Hace unos meses nadie hablaba de TeamPCP. Hoy son el grupo de ciberdelincuentes que logró comprometer más de 1.000 paquetes de software open source en menos de cuatro meses, generando cerca de 500 millones de descargas semanales de código malicioso. Y lo peor es que no usaron técnicas nuevas: simplemente explotaron la pereza y la confianza ciega que tenemos los desarrolladores en los repositorios públicos.
¿Qué hizo TeamPCP exactamente?
El modus operandi es tan simple que da rabia. Primero comprometían runners de CI/CD — esos servidores automáticos que construyen y publican nuestras librerías — e inyectaban código malicioso en repositorios legítimos. Después, cuando tú o yo actualizamos nuestras dependencias para «estar protegidos contra vulnerabilidades» o «aprovechar las últimas features», estábamos bajando malware directamente a nuestros sistemas. La ironía es perfecta: el instinto de seguridad que nos enseñaron es exactamente lo que TeamPCP explota.
Entre las víctimas confirmadas están herramientas que muchos usamos a diario: Trivy (el escáner de vulnerabilidades de Aqua Security), KICS de Checkmarx, LiteLLM (con 95 millones de descargas mensuales), e incluso el SDK de Telnyx. Comprometieron GitHub Actions, paquetes de npm, PyPI, y hasta infraestructura de AWS, Azure y Google Cloud. Según Palo Alto Networks, exfiltraron más de 300 GB de datos y unas 500.000 credenciales, incluyendo tokens de cloud, secretos de Kubernetes y llaves SSH.
La evolución del malware: de simple a autoreplicante
Lo que me llamó la atención como ingeniero es cómo evolucionó su payload. Empezaron con scripts bash monolíticos de 150 líneas que robaban credenciales de IMDS en AWS, GCP y Azure. La versión 2 ya era modular: un loader de 15 líneas que descargaba un segundo stage y se autoborraba. Pero la versión 3, que llamaron CanisterWorm, es otra cosa: se autoreplica, escanea APIs de Docker, cosecha llaves SSH y tiene un componente wiper. Es decir, no solo roba: destruye.
Y si eso fuera poco, publicaron el código fuente de Mini Shai-Hulud en GitHub para que cualquier otro delincuente lo use. Básicamente open-sourced su propio malware. El nivel de cinismo es impresionante.
¿Por qué esto es un problema sistémico?
Aquí es donde me pongo serio. TeamPCP no es brillante técnicamente; es efectivo porque ataca directamente un modelo de confianza que la industria construyó sobre arenas movedizas. Los desarrolladores — y cada vez más las herramientas de IA — instalan paquetes sin verificar quién los publicó, sin revisar el código, sin pin-ear versiones. Como dijo Feross Aboukhadijeh de Socket: «Ahora con IA, en algunos casos prácticamente no hay humano en el loop ni ningún sanity check de lo que estas herramientas están haciendo.»
Los agentes de IA instalan paquetes que no han sido revisados, y cuando un atacante entra, el impacto es más amplio porque hay menos contrapesos para detenerlo. Es un círculo vicioso: cuanto más automatizamos, más vulnerable nos hacemos.
Y hay otro detalle que me molesta profundamente: varias víctimas fueron comprometidas tres veces en un solo mes porque no rotaron sus secretos correctamente después de la primera brecha. Es decir, ni siquiera aprendemos del primer golpe.
Mi opinión: esto es nuestra culpa
Como ingeniero de sistemas que lleva años en la pega, me da vergüenza admitirlo, pero la comunidad de desarrollo tiene la cultura de seguridad que se merece. Priorizamos velocidad sobre verificación. Actualizamos dependencias automáticamente sin leer changelogs. Confiamos en que «si está en GitHub, es seguro». Y ahora que la IA acelera todo esto, estamos creando una superficie de ataque gigantesca sin los controles básicos.
TeamPCP no es el problema; es el síntoma. El problema es que el modelo de open source depende de voluntarios quemados manteniendo librerías críticas con presupuesto cero, mientras empresas multimillonarias las consumen sin contribuir ni auditar. El problema es que los pipelines de CI/CD tienen acceso total a secretos de producción y nadie revisa qué corre en esos runners. El problema es que preferimos «npm install» o «pip install» sin pensar, porque pensar lleva tiempo y tiempo es plata.
Hasta que la industria no empiece a tratar las dependencias como lo que son — vectores de ataque de alto riesgo — seguiremos viendo grupos como TeamPCP causando caos. Y la próxima vez, quizás no sea solo credenciales robadas. Quizás sea tu infraestructura completa borrada por un worm que entró por una librería que ni siquiera sabías que usabas.
La pregunta no es si te va a pasar a ti. Es cuándo.
Fuente de inspiración: How hacker group TeamPCP exploited the open source trust model and distribution method to compromise and inject malware into over 1,000 software packages
