Solo ha pasado un día desde que el segundo ataque a la cadena de suministro de Shai Hulud se propagó por todo el ecosistema, y nuevos usuarios y organizaciones siguen siendo comprometidos cada hora. Mientras analizamos las consecuencias, estamos empezando a descubrir el vector de infección inicial que los atacantes utilizaron para comprometer proyectos importantes como AsyncAPI, PostHog y Postman, y está quedando claro que aún no hemos visto el alcance total de esta campaña. Al explotar vulnerabilidades sutiles pero potentes en los flujos de trabajo de GitHub Actions, los atacantes demostraron una preocupante evolución en sus métodos de entrega. Esto es un fuerte recordatorio de que nuestras defensas deben evolucionar con la misma rapidez y que la seguridad del ecosistema de código abierto depende de endurecer continuamente la infraestructura que a menudo damos por sentada.
Cronología de la Campaña Shai-Hulud
- 27 de agosto - Publicamos nuestro informe detallando la campaña S1ngularity dirigida a varios paquetes nx en npm.
- 16 de septiembre - El atacante vuelve a atacar, lanzando la primera oleada de los ataques Shai-Hulud.
- 18 de septiembre - Publicamos un análisis de seguimiento, profundizando en las particularidades técnicas de la campaña y el comportamiento inicial de la carga útil.
- 24 de noviembre - Se produce un segundo ataque, denominado 'Second Coming' por los atacantes, programado justo antes de la fecha límite de npm para revocar tokens antiguos.
- 25 de noviembre - Descubrimos el vector de entrada inicial de los atacantes a través de flujos de trabajo vulnerables de GitHub Actions en proyectos como AsyncAPI, PostHog y Postman.
Un repaso rápido
Desde la brecha de Nx y el ataque Shai Hulud, sabemos que el atacante ha estado abusando de los flujos de trabajo de GitHub Actions para exfiltrar datos a través de enlaces de webhook.site. En incidentes anteriores, el método era sencillo. El atacante plantó una puerta trasera deliberada dentro de un archivo de flujo de trabajo, y esa puerta trasera transmitió silenciosamente información sensible, incluidas las credenciales, a un endpoint controlado por el atacante.
Lo que estamos viendo en la última oleada de la campaña Shai Hulud es más avanzado. En lugar de insertar puertas traseras directamente, los atacantes ahora están explotando vulnerabilidades en los flujos de trabajo existentes de GitHub Actions para ejecutar su ataque. Este cambio de técnica es lo que les permitió comprometer proyectos como AsyncAPI, PostHog y Postman en el ataque Shai-Hulud de ayer.
Nuestra investigación comenzó cuando notamos varias subidas sospechosas a NPM vinculadas a nombres de usuario inesperados como 'codespace' y 'runner'. Estas subidas destacaron inmediatamente como anomalías, y un análisis más profundo mostró que todas fueron probablemente sembradas manualmente por el atacante a través de la explotación de GitHub Actions. Posteriormente fuimos notificados por un tercero sobre una extensión maliciosa de OpenVSX relacionada con un patrón similar. Este descubrimiento confirmó que los atacantes han evolucionado sus métodos y ahora están aprovechando las malas configuraciones de CI como parte de su cadena de intrusión.
Cómo el atacante utilizó las vulnerabilidades de GitHub Actions
Los flujos de trabajo de GitHub Actions son scripts automatizados que se ejecutan dentro de un repositorio para manejar tareas como pruebas, compilación, publicación o gestión de pull requests. Son potentes y flexibles, pero ese poder conlleva riesgos, especialmente cuando los flujos de trabajo se configuran sin una comprensión completa de cómo ejecutan código no confiable.
Ciertos disparadores de flujo de trabajo, incluyendo pull_request_target y workflow_run, pueden volverse peligrosos cuando están mal configurados. Esto es exactamente lo que sucedió en el caso de PostHog, como se muestra en la captura de pantalla. El problema fue inicialmente puesto en conocimiento general por Adnan Khan, un investigador de seguridad que destacó el flujo de trabajo vulnerable en una publicación de X. El ataque fue probablemente causado por una vulnerabilidad dentro del .github/workflows/auto-assign-reviewers.yml flujo de trabajo. Ese archivo utilizaba el arriesgado pull_request_target disparador de una manera que permitía que el código proporcionado por cualquier nueva solicitud de extracción (pull request) se ejecutara durante la ejecución de CI. La vulnerabilidad se introdujo por primera vez el 11 de septiembre de 2025 a través de una pull request fusionada, donde permaneció disponible hasta el ataque de Shai Hulud. En total, el problema estuvo presente durante 74 días antes de que el atacante lo explotara.
Un patrón similar aparece en el repositorio de AsyncAPI. Descubrimos que su .github/workflows/auto-changeset.yml archivo contenía una configuración vulnerable añadida el 9 de septiembre de 2025. El equipo de AsyncAPI ha eliminado el archivo siguiendo nuestra recomendación, pero la configuración estuvo disponible el tiempo suficiente para que el atacante incluyera este proyecto en la campaña.
Cabe destacar que uno de estos proyectos ya utilizaba una herramienta de escaneo de PR, pero aun así no detectó las vulnerabilidades ocultas dentro de los flujos de trabajo de GitHub Actions. En el caso de PostHog, GitHub advirtió sobre la vulnerabilidad, pero esa advertencia no fue atendida. Esto subraya la necesidad de herramientas de seguridad que puedan comprender y señalar problemas en una amplia gama de sistemas y lenguajes, incluidas las vulnerabilidades de configuración de CI. Una vez que un atacante identifica un flujo de trabajo explotable en un proyecto, esa única debilidad puede servir como punto de apoyo para un ataque que se propaga a una escala nunca vista, como demostró el gusano Shai Hulud.
Lo que debes saber y acciones a tomar
A medida que estas amenazas continúan evolucionando, se vuelve cada vez más importante comprender cómo las vulnerabilidades en los flujos de trabajo de GitHub Actions pueden exponer no solo tu propio proyecto, sino cada proyecto y usuario conectado a él. Una única configuración errónea puede convertir un repositorio en un paciente cero para un ataque de rápida propagación, dando a un adversario la capacidad de introducir código malicioso a través de pipelines automatizados en los que confías cada día. Los desarrolladores solo pueden defenderse de lo que conocen, por lo que la concienciación sobre patrones de flujo de trabajo peligrosos como pull_request_target y workflow_run es esencial. Otra opción es utilizar una plataforma de seguridad como Aikido que escanea automáticamente los repositorios y las solicitudes pull entrantes en busca de este tipo de vulnerabilidades.
Es igualmente importante estar al tanto de las vulnerabilidades en las dependencias que instalas. Aunque tus propios flujos de trabajo sean seguros, los paquetes comprometidos en la cadena de suministro pueden introducir riesgos. Aquí es donde las capacidades de SCA de Aikido, la Intel Vulnerability Database y las perspectivas de Package Health son especialmente útiles, ayudando a los equipos a detectar problemas a tiempo y a comprender si las bibliotecas en las que confían muestran signos de compromiso o actividad sospechosa.
Finalmente, disponer de una herramienta que pueda detener el malware en tiempo real a medida que aparece puede prevenir una infección grave. Esta es la idea detrás de Aikido Safe Chain, una herramienta gratuita que se integra con npm y utiliza tanto IA como investigadores de malware humanos para detectar y bloquear los últimos riesgos de la cadena de suministro antes de que entren en tu entorno.
