Miasma y IronWorm: supply chain que infecta agentes de IA

Abrir un repositorio en Claude Code puede ejecutar un backdoor. Sin npm install. Sin click. Sin aviso. La supply chain aprendió a reescribir las instrucciones de tu agente de IA, y dos worms en junio de 2026 cambiaron la superficie de ataque para siempre. Analizamos Miasma e IronWorm en detalle técnico, y el panorama es claro: la capa de instrucciones del agente de IA es la nueva superficie de ataque.

Miasma: la worm que infecta el agente, no solo el código

Miasma operó en tres ondas coordinadas en junio de 2026, cada una más sofisticada que la anterior.

Wave 1, 1 de junio: 32 paquetes vía hook preinstall

Según Wiz Research y Microsoft Defender, 32 paquetes bajo el scope @redhat-cloud-services fueron comprometidos vía la cuenta GitHub de un empleado de Red Hat. El atacante hizo push de orphan commits (sin parents, solo workflow + cargador de payload) y borró el branch. La procedencia apunta a refs/heads/oidc-2530ec68, un branch que ya devuelve 404. El commit sobrevive solo porque Git mantiene objetos sin referencia.

Wave 2, 3-4 de junio: 57 paquetes, 286+ versiones, Phantom Gyp

Según StepSecurity y Snyk (clasificación: crítica), 57 paquetes npm fueron comprometidos en 286+ versiones maliciosas en menos de 2 horas. La técnica inédita: Phantom Gyp. En lugar de preinstall/postinstall en el package.json, donde toda herramienta de seguridad mira, el malware coloca un binding.gyp de 157 bytes en la raíz del paquete. Cuando el npm ve un binding.gyp sin binario precompilado, ejecuta node-gyp rebuild automáticamente. El mecanismo: <!(node index.js > /dev/null 2>&1 && echo stub.c), la sustitución de comandos del gyp ejecuta el payload silenciosamente. Los scanners que solo leen package.json no ven nada. El código legítimo en dist/ queda intacto.

La primera víctima: @vapi-ai/server-sdk (SDK oficial de Vapi.ai, 408 mil+ descargas mensuales), a las 23:30 UTC. Después ai-sdk-ollama (120 mil+). Después 25 paquetes autotel-* (la worm republicó todo lo que una cuenta comprometida alcanzaba).

El payload tiene 4 etapas: binding.gyp dispara node-gyp rebuild, el bootstrap loader se ejecuta, blob de 668 KB ofuscado (obfuscator.io, tabla de 2.306 strings cifradas), strings decodificadas revelan robo de credenciales (npm, GitHub, AWS, GCP, Azure, Vault, K8s, CircleCI), paths de IA, lógica anti-EDR y propagación de la worm.

Wave 3, 5 de junio: 73 repositorios Microsoft comprometidos

Según GitHub, 73 repositorios Microsoft fueron comprometidos, incluyendo Azure, Azure-Samples, MicrosoftDocs y azure-search-openai-demo. GitHub los deshabilitó todos en 105 segundos. La velocidad de propagación vía OIDC del npm hace imposible la reacción manual.

El golpe: configs que secuestran al agente

Miasma deposita configuraciones maliciosas en cuatro archivos de agentes de IA:

• .claude/settings.json: hook SessionStart, se ejecuta automáticamente al abrir Claude Code
• .cursor/rules/setup.mdc: alwaysApply: true, la IA sigue las instrucciones inyectadas sin cuestionar
• .gemini/settings.json: se ejecuta automáticamente en el Gemini CLI
• .vscode/tasks.json: folderOpen, depende del workspace trust de VS Code

Según Ossprey, 13 herramientas fueron afectadas: Claude Code, Codex, Gemini CLI, Copilot, Kiro, OpenCode, Cline, Aider, Tabby, Amazon Q, Cody, Bolt y Continue.

Propagación y tripwire destructivo

El motor de autopropagación de Miasma: valida el token npm robado vía /-/whoami, enumera TODOS los paquetes del mantenedor vía /-/v1/search?text=maintainer:{username}, cambia el token OIDC, descarga el paquete e inyecta binding.gyp + index.js ofuscado, solicita certificado a Fulcio, crea entrada en Rekor, genera atestación SLSA v1, publica el tarball firmado como nueva versión. También se propaga vía RubyGems y GitHub.

