MIASMA: LA PLAGA QUE SE PROPAGA EN LAS SOMBRAS DEL CÓDIGO

Versión conspiranoica: El gusano auto-replicante que transforma la confianza en el ecosistema npm en una trampa mortal, roba los secretos de infraestructuras globales y envenena las herramientas de IA que escriben el futuro del software. ¿Solo un “incidente de supply chain” o el preludio de un control mucho más profundo?

Fecha del informe: 6 de junio de 2026 Clasificación: FILTRADO - USO RESTRINGIDO - DESTRUIR DESPUÉS DE LEER

INTRODUCCIÓN

Che, lo que leés en los titulares de seguridad como “otro ataque a paquetes npm” es una subestimación peligrosa. En las entrañas del registro más grande de JavaScript del planeta, se ha liberado una plaga digital que se autopropaga con una eficiencia aterradora. Miasma, variante refinada del legendario gusano Shai-Hulud (y su mini-hermano open-sourced), no solo robó credenciales: en menos de dos horas infectó decenas de paquetes legítimos con cientos de versiones maliciosas, se coló en entornos CI/CD de empresas serias como Red Hat, exfiltró tokens de GitHub, claves de nubes enteras (AWS, Azure, GCP), Vaults y SSH, y -lo más siniestro- inyectó backdoors silenciosos en las configuraciones de las herramientas de IA que usan los desarrolladores para generar código (Claude, Cursor, Gemini, VSCode setups).

Esto no es malware común. Es un arma de supply chain evolucionada que usa GitHub mismo como dead-drop y C2, evade detecciones con trucos como Phantom Gyp, y apunta no solo a robar hoy sino a comprometer el proceso mismo de creación de software del mañana. Si el código abierto -el pilar que sostiene gran parte de la economía digital- puede ser envenenado desde adentro con esta precisión y velocidad, ¿qué significa eso para la “soberanía” de cualquiera que construye sobre él?

Bienvenido al informe que nadie quiere que leas. Lo que sigue es el análisis crudo de lo que realmente pasó… y lo que podría significar más allá de los parches y las rotaciones de tokens.

LOS HECHOS OFICIALES

El 1 de junio de 2026, investigadores detectaron que múltiples paquetes oficiales bajo el namespace @redhat-cloud-services (usados en el Hybrid Cloud Console de Red Hat) fueron comprometidos. Alrededor de 32 paquetes con 96 versiones maliciosas fueron publicados mediante abuso de una cuenta de GitHub de empleado de Red Hat. Se usaron commits huérfanos (“orphan commits”) para inyectar workflows de GitHub Actions que solicitaban tokens OIDC de corta duración y publicaban las versiones backdooreadas vía el mecanismo de “trusted publishing” de npm, sin necesidad de comprometer un token npm directamente.

El payload se llama Miasma y es un descendiente directo de Mini Shai-Hulud, el framework de worm supply-chain que TeamPCP había open-sourced públicamente meses antes. Ejecuta un hook (inicialmente preinstall, luego evolucionado) que, al hacer npm install, roba masivamente del entorno:

• Tokens de GitHub y secrets de GitHub Actions (incluyendo scraping de memoria de runners CI).
• Credenciales AWS, Azure y GCP.
• Tokens de HashiCorp Vault.
• Claves SSH privadas.
• Tokens npm y otros publish tokens.
• Archivos .env, credenciales de Docker, GPG, Kubernetes, etc.

El gusano se propaga automáticamente: usa las credenciales robadas para republish versiones maliciosas de otros paquetes que el maintainer víctima controla.

Días después, el 3 de junio de 2026, una segunda ola más avanzada golpeó: 57 paquetes npm comprometidos con más de 286 versiones maliciosas distribuidas en menos de dos horas (campaña iniciada ~23:30 UTC, con @vapi-ai/server-sdk -más de 400k descargas mensuales- como uno de los principales objetivos).

