Para los defensores, tener el código real ofrece una oportunidad poco común para estudiar el funcionamiento interno de un gusano de cadena de suministro moderno. Para los atacantes, reduce significativamente el esfuerzo necesario para replicar o adaptar la técnica.
La campaña Shai‑Hulud llamó la atención por su velocidad y escala. El 11 de mayo de 2026, los atacantes distribuyeron versiones maliciosas de paquetes populares en npm y PyPI, publicando cientos de versiones infectadas en cuestión de horas.
A diferencia de muchos incidentes de dependencias comprometidas, este malware actuaba como un gusano capaz de autopropagarse dentro de los ecosistemas de desarrollo una vez que los paquetes iniciales eran instalados.
Poco después del ataque, investigadores detectaron que TeamPCP había publicado el código completo del gusano en dos repositorios de GitHub con licencia MIT, permitiendo su reutilización sin restricciones. En pocas horas ya existían decenas de forks, evidencia de lo rápido que el código puede circular dentro del ecosistema open source.
Publicar malware con una licencia de código abierto permisiva es poco habitual, y tiene implicaciones importantes.
Para los equipos defensivos, el acceso al código real permite:
Para los atacantes, el efecto es el contrario: la barrera de entrada baja considerablemente. La licencia MIT permite copiar, modificar y redistribuir el código con mínimas restricciones, lo que facilita adaptarlo a nuevos ecosistemas de paquetes o técnicas de evasión.
La preocupación principal es que Shai‑Hulud no representa solo un exploit puntual, sino un patrón reproducible de ataque contra flujos de trabajo de desarrollo confiables.
Los análisis del incidente muestran que el malware combina varias técnicas avanzadas dirigidas a la cadena de suministro de software.
Una de las capacidades más importantes es la extracción de tokens OpenID Connect (OIDC) desde pipelines de CI/CD, especialmente en flujos de GitHub Actions usados para publicar paquetes.
En lugar de depender solo de credenciales robadas previamente, el ataque captura tokens temporales generados durante el proceso de build o publicación, permitiendo a los atacantes publicar paquetes maliciosos directamente desde pipelines legítimos.
El ataque también rompe una suposición clave de seguridad en la cadena de suministro moderna: que la procedencia firmada implica confianza.
Investigaciones indican que algunos paquetes comprometidos se publicaron con atestaciones de procedencia SLSA Build Level 3 válidas, lo que hacía que parecieran generados por pipelines legítimos aunque contenían malware.
Esto permitió que muchos sistemas automáticos de verificación aceptaran los paquetes como legítimos.
Una vez instalado, el gusano desplegaba un payload de robo de credenciales diseñado para recolectar secretos de estaciones de trabajo y entornos CI. Entre los datos buscados estaban:
Algunos análisis indican que el malware revisaba más de 100 rutas comunes de almacenamiento de credenciales en los sistemas comprometidos.
Con las credenciales robadas y pipelines comprometidos, el gusano podía publicar versiones infectadas de otros paquetes, expandiendo la infección dentro del ecosistema de dependencias.
Este comportamiento es lo que lo convierte en un verdadero gusano de cadena de suministro.
Informes de seguridad también mencionan un posible mecanismo destructivo o "interruptor de hombre muerto", que podría activar la eliminación de datos si se cumplen determinadas condiciones.
Debido a esta posibilidad, los expertos recomiendan tratar los sistemas afectados como completamente comprometidos.
La campaña de mayo de 2026 no fue el primer incidente atribuido a este grupo.
Investigaciones de la Cloud Security Alliance documentan un ataque anterior entre el 29 y 30 de abril de 2026 que afectó simultáneamente a npm, PyPI y Packagist, alcanzando aproximadamente 1.800 repositorios mediante credenciales expuestas y configuraciones débiles de CI/CD.
La ola posterior con Shai‑Hulud representó una evolución clara:
Este salto técnico muestra cómo los atacantes están adaptándose rápidamente a las nuevas defensas de la cadena de suministro.
Las organizaciones que instalaron paquetes afectados durante la ventana del ataque enfrentan varios riesgos.
Las guías de seguridad recomiendan tratar cualquier entorno que haya instalado esos paquetes como potencialmente comprometido, ya que el gusano roba credenciales y puede persistir en estaciones de trabajo y pipelines CI.
Otra conclusión clave del incidente: una procedencia firmada no garantiza seguridad si el pipeline que generó el artefacto fue comprometido.
Los equipos de seguridad deberían priorizar varias medidas:
También es importante vigilar nuevas variantes, ya que la publicación del código fuente aumenta la probabilidad de ataques derivados o imitadores en el ecosistema open source.
El incidente Shai‑Hulud refleja un cambio importante en los ataques modernos: los adversarios ya no se centran solo en vulnerabilidades del software, sino en los propios flujos de trabajo de desarrollo.
Al publicar el gusano que impulsó uno de los ataques más amplios contra npm y PyPI, TeamPCP convirtió un incidente real en un modelo técnico que ahora puede estudiarse públicamente. La carrera por comprenderlo —y defenderse de él— ya está en marcha.