Solo ha pasado un día desde que el segundo ataque a la cadena de suministro de Shai Hulud se extendió por todo el ecosistema, y cada hora siguen viéndose afectados nuevos usuarios y organizaciones. A medida que analizamos las consecuencias, estamos empezando a descubrir el vector de infección inicial que utilizaron los atacantes para comprometer proyectos importantes como AsyncAPI, PostHog y Postman, y cada vez está más claro que aún no hemos visto el alcance total de esta campaña. Al explotar vulnerabilidades sutiles pero poderosas en los flujos de trabajo de GitHub Actions, los atacantes demostraron una preocupante evolución en sus métodos de entrega. Esto nos recuerda que nuestras defensas deben evolucionar con la misma rapidez y que la seguridad del ecosistema de código abierto depende del refuerzo continuo de la infraestructura que a menudo damos por sentada.
Cronología de la campaña Shai-Hulud
- 27 de agosto: publicamos nuestro informe detallado sobre la campaña S1ngularity dirigida a varios paquetes nx en npm.
- 16 de septiembre: el atacante vuelve a la carga y lanza la primera oleada de ataques Shai-Hulud.
- 18 de septiembre: publicamos un análisis de seguimiento en el que profundizamos en las peculiaridades técnicas de la campaña y el comportamiento inicial de la carga útil.
- 24 de noviembre: se produce un segundo ataque, bautizado como «Second Coming» (Segunda venida) por los atacantes, justo antes de la fecha límite fijada por npm para revocar los 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 de Shai Hulud, sabemos que el atacante ha estado abusando de los flujos de trabajo de GitHub Actions para filtrar datos a través de enlaces webhook.site. En incidentes anteriores, el método era sencillo. El atacante colocaba deliberadamente una puerta trasera dentro de un archivo de flujo de trabajo, y esa puerta trasera transmitía silenciosamente información confidencial, incluidas credenciales, a un punto final 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 en la 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 detectamos varias subidas sospechosas a NPM vinculadas a nombres de usuario inesperados, como «codespace» y «runner». Estas subidas llamaron inmediatamente la atención por ser anómalas, y un análisis más profundo reveló que probablemente habían sido introducidas manualmente por el atacante mediante la explotación de GitHub Actions. Más tarde, un tercero nos notificó la existencia de una extensión OpenVSX maliciosa relacionada con un patrón similar. Este descubrimiento confirmó que los atacantes han evolucionado sus métodos y ahora aprovechan las configuraciones erróneas de CI como parte de su cadena de intrusión.
Cómo utilizó el atacante las vulnerabilidades de GitHub Actions
Los flujos de trabajo de GitHub Actions son scripts automatizados que se ejecutan dentro de un repositorio para gestionar tareas como pruebas, compilación, publicación o gestión de solicitudes de extracción. Son potentes y flexibles, pero esa potencia conlleva riesgos, especialmente cuando los flujos de trabajo se configuran sin comprender completamente cómo ejecutan código no confiable.
Ciertos desencadenantes del flujo de trabajo, incluidos objetivo_de_solicitud_de_extracción y ejecución_del_flujo_de_trabajo, puede resultar peligroso si se configura incorrectamente. Esto es precisamente lo que ocurrió en el caso de PostHog, como se muestra en la captura de pantalla. El problema saltó a la palestra por primera vez gracias a Adnan Khan, un investigador de seguridad que destacó el flujo de trabajo vulnerable en una publicación de X. Es probable que el ataque haya sido causado por una vulnerabilidad dentro del .github/workflows/asignación-automática-de-revisores.yml flujo de trabajo. Ese archivo utilizaba el arriesgado objetivo_de_solicitud_de_extracción activarse de tal manera que permitiera ejecutar el código proporcionado por cualquier nueva solicitud de extracción durante la ejecución de la integración continua. La vulnerabilidad se introdujo por primera vez el 11 de septiembre de 2025 a través de una solicitud de extracción fusionada, donde permaneció disponible hasta el ataque Shai Hulud. En total, el problema estuvo presente durante 74 días antes de que el atacante lo explotara.
En el repositorio de AsyncAPI se observa un patrón similar. Descubrimos que su .github/workflows/auto-changeset.yml El 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 análisis de relaciones públicas, pero aun así no logró detectar las vulnerabilidades ocultas en los flujos de trabajo de GitHub Actions. En el caso de PostHog, GitHub advirtió sobre la vulnerabilidad, pero esa advertencia no se tuvo en cuenta. Esto pone de relieve la necesidad de contar con 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 de punto de apoyo para un ataque que se propague a una escala nunca antes vista, como lo demostró el gusano Shai Hulud.
Lo que debe saber y las medidas que debe tomar
A medida que estas amenazas siguen evolucionando, cada vez es más importante comprender cómo las vulnerabilidades en los flujos de trabajo de GitHub Actions pueden exponer no solo su propio proyecto, sino todos los proyectos y usuarios conectados a él. Una sola configuración incorrecta puede convertir un repositorio en el paciente cero de un ataque de rápida propagación, lo que da al adversario la capacidad de introducir código malicioso a través de los canales automatizados en los que usted confía cada día. Los desarrolladores solo pueden defenderse de lo que conocen, por lo que es importante conocer los patrones de flujo de trabajo peligrosos, como objetivo_de_solicitud_de_extracción y ejecución_del_flujo_de_trabajo es esencial. Otra opción es utilizar una plataforma de seguridad como Aikido, que analiza automáticamente los repositorios y las solicitudes de extracción entrantes en busca de este tipo de vulnerabilidades.
Es igualmente importante ser consciente de las vulnerabilidades de las dependencias que se instalan. Aunque los flujos de trabajo propios sean seguros, los paquetes comprometidos en el origen pueden seguir suponiendo un riesgo. Aquí es donde SCA de Aikido, la base de datos de vulnerabilidades de Intel y la información sobre el estado de los paquetes resultan especialmente útiles, ya que ayudan a los equipos a detectar problemas de forma temprana y a comprender si las bibliotecas en las que se basan muestran signos de compromiso o actividad sospechosa.
Por último, disponer de una herramienta capaz de detener el malware en tiempo real tan pronto como aparece puede evitar infecciones graves. Esta es la idea que subyace a Aikido Safe Chain, una herramienta gratuita que envuelve npm y utiliza tanto inteligencia artificial como investigadores humanos especializados en malware para detectar y bloquear los últimos riesgos de la cadena de suministro antes de que entren en su entorno.
Protege tu software ahora.
.avif)