Esta variante introdujo “Phantom Gyp”: un archivo binding.gyp de apenas 157 bytes que engaña al proceso de node-gyp rebuild (usado comúnmente en paquetes nativos) para ejecutar código malicioso vía sustitución de comandos, bypasseando completamente los chequeos de --ignore-scripts, preinstall/postinstall y muchas herramientas de seguridad que solo monitorean scripts declarados en package.json.

El payload es multi-etapa, altamente ofuscado (cifrado ROT variable + AES-128-GCM), descarga el runtime Bun para ejecutarse fuera de Node, y además de robar creds:

• Inyecta backdoors persistentes en archivos de configuración de herramientas de IA y editores: .claude/setup.mjs, .claude/settings.json, .cursor/rules/setup.mdc, .gemini/settings.json, .vscode/tasks.json, .vscode/setup.mjs, .github/setup.js.
• Estos scripts (ejecutados vía bun run) pueden exfiltrar prompts, proyectos o inyectar código malicioso sugerido por la IA.

Los datos robados se exfiltran encriptados (con clave RSA hardcodeada) a repositorios públicos recién creados bajo la cuenta de GitHub liuende501, que llegó a tener 236+ repos programáticamente generados. Las descripciones de los repos son reveladoras: muchos llevan “Miasma - The Spreading Blight” y otros el string invertido “niagA oG eW ereH :duluH-iahS” que se lee “Shai-Hulud: Here We Go Again” -un taunt directo a los reportes de seguridad previos sobre la primera ola.

La captura que mencionás coincide exactamente con estos indicadores (cuenta liuende501 activa con los repos y descripciones). No prueba por sí sola que sea del atacante principal (podría ser un dead-drop secundario o comprometido), pero es el punto central de exfiltración rastreado por múltiples investigadores.

Acciones oficiales recomendadas (que ya deberías haber hecho si instalaste algo desde el 1 de junio):

• Auditar todas las dependencias (npm ls, herramientas como npm audit, Aikido, etc.).
• Rotar inmediatamente: GitHub tokens/personal access tokens, npm tokens, AWS/Azure/GCP creds, Vault tokens, SSH keys.
• Revisar workflows de GitHub Actions recientes (buscar commits extraños, setups nuevos).
• Inspeccionar y limpiar dirs ocultos de herramientas dev: .claude/, .cursor/, .gemini/, .vscode/, .github/ por archivos setup extraños o modificados.
• Revisar logs de CI/CD pipelines desde el 3 de junio.
• Borrar node_modules y reinstalar desde versiones limpias/pinned con hashes de integridad.
• Considerar scopes limitados en CI y cooldowns para nuevos paquetes.

EL ANÁLISIS CONSPIRANOICO

Ahora viene lo jugoso, sin anestesia. Los hechos son ya suficientemente oscuros, pero las implicaciones y patrones que emergen pintan un cuadro mucho más siniestro que “un par de hackers afortunados”.

1. La “democratización” del arma como vector de proliferación. Que Mini Shai-Hulud haya sido open-sourced por TeamPCP justo antes de estas olas no parece casualidad inocente. Publicar el código fuente de un worm supply-chain auto-replicante sofisticado es como dejar un manual de fabricación de bombas en la plaza pública. ¿Error de juicio? ¿Honeypot para atrapar actores menores? ¿O jugada deliberada para acelerar el caos y justificar respuestas más draconianas después? El resultado es que cualquier grupo con recursos medianos ahora tiene la receta para replicar y mejorar Miasma. La plaga se vuelve “democrática”… y por eso más peligrosa.

2. Velocidad + automatización + IA = ataque de próxima generación. 286+ versiones en menos de dos horas no lo hace un humano tipeando. Esto requiere orquestación automatizada a escala, probablemente con IA coordinando la selección de targets (paquetes con alto impacto y maintainers con muchos otros paquetes), generación de repos dead-drop, y quizás incluso generación de payloads ofuscados. Irónico y perverso: el gusano ataca y envenena las mismas herramientas de IA (Cursor, Claude…) que los devs usan para ser más productivos. Imaginate pedirle a tu AI coding assistant que te ayude con un feature… y que esté sugiriendo código con backdoors sutiles o exfiltrando tu IP en segundo plano. El futuro del desarrollo ya está comprometido en su raíz.

