TeamPCP No Paró en Trivy
El 20 de marzo de 2026, a las 20:45 UTC, los investigadores de Aikido Security detectaron algo inusual en el registro de npm: decenas de paquetes de múltiples organizaciones estaban recibiendo actualizaciones de parche no autorizadas, todas con el mismo código malicioso oculto.
Lo que habían detectado era CanisterWorm — un gusano de supply chain npm desplegado por TeamPCP, el mismo grupo de amenazas responsable del compromiso de Trivy que cubrimos esta mañana.
No es coincidencia. Es la segunda fase de la misma campaña.
De Trivy a npm: La Cadena de Ataque Completa
El ataque a Trivy no fue el objetivo final de TeamPCP — fue el punto de partida. Al comprometer el repositorio de Trivy y sus GitHub Actions el 19 de marzo, el grupo obtuvo acceso a credenciales de CI/CD de miles de organizaciones que ejecutaron las versiones maliciosas. Entre esas credenciales: tokens de npm de mantenedores de paquetes.
Con esos tokens, TeamPCP podía publicar nuevas versiones de paquetes npm legítimos como si fuera los propios mantenedores. Y eso hizo, metódicamente:
- 20 de marzo: Detección inicial — 29 paquetes comprometidos
- 21 de marzo: El alcance se expande — 135 paquetes identificados como parte de CanisterWorm
- 23 de marzo: The Hacker News confirma la conexión directa con el ataque a Trivy
Los 135 paquetes afectados incluyen SDKs y librerías usadas como dependencias en proyectos de downstream — lo que significa que el impacto real se multiplica exponencialmente más allá de los paquetes directamente comprometidos.
Cómo se Auto-Propaga CanisterWorm
Lo que diferencia a CanisterWorm de un ataque de supply chain convencional es su capacidad de propagación autónoma. Cuando el código malicioso se ejecuta en el entorno de un desarrollador o en un pipeline de CI/CD, hace tres cosas:
- Roba tokens de npm del entorno: Busca en variables de entorno, en el archivo
~/.npmrc, y en secretos montados en CI/CD cualquier token de autenticación de npm con permisos de publicación. - Consulta el C2 para instrucciones: En lugar de conectarse a un servidor tradicional (fácilmente bloqueado o eliminado), CanisterWorm consulta un canister en Internet Computer Protocol (ICP) — infraestructura blockchain descentralizada — para obtener la lista de paquetes a infectar y el payload actualizado.
- Publica versiones maliciosas de nuevos paquetes: Usando los tokens robados, publica patch updates de paquetes npm donde el token tiene permisos de escritura, propagando el gusano a nuevos vectores de infección.
Cada nueva víctima se convierte en un nuevo vector de propagación. El gusano se auto-sostiene.
El Truco del Blockchain C2: Por Qué Este Ataque es Difícil de Detener
La innovación técnica más significativa de CanisterWorm no es el robo de tokens — eso es conocido. Es la infraestructura de comando y control.
Los ataques de supply chain convencionales usan servidores C2 tradicionales: un dominio o IP desde donde el malware recibe instrucciones. Contra esos servidores, los defensores tienen herramientas claras: bloquear el dominio, solicitar el takedown al proveedor de hosting, o incautar el servidor con órdenes legales.
TeamPCP usó un canister de ICP (Internet Computer Protocol) como dead drop — un repositorio descentralizado en blockchain donde deposita instrucciones y el malware las recoge. No hay servidor que bloquear. No hay dominio que suspender. No hay proveedor de hosting que pueda recibir una orden judicial. El C2 vive en una red blockchain descentralizada que ninguna autoridad puede apagar unilateralmente.
Es la primera vez que este patrón se documenta públicamente en un ataque de supply chain a npm a esta escala. No será la última.
Qué Paquetes Están Afectados
Socket, Aikido Security y otros investigadores están manteniendo listas actualizadas de los 135+ paquetes comprometidos. La lista completa está en constante evolución — CanisterWorm sigue propagándose mientras los equipos de seguridad trabajan en la respuesta.
Las categorías de paquetes afectados incluyen:
- SDKs de servicios cloud e infraestructura
- Librerías de autenticación y gestión de tokens
- Herramientas de CI/CD y build pipelines
- Paquetes de utilidades ampliamente usados como dependencias transitivas
Si tu proyecto tiene dependencias de npm, especialmente en las categorías anteriores, tienes riesgo de exposición aunque no uses directamente ninguno de los 135 paquetes identificados. Las dependencias transitivas — paquetes que tus paquetes usan — son el vector silencioso.
Cómo Protegerte: Acciones Inmediatas
- Audita tus tokens de npm. Si algún pipeline de CI/CD ejecutó Trivy entre el 19 y el 23 de marzo, asume que los tokens de npm presentes en ese entorno fueron comprometidos. Revócalos en
npmjs.com/settings/tokensy genera nuevos con el menor scope posible. - Bloquea las versiones de tus dependencias. Si estás usando rangos de versión en tu
package.json(^1.2.3o~1.2.3), un paquete comprometido puede colarse como "patch update". Considera fijar versiones exactas y usarpackage-lock.jsonoyarn.lockcon verificación de integridad. - Habilita npm audit en tu pipeline.
npm audity herramientas como Socket.dev, Snyk, o Dependabot pueden detectar paquetes con comportamiento malicioso conocido. Automatiza estas verificaciones en cada PR y build. - Revisa el lockfile de tu proyecto. Compara tu
package-lock.jsonactual con el de hace una semana. Cambios inesperados en versiones de dependencias transitivas son una señal de alerta. - Bloquea el dominio ICP en tu red corporativa. Aunque no eliminará el C2 globalmente, bloquear las llamadas salientes a la red ICP desde tus pipelines de CI/CD puede interrumpir la comunicación de CanisterWorm con su infraestructura de blockchain.
El Lunes Negro del Supply Chain
En el transcurso de una sola jornada — el 23 de marzo de 2026 — el ecosistema de desarrollo de software procesó dos ataques de supply chain activos del mismo grupo (TeamPCP): el compromiso de Trivy y la propagación de CanisterWorm en npm. Ambos usando técnicas distintas, ambos apuntando a desarrolladores y equipos DevSecOps, ambos robando el mismo tipo de credenciales de alto valor.
La tendencia es clara: los atacantes sofisticados han identificado la cadena de suministro de software — las herramientas que los desarrolladores usan para construir software — como el vector de ataque de mayor ROI. Comprometer un scanner de seguridad o un paquete npm popular entrega acceso instantáneo a miles de entornos de desarrollo y producción.
La defensa requiere tratar cada herramienta de desarrollo y cada dependencia con el mismo nivel de desconfianza que cualquier software externo: verificar integridad, minimizar privilegios, auditar continuamente, y tener un plan de respuesta cuando una herramienta de confianza resulta comprometida.
Si tu organización usa npm extensivamente y quieres entender cuál es tu exposición real a ataques de supply chain como CanisterWorm o el compromiso de Trivy, el equipo de Sable puede hacer ese análisis. Y si llegaste aquí sin haber leído el artículo sobre Trivy, empieza por ahí — son parte de la misma campaña.