Miasma: worm de supply chain infecta 32 paquetes Red Hat en npm

El preinstall es uno de los hooks más simples de npm: agregas una línea en el package.json y el script se ejecuta automáticamente antes de cualquier instalación. Es útil para validar entornos, generar configuraciones. El 1 de junio de 2026 se descubrió que también es igual de perfecto para robar las credenciales de nube de cada desarrollador que ejecute npm install.

Eso fue lo que hizo el worm Miasma en al menos 32 releases del namespace @redhat-cloud-services en npm. Wiz Research identificó el compromiso el día 1 de junio; el Microsoft Security Blog publicó un análisis técnico detallado el 2 de junio. Los paquetes afectados acumulan cerca de 80 mil descargas por semana.

Cómo entró el atacante

Wiz Research determinó que la cuenta de GitHub de un empleado de Red Hat fue comprometida y usada para inyectar el malware en el pipeline de CI/CD del namespace @redhat-cloud-services. Desde esa cuenta, el atacante subió commits a ramas efímeras (oidc-<hex>) en los repositorios de RedHatInsights y reescribió el workflow de publicación en GitHub Actions para ejecutar el payload del worm con permiso id-token: write.

Este detalle importa: el atacante no necesitó una contraseña de npm. Usó el token OIDC generado por la propia Actions para publicar paquetes como si fuera el pipeline legítimo de Red Hat.

Qué hace el script preinstall

Cada tarball comprometido cargaba un archivo JavaScript de 4,29 MB fuertemente ofuscado registrado como gancho de preinstall. Al ejecutar npm install, el paquete dispara automáticamente un loader multi-etapa que instala el runtime Bun en silencio y ejecuta el payload principal.

Lo que el payload recolecta, según el Microsoft Security Blog:

• Claves SSH y credenciales de CLI
• Datos de navegador y carteras locales
• Identidades de nube: AWS, Azure, GCP, HashiCorp Vault
• Secretos de pipelines Kubernetes
• Tokens OIDC de GitHub Actions, incluyendo secretos enmascarados en la memoria del runner
• Tokens de npm y credenciales de Bitwarden y 1Password

La exfiltración usa dos canales: HTTPS directo y la GitHub Contents API, lo que disfraza el tráfico malicioso como actividad legítima de repositorio.

El componente worm: cómo se autopropaga

Miasma no es solo un stealer. Es un worm: usando los tokens de npm robados, enumera todos los repositorios y organizaciones donde la víctima puede publicar y usa la bandera bypass_2fa: true para republicar versiones envenenadas de esos paquetes, alcanzando a otros desarrolladores sin que nadie necesite ser víctima directa de phishing.

Cada payload republicado está cifrado con AES-GCM único por infección. Esto vuelve inútiles los IOC basados en hash: un indicador de compromiso detectado en una versión no sirve para la siguiente. Cada víctima recibe un artefacto distinto.

El bypass de SLSA provenance: la parte más preocupante

El Supply-chain Levels for Software Artifacts (SLSA) es un framework creado exactamente para este tipo de problema: garantizar que un paquete npm viene del código fuente correcto, generado por un pipeline legítimo, sin manipulación. Red Hat usaba SLSA. Los paquetes comprometidos publicados por Miasma tenían provenance SLSA válido.

Wiz Research identificó el motivo: npm vincula el Trusted Publishing al nombre del repositorio más el nombre del workflow, pero no a la rama de origen. El atacante creó ramas efímeras en los repositorios legítimos de RedHatInsights y reescribió el workflow para autopublicarse con OIDC. El resultado: tarballs troyanizados con provenance SLSA válido que pasa cualquier verificación automatizada. La cadena de custodia criptográfica existía, y apuntaba a un artefacto malicioso.

La conexión con TeamPCP y el worm Shai-Hulud

Miasma no surgió de la nada. Es una variante evolucionada del worm Mini Shai-Hulud, cuyo código fuente el grupo TeamPCP publicó en GitHub el 12 de mayo de 2026, acompañado de publicaciones en BreachForums incentivando campañas independientes. Miasma añade recolectores de identidad de nube (Azure, GCP) y cifrado por infección que el original no tenía.

Si seguiste aquí el caso TeamPCP que comprometió GitHub vía una extensión de VS Code, vas a reconocer el patrón: el mismo grupo que atacó la cadena de suministro de desarrolladores en mayo abrió el código del worm para que cualquiera hiciera lo mismo, y alguien lo hizo, tres semanas después.

Qué verificar si usas estos paquetes

Red Hat confirmó que ningún producto oficial se distribuyó con las versiones comprometidas, y npm eliminó los releases maliciosos. Pero si tú o tu equipo instalaron paquetes del namespace @redhat-cloud-services entre el 1 y el 2 de junio, la recomendación de los equipos de respuesta es tratarlo como un compromiso confirmado:

1. Revocar de inmediato todos los tokens de nube (AWS, Azure, GCP) y de npm de las máquinas afectadas
2. Ejecutar npm audit y revisar el lockfile en busca de releases con hash inesperado
3. Examinar los logs de GitHub Actions del período; el worm extrae secretos enmascarados de la memoria del runner
4. Restringir el permiso id-token: write en Actions solo a los jobs que realmente necesiten publicar
5. Para mantenedores de npm: proteger las ramas principales con revisión obligatoria de PR y bloquear pushes directos

La lección más grande aquí es que el provenance de SLSA no sustituye el control de acceso. Un framework de integridad es tan fuerte como la cuenta que autoriza los commits. Proteger al desarrollador, con MFA robusto, revisión periódica de accesos y monitoreo de cuentas, sigue siendo el eslabón más frágil de la cadena. Ataques similares al caso JDownloader de mayo y al MOVEit de 2023 repiten el mismo patrón: comprometer el punto de distribución confiable, no el endpoint final.

Si gestionas pipelines con paquetes npm, este incidente es el argumento que faltaba para revisar los permisos de tu Actions y rotar tokens con regularidad. El informe técnico de Wiz Research detalla los IoC y hashes de las versiones comprometidas para quien necesite auditar el entorno.