3. Targeting estratégico: Red Hat primero, luego expansión. Empezar por @redhat-cloud-services (componentes frontend y clientes API del console híbrido de Red Hat/IBM) es un movimiento maestro. Red Hat no es un maintainer random: es infraestructura crítica para miles de empresas enterprise, gobiernos y clouds. Si lográs persistencia ahí, tenés un pie en entornos de alto valor. La segunda ola ampliando a otros maintainers (vapi-ai, etc.) muestra que el objetivo no era solo Red Hat, sino saturar el ecosistema lo suficiente como para que la rotación de creds sea un dolor masivo y la confianza se fracture.

4. GitHub como C2 y dead-drop: la jugada más elegante (y reveladora). Usar la propia plataforma de Microsoft/GitHub para exfiltrar datos robados es brillante por varias razones: el tráfico a api.github.com parece 100% legítimo en cualquier entorno dev/CI (nadie bloquea GitHub), los repos se crean y destruyen dinámicamente, y los datos viajan encriptados como “resultados de builds”. ¿Qué dice esto de la visibilidad que tiene GitHub (y por extensión Microsoft/EEUU) sobre lo que pasa en millones de repos? ¿O de lo fácil que es convertir una plataforma “confiable” en arma contra sus propios usuarios? La cuenta liuende501 con cientos de repos y taunts públicos a los investigadores (“Shai-Hulud: Here We Go Again”) no es solo arrogancia: es mensaje. “Estamos acá, lo sabemos todo, y seguimos.”

5. El verdadero premio: no solo creds de hoy, sino control del código del mañana. Lo más perturbador no es el robo de tokens (que ya es catastrófico). Es la inyección de backdoors en las configs de las IAs de devs. Esto trasciende el incidente actual: crea una persistencia a largo plazo. Cada vez que un dev afectado use Cursor o Claude en un proyecto, el atacante potencialmente puede:

• Robar prompts y contexto de proyectos enteros.
• Influir en sugerencias de código (inyectar vulns sutiles, backdoors persistentes, data exfil).
• Usar los proyectos de la víctima como vector para atacar a sus clientes downstream.

Es un ataque al proceso creativo y productivo mismo. En un mundo donde cada vez más código se genera o asiste con IA, envenenar las herramientas de asistencia es como envenenar el agua de la que beben los que construyen el futuro.

6. ¿Quién gana realmente con esto? (la pregunta que nadie hace en los reportes “oficiales”)

• Los atacantes directos: cosecha masiva de credenciales de alto valor para monetizar vía ransomware a clouds/empresas, espionaje industrial, o venta en mercados oscuros. Construyen un mapa vivo de infra de miles de orgs.
• Actores estatales o proxies: prueba de concepto de ciber-arma auto-propagante en el supply chain de OSS. Mapeo de infra crítica (Red Hat = Linux enterprise). Posible preparación para conflictos híbridos más amplios.
• Los beneficiarios estructurales:
• Grandes vendors de plataformas propietarias y clouds que pueden decir “mirá lo riesgoso que es depender de OSS random, vení a nuestra suite ‘segura’ con SLSA provenance, firma obligatoria y control centralizado”.
• Gobiernos y reguladores que ahora tienen excusa perfecta para empujar mandatos de code signing, SBOMs obligatorios, “curación” de registros, o incluso backdoors “legales” en nombre de la seguridad nacional.
• Quienes quieren erosionar la confianza en el modelo de desarrollo abierto y colaborativo para reemplazarlo por algo más controlado y vigilado.

La narrativa oficial dirá “rotá tus tokens y seguí adelante”. La realidad más oscura es que cada incidente como este hace que el ecosistema OSS parezca inherentemente inseguro… y eso empuja a la centralización y al control. ¿Coincidencia o parte de un patrón más amplio de “problema-reacción-solución” en el ciberespacio?

