Miasma Worm no necesita CVE. No explota una vulnerabilidad en el código. Abusa de la infraestructura de confianza que construimos para protegernos, y que funciona exactamente como fue diseñada. En Tech86 seguimos en tiempo real cómo siete días de ataques coordinados transformaron SLSA, Sigstore y credenciales legítimas en vectores de compromiso en masa. El resultado: más de 400 artefactos rastreados entre npm y PyPI por investigadores de seguridad, y cero CVEs atribuidos hasta el momento.
7 días, 4 superficies de entrega simultáneas
Miasma Worm operó en cuatro frentes paralelos entre el 1 y el 7 de junio de 2026, según investigadores de seguridad que rastrearon el incidente. Cada frente explotó un vector diferente de confianza, y cada uno pasó por las verificaciones que deberían detectarlo.
El 1 de junio, decenas de paquetes @redhat-cloud-services en el npm fueron publicados con scripts preinstall maliciosos. Según datos del npm, decenas de miles de descargas semanales fueron afectadas. Los tokens OIDC robados del GitHub Actions pasaron la verificación de procedencia SLSA vía Sigstore, Fulcio y Rekor. Los paquetes pasan npm audit signatures, porque las firmas son genuinas.
El 4 de junio, 57 paquetes npm usaron binding.gyp, compilación nativa que elude las herramientas de monitoreo de scripts. Incluyendo @vapi-ai/server-sdk, con cientos de miles de descargas mensuales según estadísticas del npm. En total, cientos de miles de descargas mensuales afectadas, según investigadores de seguridad que rastrearon el incidente.
El 5 de junio, un commit malicioso en el repositorio Azure/durabletask en GitHub se disparó cuando desarrolladores abrieron el repositorio en agentes de IA como Claude Code, Gemini CLI, Cursor o VS Code. Sin npm install. Sin build. Se abrió, se ejecutó. Según reportes de seguridad, GitHub habría deshabilitado decenas de repositorios Microsoft en cuestión de minutos. La Azure/functions-action quedó fuera de servicio, y todo pipeline CI/CD que referenciaba Azure/functions-action@v1 se rompió globalmente.
El 7 de junio, decenas de wheels de PyPI en 19 paquetes usaron hooks de startup .pth, una variante denominada Hades. El código se ejecuta en cada startup del intérprete de Python, independientemente de qué paquete haya sido importado.
Qué roba Miasma, y por qué esto no termina
El scope de exfiltración de Miasma es amplio: credenciales AWS, Azure, GCP, Kubernetes, HashiCorp Vault, GitHub, npm, llaves SSH y datos de browser. Según investigadores de seguridad que rastrearon el incidente, el código fuente del toolkit fue publicado como código abierto el 9 de junio, lo que significa que campañas derivadas son prácticamente garantizadas.
Un detalle que ilustra la gravedad: la misma cuenta de contribuidor comprometida en mayo en PyPI (durante el incidente con durabletask) fue usada nuevamente en junio, según reportes de seguridad. Las credenciales nunca fueron completamente rotadas. El atacante reutilizó acceso que debió haber sido revocado.
La infraestructura de confianza funcionó, y eso es el problema
El aspecto más perturbador de Miasma Worm es que la infraestructura de procedencia funcionó exactamente como fue diseñada. El problema es que el atacante usó credenciales legítimas para atestar código malicioso como confiable. La verificación de firma no detecta esto porque las firmas son genuinas. SLSA confirma que el paquete vino de donde dice que vino, pero no codifica qué había dentro.
En Tech86, esa es la lección central que extraemos: procedencia no es seguridad. Es procedencia. Mientras la industria trate la atestación de origen como garantía de seguridad, los atacantes seguirán usando nuestra propia infraestructura de confianza contra nosotros. Miasma Worm es la prueba operacional de eso.
La convergencia que nadie esperaba
Miasma Worm no es un ataque aislado. Es la convergencia operacional de tres patrones que la comunidad de seguridad venía observando por separado: autorreplicación tipo worm, autonomía de agente y compromiso de supply chain de software. Hasta entonces, cada patrón había sido documentado de forma independiente: un worm experimental, un agente autónomo, vulnerabilidades aisladas en supply chains de software. Miasma es todo eso operando en conjunto, en un único ataque en producción, con cuatro superficies de entrega simultáneas.
Esta convergencia cambia el modelo de amenaza. No basta proteger el supply chain de software. No basta monitorear agentes de IA. No basta auditar paquetes. Hay que proteger los tres vectores al mismo tiempo, porque el próximo Miasma va a operar de la misma forma, y probablemente con más superficies.
Qué cambia a partir de ahora
En Tech86, la conclusión que sacamos es directa: la defensa perimetral tradicional no alcanza los ataques que abusan de la infraestructura de confianza. Un WAF bloquea tráfico malicioso en el borde, pero no intercepta un npm install cuyo paquete tiene firma válida y procedencia SLSA verificada. Miasma entra con credenciales legítimas y firmas genuinas, no por la puerta del frente. Por eso nuestra Seguridad Ofensiva combina monitoreo de integridad de pipelines, verificación de comportamiento de paquetes en producción y caza proactiva de vectores de supply chain, porque el ataque de hoy se infiltra donde la infraestructura confía, no donde el perímetro vigila.
Tu npm audit signatures pasa. Tu SLSA verifica. Tu CI/CD confía. Y el atacante está adentro.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →