npm lanzó «Package Provenance» a finales de 2022. Durante dos años, la adopción se situó de media entre 20 y 50 paquetes por semana. A esto le siguió «Trusted Publishing» en 2024. Se publicaron entradas de blog. Se emitieron avisos de la CISA. La situación apenas varió. Finalmente, «Trusted Publishing» con OIDC se puso a disposición del público en general en julio de 2025.
Entonces se produjo el ataque de Shai-Hulud. La adopción semanal se disparó hasta los 430 paquetes. En 18 meses, la adopción acumulada se multiplicó por 3,4. Todavía solo cubrimos el 25 % del volumen total de descargas: solo 11.001 de los 51.370 paquetes más populares lo han adoptado. Pero los ataques tuvieron un impacto mayor que cualquier otra medida tomada por el sector de la seguridad.
Aquí están los datos.
Qué es «Trusted Publishing»
Trusted Publishing sustituye los tokens de la API de npm de larga duración por credenciales de corta duración, válidas para cada ejecución, emitidas a través de OpenID Connect. En lugar de almacenar el NPM_TOKEN en los secretos de tu repositorio de GitHub de forma indefinida, tu pipeline de CI obtiene un token que caduca en cuestión de minutos. No hay nada que robar. No hay nada que filtrar.
La oleada de ataques que lo cambió todo
26 de agosto de 2025: S1ngularity. Los atacantes aprovecharon una configuración errónea de GitHub Actions en el monorepo de Nx para ejecutar código procedente de una bifurcación maliciosa en el contexto de confianza del repositorio original, sustrayendo así el token de publicación de npm. Las versiones maliciosas de varios paquetes de Nx estuvieron activas durante cuatro horas, escaneando los equipos de los desarrolladores en busca de credenciales, claves SSH y carteras de criptomonedas; y, sobre todo, buscando activamente herramientas de IA de línea de comandos instaladas para ejecutarlas con la opción --dangerously-skip-permissions y extraer el contenido del sistema de archivos. Esa semana: la adopción aumentó notablemente por primera vez.
8 de septiembre de 2025: Debug/Chalk. Un mantenedor fue víctima de un ataque de phishing a través de un correo electrónico falso de soporte técnico de npm (enviado desde npmjs.help) que recopiló sus credenciales y su código TOTP en tiempo real. Se introdujo una puerta trasera en 18 paquetes, con más de 2 000 millones de descargas semanales en total, mediante una carga útil de robo de criptomonedas que interceptaba de forma silenciosa las interacciones de los monederos en el navegador y redirigía los fondos. Las versiones maliciosas estuvieron activas durante dos horas. Esa semana: 103 nuevos paquetes adoptaron Trusted Publishing.
15 de septiembre de 2025: Shai-Hulud, primera oleada. Un gusano autorreplicante afectó al ecosistema de npm. Cuando un paquete comprometido encontraba tokens de npm adicionales en su entorno, publicaba automáticamente versiones maliciosas de cualquier otro elemento al que pudiera acceder. Resultado: más de 700 paquetes comprometidos, 27 000 repositorios maliciosos en GitHub y 14 000 secretos expuestos en 487 organizaciones. La CISA emitió una alerta el 23 de septiembre. Esa semana: 109 paquetes nuevos.
23 de noviembre de 2025: Shai-Hulud 2.0. Una solicitud de «Pwn» dirigida al repositorio asyncapi/cli filtró el token de CI en menos de tres minutos y, a continuación, lo utilizó para desplegar el gusano a través de una extensión maliciosa de OpenVSX. La campaña se extendió a más de 25 000 repositorios maliciosos. Microsoft publicó unas directrices el 9 de diciembre. Esa semana: 372 paquetes nuevos. La media semanal de los dos años anteriores rondaba los 40.
24 de noviembre de 2025: SHA1-Hulud. Una oleada de ataques afectó a Zapier, ENS Domains y otras empresas. Se encontraron credenciales de larga duración almacenadas en repositorios comprometidos. El equipo de seguridad de npm recomendó expresamente el uso de «Trusted Publishing» como solución. Esa semana: 120 paquetes nuevos.
20-21 de marzo de 2026: CanisterWorm. TeamPCP difundió un gusano de npm mediante tokens robados. Más de 28 paquetes infectados en menos de 60 segundos; la carga útil recopiló credenciales y se propagó por sí misma. Esa semana: 112 paquetes nuevos.
31 de marzo de 2026: Axios. Sapphire Sleet (Corea del Norte) comprometió la cuenta de un mantenedor y publicó dos versiones con puerta trasera con 39 minutos de diferencia entre ellas, cada una de las cuales inyectaba una dependencia falsa que descargaba de forma silenciosa un troyano de acceso remoto multiplataforma. Los paquetes maliciosos estuvieron activos durante tres horas. Axios tiene más de 100 millones de descargas semanales. Esa semana: 138 paquetes nuevos.
Del 8 al 22 de abril de 2026: CanisterSprawl. Un segundo gusano npm de TeamPCP que utilizaba un nuevo contenedor ICP. Cuando se descubrieron tokens de PyPI en entornos infectados, se propagó a otros ecosistemas mediante la inyección de archivos .pth. Esa semana: 163 paquetes nuevos.
29-30 de abril de 2026: Mini Shai-Hulud I. TeamPCP pasó de robar tokens a suplantar credenciales de CI. Un ataque que afectó a varios ecosistemas afectó a npm, PyPI y Packagist en 24 horas a través de tokens de CircleCI comprometidos. Esa semana: 121 paquetes nuevos.
Del 7 al 11 de mayo de 2026: Mini Shai-Hulud II / TanStack. Esta es la escalada que lo cambia todo: no robaron ningún token. El equipo TeamPCP utilizó una solicitud «Pwn Request» para contaminar la caché de GitHub Actions y, a continuación, esperó a que se ejecutara el flujo de trabajo de lanzamiento legítimo. Cuando esto ocurrió —con id-token: permisos de escritura—, el código controlado por el atacante procedente de la caché contaminada extrajo el token OIDC de la memoria del ejecutor y lo intercambió a través del propio punto final de tokens de npm. Los paquetes publicados llevaban certificados de procedencia SLSA de nivel 3 válidos. La publicación de confianza no se eludió. Se utilizó como vector de ataque. Más de 170 paquetes en npm y PyPI en 5 horas.
18-19 de mayo de 2026: Mini Shai-Hulud III / Nx y AntV. La extensión VS Code de Nx Console se vio comprometida mediante credenciales robadas durante el ataque a TanStack —cinco días de tiempo de permanencia antes de su uso—. Se contaminaron 639 versiones de @antv en npm a través de una cuenta robada del mantenedor, cada una de las cuales instalaba una puerta trasera persistente «kitty-monitor ». Esa semana: 144 paquetes nuevos. La semana siguiente: 430. Un récord histórico.
Del 1 al 7 de junio de 2026: Miasma / Hades. La estrategia de ataque volvió a cambiar. La oleada 1 publicó 90 versiones maliciosas de npm dirigidas a paquetes de Red Hat Cloud Services, no mediante el robo de tokens OIDC, sino abusando directamente del punto final de publicación de OIDC. La oleada 2 incorporó una técnica «binding.gyp» para eludir la detección de scripts de instalación. Para la cuarta oleada (Hades), la campaña se había extendido a PyPI mediante la ejecución de archivos .pth de inicio, contaminando 37 wheels en 19 paquetes. Red Hat publicó el boletín RHSB-2026-006. Esa semana: 209 paquetes nuevos.
El patrón y cómo se agravó
Los primeros ataques siguieron un guion ya conocido: suplantar la identidad de un administrador, robar un token de larga duración, publicar malware y propagarlo a todo aquello a lo que el token pudiera acceder. El caso «Debug/Chalk» fue un ataque de suplantación de identidad. El caso «Axios» se debió al compromiso de la cuenta de un administrador.
Pero los ataques más sofisticados se dirigieron directamente contra el propio proceso de integración continua (CI). Tanto S1ngularity como Shai-Hulud 2.0 utilizaron «Pwn Requests», es decir, pull requests maliciosas que aprovechaban la vulnerabilidad de los flujos de trabajo de GitHub Actions «pull_request_target» para ejecutar código del atacante dentro del contexto de confianza del repositorio upstream. No necesitaban robar un token almacenado; solo necesitaban que el ejecutor de CI tuviera uno.
Mini Shai-Hulud II fue el desenlace lógico de una evolución. Una vez que se controla el «runner», se pueden extraer todas las credenciales ambientales presentes, incluidos los tokens OIDC de corta duración. Los paquetes que publicaba parecían legítimos según todas las comprobaciones automatizadas: procedencia válida, identidad real del mantenedor, firma correcta. El ataque había evolucionado desde la explotación de secretos almacenados hasta la explotación del propio proceso de compilación.
Miasma se intensificó aún más. Ni siquiera necesitaba extraer un token: abusaba directamente del punto final de publicación de OIDC. Cada oleada introducía una nueva técnica para eludir la detección. Los análisis posteriores seguían señalando los mismos fallos. Los ataques seguían encontrando nuevas formas de sortear las soluciones recomendadas.
La superficie de ataque es ahora considerablemente menor que hace 18 meses. No porque el sector de la seguridad haya convencido a la gente, sino porque se introdujeron puertas traseras en los paquetes y, a raíz de ello, los responsables de su mantenimiento modificaron su configuración.
Eso no supone un avance para la formación en seguridad. Es un dato que refleja cómo se toman realmente las decisiones en materia de seguridad en la práctica.
¿Quién era este?
Durante la campaña «Shai-Hulud 2.0», el atacante cambió el nombre de su cuenta de GitHub por «UnknownWonderer1», lo que casi con toda seguridad es una referencia a los «Zensunni Wanderers» de «Dune»: los nómadas perseguidos que se convirtieron en los fremen, la única cultura que aprendió a vivir en armonía con Shai-Hulud. El nombre no es obra de alguien que se topó por casualidad con el ecosistema. Es el nombre de alguien que lo había estado meditando.
El diseño del malware refuerza esa interpretación. S1ngularity no se limitó a sustraer credenciales de forma silenciosa, sino que inyectó un comando de apagado en el perfil del shell, algo que, visiblemente, bloquearía tu ordenador la próxima vez que abrieras un terminal. Ese no es el comportamiento de alguien que intente pasar desapercibido. Todas las campañas se quedaron muy por debajo de lo que podrían haber logrado. Un gusano que se propaga por sí mismo a más de 700 paquetes, pero que modera su carga útil, está tomando una decisión.
Además, comprendían la estructura de incentivos mejor que el propio ecosistema. A los mantenedores rara vez se les paga por proteger los paquetes. El impacto de una brecha recae sobre los usuarios finales, no sobre la persona que dejó el token en el entorno de integración continua. Las plataformas con poder para exigir una publicación segura son las que menos sufren cuando las cosas salen mal. Se trata de un clásico fracaso de la acción colectiva, y 40 000 paquetes desprotegidos tras tres años de avisos es precisamente lo que produce esa estructura. Este atacante entendió por qué no se movía nada. Y decidió ejercer un tipo diferente de presión.
Disparos de advertencia
Ya escribí sobre esto en su momento: el nombre, la moderación en el diseño del malware y la forma en que los ataques se detenían sistemáticamente antes de llegar a una explotación total. Mi interpretación es que Shai-Hulud no era, ante todo, una operación delictiva. Era un mensaje —de alguien que entendía el ecosistema lo suficientemente bien como para saber exactamente qué puntos sensibles lo harían reaccionar—.
Los fremen rezan para que el paso del Creador purifique el mundo. El atacante parece haber llegado a una conclusión similar: solo el dolor visible obligaría al ecosistema a enfrentarse a lo que hizo posible la existencia del gusano. Para los fremen, Shai-Hulud no es simplemente un animal destructivo. Es el Creador. Su paso arrasa el desierto, pero también purifica y hace cumplir las leyes por las que debe regirse todo en ese ecosistema.
No se limitaron a liberar a Shai-Hulud.
Decidieron interpretar al Errante, que entendía por qué tenía que llegar ese momento.
Por qué todavía no lo hemos solucionado
Se lanzó la advertencia. El ecosistema no reaccionó con la suficiente rapidez. El manual de estrategias de Shai-Hulud, de código abierto, fue entonces adoptado por actores que no tenían ningún interés en enviar un mensaje: TeamPCP, Sapphire Sleet y otros que se centraron directamente en el robo de credenciales, carteras de criptomonedas y acceso remoto. Marcos de trabajo como Mastra se convirtieron en víctimas. El gusano que comenzó como una demostración se convirtió en una plantilla.
Lo frustrante es que el obstáculo no es una dificultad técnica. Trusted Publishing es gratuito y solo lleva diez minutos. El problema es que el coste de no hacerlo aún no ha recaído sobre la persona adecuada. Los mantenedores asumen el riesgo reputacional si su paquete se ve comprometido, pero el daño real recae en los equipos que se encuentran más abajo en la cadena y que no han escrito ni una sola línea del paquete afectado. Esa falta de alineación es estructural. Los ataques provocan un aumento temporal de la adopción, luego la urgencia se desvanece y la siguiente tanda de paquetes vuelve por defecto a utilizar tokens de larga duración.
Fíjate en el gráfico. Los picos son reales. Y también lo es el descenso entre ellos.
Y Mini Shai-Hulud añadió un nuevo matiz: incluso los paquetes que adoptan Trusted Publishing pueden verse comprometidos si el proceso de integración continua (CI) subyacente no está bien protegido. Extraer un token OIDC de la memoria del ejecutor es más difícil que robar un secreto almacenado. Pero no es imposible, y el ataque cuenta ahora con una prueba de concepto pública. Trusted Publishing elimina un vector de ataque. No los elimina todos.
La falta de rendición de cuentas y cómo abordarla
Axios registraba más de 100 millones de descargas semanales y aún no había adoptado Trusted Publishing cuando Corea del Norte lo vulneró. Alguien podría haber presentado una solicitud de corrección un año antes. Nadie lo hizo.
Esa es la brecha de responsabilidad. La comunidad de seguridad publica avisos, redacta análisis retrospectivos y espera a que el próximo ataque marque la diferencia. Existe una versión más constructiva de esa misma presión: actuar de forma proactiva sobre los 40 000 paquetes que aún no han cambiado, del mismo modo que Let’s Encrypt actuó con respecto al HTTP. Envía solicitudes de incorporación de cambios. Abre incidencias. Identifica los paquetes más descargados que siguen utilizando tokens de larga duración. Haz que el coste social de no adoptar TP sea mayor que los diez minutos que se tarda en solucionarlo.
Este es el tipo de activismo que el ecosistema realmente necesita. No otro aviso de la CISA. No otra entrada de blog que se lee y se olvida. Una presión concreta, específica e incómoda sobre los responsables de mantenimiento de paquetes concretos —aquellos con más de 10 millones de descargas semanales que siguen estando a solo una credencial suplantada de convertirse en el próximo incidente—.
El sector de la seguridad sabe cuál es la solución desde hace tres años. La cuestión es si estamos dispuestos a hacer que sea socialmente inaceptable ignorarla.
40 000 de los 51 000 paquetes más populares aún no se han cambiado
11.001 paquetes han adoptado Trusted Publishing. Esos 11.000 representan aproximadamente el 25 % del volumen total de descargas, ya que algunos de los paquetes más importantes se pasaron a este sistema tras cada oleada de ataques. Sin embargo, eso significa que 40.369 paquetes (el 75 % del volumen de descargas) siguen publicándose con tokens de larga duración.
Si mantienes un paquete de npm, hazlo ahora mismo. La documentación está aquí. Son cuatro líneas de YAML y una casilla de selección. A continuación, asegúrate de que tus flujos de trabajo de GitHub Actions no incluyan «pull_request_target» sin límites de confianza explícitos; ese es el vector que utilizó Mini Shai-Hulud para extraer el token OIDC incluso después de que TP estuviera en funcionamiento.
Si dependes de paquetes que aún no se han actualizado, crea una incidencia. Abre una solicitud de incorporación de cambios. Es posible que el responsable del mantenimiento no sepa que existe Trusted Publishing, o quizá solo necesite que alguien le haga ver que la inacción resulta más incómoda que la corrección de diez minutos.
El gusano de arena de «Dune» se llama Shai-Hulud, que significa «el gran anciano del desierto». Los fremen no se alegran cuando destruye algo. Entienden que su paso configura el ecosistema de una forma que nada más puede igualar.
Esa es la incómoda verdad que subyace a esta entrada. Los ataques surtieron efecto. El dolor logró un impacto que tres años de avisos no habían conseguido.
Hemos aprendido la lección. El ecosistema reacciona ante la presión, y esta no tiene por qué provenir de un gusano. El Errante comprendió por qué el Creador tuvo que venir. Estamos trabajando para que el próximo no sea necesario.
Pronto daremos más detalles al respecto.