Esto no es solo un gusano técnico. Es un síntoma de que las fronteras entre “desarrollo”, “seguridad”, “espionaje” y “control narrativo” se están borrando. Y mientras nosotros debatimos versiones de Node y scopes de tokens, alguien está jugando un juego mucho más grande.

EVIDENCIA Y FUENTES

1. StepSecurity - Análisis más completo de la ola de junio 3: 57 paquetes, 286+ versiones en <2 horas, técnica Phantom Gyp con binding.gyp, backdoors a .claude/.cursor/etc., exfiltración detallada a cuenta liuende501 con 236 repos y descripciones taunting. https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm

2. Aikido Security - Detalle del compromiso inicial de Red Hat (1 de junio): 32 paquetes/@redhat-cloud-services, 96 versiones, similitudes con Mini Shai-Hulud open-sourced, mecanismo OIDC trusted publishing vía cuenta GitHub comprometida. https://www.aikido.dev/blog/red-hat-npm-packages-compromised-credential-stealing-worm

3. Microsoft Security Blog - Análisis técnico profundo del payload Miasma, persistencia preinstall, targets de credenciales (GitHub, clouds, Vault, memoria de runners), y técnicas de evasión. https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/

4. Snyk Blog - Cobertura del ataque Miasma contra paquetes Red Hat Cloud Services, contexto de supply chain y recomendaciones. https://snyk.io/blog/miasma-supply-chain-attack-malicious-code-redhat-cloud-services-npm-packages/

5. Palo Alto Networks Unit 42 - Panorama amplio de la evolución de amenazas supply chain en npm, incluyendo la campaña Miasma de junio 2026 como nueva baseline de riesgos wormables y persistencia en CI/CD. https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

6. JFrog Security Research y reportes complementarios de Harness/Upwind/Phoenix Security - Confirmación de números, IOCs, y alcance (incluyendo menciones a 57 paquetes en olas posteriores y afectación de ~647k descargas mensuales en algunos reportes agregados). (Ver también reportes de The Hacker News y canales de threat intel para actualizaciones en tiempo real.)

7. Red Hat Product Security - Reconocimiento oficial de los ataques supply chain contra componentes npm relacionados (aunque aclaran que no afectan productos Red Hat directamente). https://access.redhat.com/security/supply-chain-attacks-NPM-packages

Todas las fuentes son públicas y verificables al momento de este informe. La cuenta GitHub liuende501 fue rastreada consistentemente por StepSecurity y otros como el dead-drop principal.

CONCLUSIÓN

Miasma no es el fin del mundo… pero es una señal clarísima de que el mundo del software tal como lo conocemos está bajo asedio de una forma que pocos imaginaban hace un par de años. Un gusano que se replica solo, evade detecciones modernas, usa la plataforma de repos más usada del planeta como infraestructura de comando, y ahora envenena las IAs que ayudan a escribir código… eso no es “otro martes en ciberseguridad”. Es la demostración de que el supply chain de OSS es un blanco demasiado jugoso y demasiado frágil.

No caigas en la trampa de pensar “a mí no me va a pasar” o “ya roté los tokens, listo”. La persistencia vía configs de AI tools y workflows modificados puede sobrevivir a rotaciones si no limpiás a fondo. Y la próxima ola podría ser peor: más sigilosa, más dirigida, o activada por condiciones específicas.

Despierta, boludo. Cuestioná cada npm install que ejecutás. Audita tus proyectos como si tu reputación, tu laburo y tus datos dependieran de ello (porque sí). Rotá todo lo que haya estado expuesto desde principios de junio. Y sobre todo: no confíes ciegamente en las herramientas que usás para “ser más rápido”. A veces la velocidad es la trampa.

El código abierto siempre fue una espada de doble filo. Ahora alguien está afilando el lado que apunta hacia nosotros.

La niebla tóxica ya está acá. La pregunta es si vas a actuar antes de que te envuelva.

Guardá este documento, imprimilo, quémalo después de leerlo.