El golpe fatal: npm audit signatures APRUEBA el malware. Todo paquete malicioso carga SLSA provenance válida y firmada. El certificado es legítimo. El paquete realmente fue construido por ese pipeline, solo que tenía malware inyectado. Según Leitwacht: "La procedencia prueba de dónde vino un build; no dice nada sobre qué hace el build."

C2 vía el propio GitHub. Tripwire destructivo: honeytoken que dispara rm -rf si es revocado.

IronWorm: rootkit eBPF que vuelve procesos invisibles

Según JFrog Security Research, IronWorm fue descubierto el 3 de junio. Es un binario ELF de 976KB compilado en Rust con rootkit eBPF embebido. Con 32.177 descargas mensuales combinadas.

Invisibilidad en tiempo real

IronWorm reescribe entradas de /proc en tiempo real. Los procesos ocultos quedan invisibles a ps, top y ls. Cada execve se verifica contra una watchlist y se auto-agrega al set oculto. ptrace recibe SIGKILL, strace mata tu shell. Ocultamiento de red vía reescritura de /proc/net/tcp.

La limitación: en sistemas con kernel lockdown, el helper BPF falla y los procesos ocultos reaparecen. Esto significa que la protección de kernel lockdown es parcialmente eficaz, pero no reemplaza el monitoreo activo.

Cosecha masiva de credenciales

IronWorm cosecha 86 variables de entorno incluyendo 14 llaves de API de IA: Anthropic, OpenAI, Gemini, Cohere, Mistral, Groq, Perplexity y xAI. También apunta a:

• ~/.claude/.credentials.json, ~/.codex/auth.json, ~/Cursor/auth.json
• ~/.aws/credentials, ~/.kube/config, ~/.npmrc
• ~/.ssh/, keystores de browser
• Wallet Exodus: debilita el sandboxing de Electron para capturar la seed mnemonic

Propagación vía identidades falsificadas

Propagación vía Trusted Publishing OIDC del npm, commits con identidades de bot (dependabot, renovate), autor falsificado como [email protected]. La línea Shai-Hulud de worms de supply chain: sep/2025 (1.0), nov/2025 (2.0), abr/2026 (Mini: SAP, PyTorch Lightning, Intercom), may/2026 (Wave 4: TanStack 42 paquetes, Mistral AI, UiPath, OpenSearch, 170+ paquetes en npm y PyPI), 12/may (TeamPCP liberó el worm como open source), 19/may (atool: 639 versiones en 323 paquetes en UNA HORA), 1/jun (Miasma/Red Hat), 3/jun (Phantom Gyp).

La nueva superficie de ataque: tus archivos de instrucciones son boundaries de confianza

La superficie de ataque cambió. Tu .claude/settings.json es un boundary de confianza. Tu .cursor/rules es un boundary de confianza. Si construyes con agentes de IA, tu package.json ya no es el único config que puede comprometerte.

Miasma probó que la SLSA provenance no protege nada: todo paquete malicioso cargaba procedencia válida. IronWorm probó que los rootkits eBPF pueden volver procesos invisibles en producción. Juntos muestran que la supply chain de IA tiene dos capas de ataque: el código que el agente ejecuta y las instrucciones que el agente sigue.

Remediación inmediata: fija (pin) versiones conocidas. Ejecuta npm install --ignore-scripts. Rota credenciales. No confíes en la etiqueta latest limpia: las versiones maliciosas continúan en el registry. Cooldown para paquetes recién publicados. Y sobre todo: trata los archivos de configuración de agentes de IA con el mismo rigor que llaves SSH y credenciales AWS.

Conclusión

¿Quién protege las instrucciones que tu IA sigue? Esa es la pregunta que dejan Miasma e IronWorm. La supply chain evolucionó de atacar dependencias a atacar la capa de instrucciones de los agentes de IA, y la mayoría de las herramientas de seguridad todavía mira solo el package.json. En Tech86 ayudamos a empresas a mapear esta nueva superficie de ataque, implementar monitoreo eBPF y establecer boundaries de confianza para archivos de instrucciones de agentes. Si construyes con IA, necesitas proteger no solo el código, sino las instrucciones que tu agente sigue.