La lección sobre la cadena de suministro que nos enseñan Shai-Hulud y el megalodón

La versión resumida

Qué: Shai-Hulud y Megalodon fueron ataques a la cadena de suministro de software perpetrados en 2026 que tuvieron como objetivo los sistemas en los que más confían los desarrolladores: registros de paquetes, flujos de trabajo de GitHub Actions, ejecutores de CI/CD, canalizaciones de procedencia y federación de identidades en la nube.

Repercusión: Mini Shai-Hulud comprometió paquetes de npm y PyPI, incluidos paquetes vinculados a TanStack, Mistral AI, Guardrails AI, UiPath y OpenSearch, y fue el primer ataque ampliamente documentado en distribuir malware con una procedencia válida de nivel 3 de SLSA (CVE-2026-45321, CVSS 9,6). Posteriormente, Megalodon realizó 5.718 commits maliciosos en 5.561 repositorios de GitHub en unas seis horas, introduciendo puertas traseras en los flujos de trabajo de GitHub Actions para robar credenciales de la nube, claves SSH, tokens de GitHub, datos de tokens OIDC y secretos del código fuente.

Situación: Estas campañas ya no son noticia de última hora, pero la lección sigue siendo de actualidad. Cualquier credencial expuesta, flujo de trabajo inactivo pero malicioso, versión de paquete comprometida o política de confianza de CI/CD excesivamente amplia que no se haya subsanado puede seguir generando riesgos en fases posteriores del proceso.

Gravedad: Gran impacto en la cadena de suministro. No se trata de un único paquete vulnerable ni de un único CVE al que se pueda aplicar un parche y dar por zanjado el asunto. Se trata de un patrón de ataque repetible dirigido contra los sistemas que desarrollan y publican software.

Por qué es importante para la incorporación de paquetes: Megalodon se aprovechó de la brecha entre el código fuente y la publicación. El atacante no necesitaba comprometer la cuenta de npm, ya que un mantenedor legítimo podía publicar sin saberlo a partir de un código fuente contaminado. Este es el tipo de brecha que SecureChain está diseñado para cerrar, analizando las nuevas versiones de los paquetes en el momento de su incorporación, incluyendo diferencias en el código fuente, hooks en tiempo de compilación, cargas útiles ofuscadas, rutas de ejecución ocultas y comportamientos de exfiltración, antes de que una versión sea considerada fiable en las fases posteriores.

Hazlo ahora mismo: revisa los flujos de trabajo de GitHub Actions, comprueba si hay indicadores de Megalodon, renueva cualquier clave secreta expuesta a ejecutores de CI sospechosos, revisa la incorporación de paquetes afectados y refuerza las políticas de confianza de OIDC.

¿Me afecta esto?

Es posible que te veas afectado si tu organización:

• Utiliza GitHub Actions para la compilación, las pruebas, las versiones, la publicación de paquetes o la implementación
• Permite que los flujos de trabajo soliciten un token de identificación: escritura
• Almacena credenciales de la nube, del registro, de SSH, de Docker, de Kubernetes, de Terraform o de Vault en CI/CD
• Utiliza paquetes de npm o PyPI procedentes de registros públicos sin controles de admisión adicionales
• Paquetes Mini Shai-Hulud afectados instalados durante la ventana de exposición de mayo de 2026
• Se han instalado las versiones 2.18.6 a 2.18.12 de @tiledesk/tiledesk-server
• Permite realizar envíos directos a las ramas predeterminadas
• No requiere revisión para los cambios en .github/workflows
• Considera la procedencia, la firma o un editor de paquetes conocido como prueba de que una dependencia es segura

Un buen punto de partida es buscar en los repositorios los nombres conocidos de los flujos de trabajo de Megalodon y la dirección C2:

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

A continuación, busca la ejecución de comandos de shell encriptados dentro de los flujos de trabajo:

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

Si alguna de las búsquedas arroja resultados inesperados, revisa el historial del repositorio y los registros de CI antes de eliminar archivos o renovar las credenciales. Es posible que se necesiten los registros para comprender qué se ejecutó, cuándo se ejecutó y qué secretos quedaron expuestos.

Qué son el Shai-Hulud y el Megalodón

Shai-Hulud es el nombre que se le ha dado a una familia de ataques en la cadena de suministro que se propagan de forma autónoma y que tienen como objetivo los ecosistemas de desarrolladores, especialmente npm y PyPI.

El gusano original apareció en septiembre de 2025, cuando Unit 42 documentó un gusano npm autorreplicante que recopilaba credenciales y las utilizaba para propagarse. En noviembre apareció una variante más extendida, Shai-Hulud 2.0. Para la primavera de 2026, el actor malicioso identificado como TeamPCP llevaba meses incorporando puertas traseras en herramientas de desarrollo y de seguridad de alta confianza.

«Mini Shai-Hulud», la oleada de mayo de 2026, subió el listón. No se limitó a publicar paquetes maliciosos a través de cuentas claramente sospechosas, sino que comprometió procesos de compilación legítimos y los utilizó para generar paquetes maliciosos que contaban con certificados de procedencia válidos.

Megalodon actuó a otro nivel. En lugar de centrarse en la publicación de paquetes, inyectó masivamente flujos de trabajo de GitHub Actions en miles de repositorios. Esos flujos de trabajo se ejecutaron dentro de los runners de CI y robaron los secretos que los sistemas de CI/CD guardan por diseño: credenciales de la nube, tokens de GitHub, claves SSH, datos de solicitud de tokens OIDC, credenciales de Docker, configuraciones de Kubernetes, credenciales de Terraform, tokens de Vault y secretos del código fuente.

En conjunto, ambas campañas ponen de manifiesto la misma tendencia. Los atacantes ya no se limitan a intentar corromper el paquete que instalas. Intentan corromper el sistema que lo compila, lo firma, lo publica y lo implementa.

Primera oleada: el mini Shai-Hulud y el problema del SLSA

El momento más destacado de Mini Shai-Hulud tuvo lugar el 11 de mayo de 2026 a las 19:20 UTC, cuando se publicaron 84 artefactos maliciosos repartidos en 42 paquetes del espacio de nombres @tanstack en un intervalo de seis minutos. Los paquetes parecían proceder del canal de lanzamiento real de TanStack, utilizando su identidad OIDC real.

Eso es porque lo hicieron.

El mecanismo, al que se le ha asignado el CVE-2026-45321 (CVSS 9,6), encadenaba tres vulnerabilidades conocidas de GitHub Actions en una sola ruta:

1. Un disparador «pull_request_target» que se ejecuta con acceso de escritura incluso cuando la solicitud de incorporación de cambios que lo activa procede de una bifurcación, lo que proporciona el punto de apoyo.
2. Manipulación de la caché de GitHub Actions, utilizada para introducir una dependencia modificada en la compilación legítima.
3. Robo de un token OIDC activo de la memoria del proceso «runner», utilizado para obtener un certificado de firma Sigstore válido.

Con un certificado de firma auténtico procedente de un canal real, el gusano generó certificados de procedencia SLSA de nivel 3 válidos para los paquetes maliciosos.

Esta es la parte que debería cambiar la forma en que los equipos conciben la procedencia.

Esto no significa que SLSA haya fallado en lo que se pretendía que hiciera. Significa que muchos equipos están planteando a la procedencia una pregunta para la que no tiene respuesta. La procedencia puede mostrar de dónde procede un artefacto y si se ha compilado siguiendo el proceso previsto. En este caso, esa garantía era técnicamente cierta, ya que los paquetes maliciosos realmente se habían compilado siguiendo el proceso previsto. El problema era que el propio proceso se había visto comprometido.

SLSA certifica la integridad de la compilación. No demuestra que el código introducido en la compilación fuera seguro, que el flujo de trabajo no se viera contaminado ni que el entorno del responsable del mantenimiento no se hubiera visto comprometido en la fase previa. Esa distinción no es meramente teórica: la oleada de imitaciones del 1 de junio contra el espacio de nombres @redhat-cloud-services distribuyó paquetes maliciosos que, cada uno de ellos, contaban con una procedencia npm válida, publicada a través de GitHub Actions OIDC desde una cuenta de empleado comprometida. La procedencia hizo exactamente lo que promete. Simplemente no promete lo que los equipos dan por sentado.

El gusano se propagó a 172 paquetes de npm y a un par de paquetes de PyPI a través de 404 versiones maliciosas, llegando a ecosistemas vinculados a TanStack, Mistral AI, Guardrails AI, UiPath y OpenSearch. La carga útil ofuscada, de 2,3 MB, rastreó más de 100 rutas de archivos en busca de datos confidenciales e instaló mecanismos de persistencia que sobrevivían al reinicio en herramientas de desarrollo, entre ellas Claude Code y Visual Studio Code. Según los informes públicos, los paquetes afectados sumaban más de 518 millones de descargas en total [verificar la cifra exacta antes de publicar; las fuentes difieren en si se trata de una cifra acumulada o semanal], por lo que se trató de un problema de dependencias en la cadena de suministro para cualquier organización que obtuviera paquetes de los registros públicos durante ese periodo, y no solo de un incidente por parte de los mantenedores.

Un día después, el 12 de mayo, TeamPCP publicó el marco completo de Shai-Hulud en código abierto en GitHub bajo una licencia MIT, al parecer junto con un concurso que ofrecía 1.000 dólares en Monero al autor del mayor ataque a la cadena de suministro creado con él. Una capacidad perfeccionada a lo largo de meses se convirtió en algo que cualquier atacante competente podía clonar en tan solo un fin de semana.

Una verificación de procedencia ecológica no es un veredicto sobre la seguridad. Es solo un indicio más en una decisión más amplia sobre la confianza.

Segunda oleada: el Megalodón y la revolución de CI/CD

Seis días después de ese lanzamiento de código abierto, llegó Megalodon.

Entre las 11:36 y las 17:48 UTC del 18 de mayo de 2026, la campaña realizó 5.718 commits maliciosos en 5.561 repositorios de GitHub. El atacante utilizó cuentas desechables con nombres de usuario aleatorios de ocho caracteres (rkb8el9r, bhlru9nr y similares) e identidades de autor falsificadas al estilo de los bots:

• build-bot
• auto-ci
• ci-bot
• bot-de-pipeline

Los mensajes de las confirmaciones se redactaron para que parecieran tareas de mantenimiento rutinario:

• ci: añadir un paso de optimización de la compilación
• Tarea: optimizar el tiempo de ejecución del proceso
• cambios similares relacionados con la interfaz de usuario que es fácil pasar por alto

El atacante no intentaba que el código de la aplicación pareciera malicioso. Lo que intentaba era que los cambios en el proceso parecieran aburridos.

Megalodon implementó dos variantes del flujo de trabajo de GitHub Actions; ambas solicitaban «id-token: write» y «actions: read», ejecutaban una carga útil de bash decodificada en base64 y se comunicaban con el mismo servidor C2 en la dirección 216.126.225.129:8443.

SysDiag era la variante más ruidosa y de mayor alcance. Incorporaba un flujo de trabajo que se activaba con cada solicitud de envío y de extracción, lo que maximizaba la frecuencia con la que se ejecutaba y recopilaba datos.

Optimize-Build era la variante silenciosa. Utilizaba `workflow_dispatch`, por lo que el flujo de trabajo podía permanecer inactivo hasta que se activara manualmente a través de la API de GitHub. Eso lo hace más útil como puerta trasera: sin compilaciones fallidas constantes, sin fallos evidentes y sin ningún motivo inmediato para que un mantenedor se diera cuenta.

La recopilación de datos por parte de la carga útil fue muy amplia. Recogió variables de entorno de CI y /proc/*/environ, credenciales de AWS de todos los perfiles configurados, tokens de Google Cloud, credenciales de roles de instancia extraídas de los puntos finales de AWS IMDSv2 y Azure IMDS, claves privadas SSH, credenciales de Docker, .npmrc, .netrc, Kubernetes, Vault y Terraform, el historial del shell, más de 30 patrones de expresiones regulares de claves API y cadenas de conexión y, lo más relevante, la URL de solicitud del token OIDC de GitHub Actions y el token correspondiente, junto con los tokens de GITHUB_TOKEN, GitLab y Bitbucket.

Por qué es importante el robo de la OIDC

Muchas organizaciones han dejado de utilizar claves de nube de larga duración en CI/CD y han optado por la federación OIDC. Es una buena decisión. En lugar de almacenar credenciales permanentes de AWS, Google Cloud o Azure en GitHub Actions, el flujo de trabajo solicita credenciales de corta duración cuando las necesita.

El megalodón pone de manifiesto que ese modelo aún necesita algunas medidas de seguridad.

Si un flujo de trabajo malicioso puede solicitar «id-token: write», puede obtener los datos de solicitud del token OIDC necesarios para suplantar la identidad de un flujo de trabajo de confianza. Si el ámbito de aplicación de la política de confianza en la nube correspondiente es demasiado amplio, ese flujo de trabajo malicioso puede generar credenciales de nube de corta duración en el propio equipo del atacante.

La cuestión no es que el OIDC sea malo. La cuestión es que la confianza en el OIDC debe ser limitada. Una configuración segura debería responder a lo siguiente:

• ¿Qué repositorio concreto puede solicitar este rol?
• ¿Qué rama, etiqueta o entorno está permitido?
• ¿Qué flujo de trabajo está permitido?
• ¿Es realmente necesario el «id-token: write» en este flujo de trabajo?
• ¿Puede un flujo de trabajo recién añadido heredar ese mismo nivel de confianza?
• ¿Puede un flujo de trabajo de una rama que no sea de lanzamiento solicitar credenciales de producción?

Si la política de confianza establece, en la práctica, que «este repositorio es de confianza», el alcance del impacto es mayor de lo necesario. El OIDC reduce el riesgo que suponen los secretos estáticos de larga duración. Sin embargo, no resuelve el problema de la ejecución de flujos de trabajo contaminados.

El caso de Tiledesk pone de manifiesto el riesgo derivado

El Megalodon no era solo un problema del propietario del repositorio.

Al menos un paquete dependiente, @tiledesk/tiledesk-server, se publicó en una versión comprometida en las versiones 2.18.6 a 2.18.12. Un detalle importante es que la cuenta de npm no fue el punto inicial del ataque. El atacante contaminó el repositorio de código fuente inyectando archivos maliciosos de flujos de trabajo de GitHub Actions, y el mantenedor legítimo publicó, sin saberlo, versiones a partir de ese código fuente contaminado.

Por eso la autenticación de dos factores (2FA) y la firma de código no fueron suficientes. El evento de publicación seguía pareciendo legítimo, ya que el atacante nunca tuvo que hacerse con el control de la cuenta de npm. Ambos controles confirmaron que la versión procedía del verdadero responsable del mantenimiento, lo cual era cierto. La brecha de integridad se produjo antes, entre el código fuente y la publicación.

Por eso también es importante el análisis de diferencias entre códigos fuente. Un detector que compare una nueva versión de un paquete con su versión anterior en el momento de su incorporación examinaría el cambio de la versión 2.18.5 a la 2.18.6 antes de dar por fiable la nueva versión. Los archivos de flujo de trabajo y la carga útil inyectados encajan perfectamente en las categorías que deberían activar las alarmas: ganchos de ejecución en tiempo de compilación, rutas de ejecución de tipo CI/CD, cargas útiles ofuscadas, ejecución oculta, recolección de credenciales y actividad de red sospechosa; es decir, el mismo tipo de puerta trasera que event-stream y ua-parser-js.

Esta es precisamente la laguna que SecureChain ha sido diseñado para subsanar. Al basar su análisis en las diferencias del código fuente en lugar de confiar en el evento de publicación, SecureChain está diseñado para detectar el escenario en el que el mantenedor publica código fuente malicioso —algo que la firma, la procedencia y la autenticación de dos factores (2FA) del registro pasan por alto— y para proporcionar al equipo de seguridad un artefacto de razonamiento, fragmentos de diferencias marcados, una justificación y un veredicto, antes de que la versión se distribuya a las fases posteriores del proceso.

 

La cascada en su conjunto tiene este aspecto:

1. Se produce una modificación en un repositorio mediante un acceso robado o utilizado indebidamente.
2. Se inserta o se sustituye un flujo de trabajo de GitHub Actions.
3. El flujo de trabajo se ejecuta en un entorno de integración continua (CI) de confianza.
4. Los secretos se extraen del corredor.
5. Un paquete puede compilarse o publicarse a partir de un código fuente alterado.
6. Los usuarios finales instalan lo que parece ser un paquete legítimo.

Desde el punto de vista del consumidor, el nombre del paquete resulta familiar, el editor es legítimo y la publicación procede de la cuenta esperada. Sin embargo, la fuente y el flujo de trabajo que hay detrás ya se habían visto comprometidos. «Editor de confianza» y «paquete seguro» no son lo mismo.

La polémica sobre la atribución y por qué no cambia tu respuesta

Aquí es donde la cobertura mediática se vuelve confusa.

TeamPCP está estrechamente relacionado con la actividad general de Shai-Hulud, incluidas campañas anteriores contra la cadena de suministro y la publicación, el 12 de mayo, del marco de trabajo del gusano. Algunas fuentes atribuyen Megalodon directamente a TeamPCP.

Una lectura más detallada revela que Megalodon presenta un marcado solapamiento en cuanto a técnicas de operación con la actividad al estilo Shai-Hulud, pero la atribución directa no está clara. OX Security, que analizó la carga útil de Megalodon, la calificó como muy probablemente una imitación, señalando un comportamiento y un estilo similares, pero con poco código compartido, sin vínculos directos, sin indicadores de identificación comunes y sin reivindicación de responsabilidad. Megalodon tampoco cuenta con la clave de cifrado pública que TeamPCP exige para participar en su propio concurso, por lo que ni siquiera se trata de una propuesta presentada al concurso. Mini Shai-Hulud presenta una fuerte atribución a TeamPCP; Megalodon presenta coincidencias circunstanciales. La atribución directa debe considerarse de baja fiabilidad.

Para los responsables de la seguridad, esa distinción no debería suponer ningún obstáculo. Tanto si Megalodon era TeamPCP, un imitador u otro actor que utilizaba herramientas de código abierto, la respuesta es la misma: buscar flujos de trabajo comprometidos, rotar los secretos expuestos, reforzar la OIDC, restringir los cambios en los flujos de trabajo y tratar los terminales de los desarrolladores y las identidades de CI/CD como parte de la cadena de suministro. Hay que defenderse contra el método, no contra la marca.

La causa principal es, además, menos exótica de lo que sugieren los nombres de las campañas. Hudson Rock cotejó los nombres de usuario de GitHub asociados a las contribuciones de Megalodon con su base de datos de programas de robo de información y descubrió que 331 de 978 (más de un tercio) coincidían con equipos ya infectados por este tipo de programas, lo que le llevó a concluir que el acceso procedía de los registros de dichos programas. La condición previa para ataques como este no suele ser un «zero-day» de GitHub. Se trata de una estación de trabajo de un desarrollador o un entorno de mantenimiento que ya había sido comprometido.

Por qué los escáneres tradicionales no detectan este tipo de ataques

La mayoría de los escáneres de vulnerabilidades están diseñados para responder a preguntas como:

• ¿Este paquete tiene algún CVE conocido?
• ¿Esta dependencia está desactualizada?
• ¿Utiliza este contenedor una biblioteca vulnerable?
• ¿Está este artefacto relacionado con algún malware conocido?

Esas preguntas siguen siendo importantes. Pero Shai-Hulud y Megalodon se mueven en otro nivel.

Un flujo de trabajo de GitHub Actions «envenenado» no es necesariamente una dependencia vulnerable. Es posible que una carga útil de shell codificada en base64 dentro de .github/workflows no aparezca en un SBOM. Un token OIDC robado no es un CVE. Un paquete malicioso puede tener una procedencia válida si el atacante ha comprometido el proceso de compilación que lo generó. Un mantenedor legítimo puede publicar una versión maliciosa si el código fuente desde el que realiza la publicación ya ha sido «envenenado».

La defensa de la cadena de suministro debe ir más allá del producto final. Los equipos necesitan controles que verifiquen:

• Comportamiento del paquete antes de la instalación
• Cambios a nivel de código fuente y diferencias entre versiones
• integridad del flujo de trabajo y ganchos de ejecución durante la compilación
• Permisos de CI/CD y comportamiento de los ejecutores
• procedencia y contexto de atestación
• Ámbito de identidad en la nube
• Exposición de las credenciales de los responsables del mantenimiento y los desarrolladores
• Señales de vulnerabilidad y compromiso posteriores a la publicación

El registro es solo una capa. El sistema de compilación es ahora el objetivo principal.

Mitigación

Aprovecha los casos de Shai-Hulud y Megalodon como motivo para auditar y reforzar el proceso de entrega de software, sobre todo si no has revisado tu exposición a CI/CD desde mayo de 2026.

1. Busca tus repositorios

Busca en los repositorios y bifurcaciones de GitHub:

• Nombres de los flujos de trabajo «SysDiag» y «Optimize-Build»
• la dirección C2 216.126.225.129
• Ejecución de «base64 -d | bash»
• activaciones inesperadas de workflow_dispatch
• Token de identificación sin explicar: permisos de escritura
• confirmaciones del flujo de trabajo procedentes de identidades desconocidas que parecen bots
• envíos directos que modificaron .github/workflows

Presta especial atención a los cambios en los flujos de trabajo que se produzcan en torno al 18 de mayo de 2026, sobre todo a aquellos que hayan eludido la revisión de las solicitudes de incorporación de cambios.

2. Bloquear y revisar las salidas conocidas

Bloquea el tráfico saliente de los runners de CI hacia 216.126.225.129:8443 y revisa los registros históricos del proxy, el cortafuegos y NetFlow en busca de conexiones procedentes de sistemas de compilación o runners autohospedados. Bloquear la dirección IP no constituye una defensa completa, ya que la infraestructura cambia rápidamente, pero resulta útil para el análisis histórico y la limpieza inmediata.

3. Rotar los secretos expuestos

Si se ha ejecutado un flujo de trabajo sospechoso, da por hecho que el entorno del ejecutor ha quedado expuesto. Da prioridad a la rotación de los PAT de GitHub y los tokens de acceso detallado, las claves de implementación, los secretos de Actions, las credenciales de las aplicaciones de GitHub, los tokens de publicación de npm y PyPI, las credenciales del registro de Docker, las claves privadas de SSH, las credenciales de AWS, Google Cloud y Azure, las configuraciones de Kubernetes, las credenciales de Terraform, los tokens de Vault y las relaciones de confianza OIDC vinculadas a los flujos de trabajo afectados.

Una advertencia antes de revocar las credenciales: algunas cargas útiles de la familia Shai-Hulud han incluido un mecanismo de seguridad destructivo vinculado a la revocación de tokens. No se ha confirmado que ese comportamiento sea una característica de las cargas útiles de Megalodon, pero en cualquier host que sospeches que está infectado, aíslalo y crea una imagen del mismo, y conserva los registros de CI, el historial de ejecución de flujos de trabajo y los eventos de auditoría antes de revocar las credenciales.

4. Poner en cuarentena las versiones de paquetes que se sabe que están comprometidas

Si utilizas @tiledesk/tiledesk-server, comprueba si hay versiones entre la 2.18.6 y la 2.18.12. Si alguna de ellas se ha instalado, compilado o implementado, revisa los entornos afectados y renueva las claves secretas utilizadas durante la compilación o en tiempo de ejecución. Mantén la última versión limpia verificada, la 2.18.5, y comprueba los archivos de bloqueo.

5. Reforzar la confianza en la OIDC

No permitas una confianza general a nivel de repositorio para roles sensibles en la nube. Siempre que sea posible, restringe la confianza OIDC por repositorio, rama, etiqueta, entorno, archivo de flujo de trabajo, público y ruta de lanzamiento. Una condición como «sub restringido a repo:org/name:ref:refs/heads/main» impide que un flujo de trabajo malintencionado en una rama secundaria genere credenciales de producción.

Revisa todos los flujos de trabajo que soliciten:

permissions:
id-token: write

Elimínalo, a menos que el flujo de trabajo tenga una necesidad documentada de solicitar un token.

6. Exigir una revisión de los cambios en el flujo de trabajo

Trata .github/workflows como código sensible desde el punto de vista de la seguridad. Utiliza la aprobación de los CODEOWNERS para los archivos de flujos de trabajo, la protección de ramas, la revisión obligatoria de las solicitudes de incorporación de cambios, las confirmaciones firmadas cuando sea pertinente, los permisos predeterminados de solo lectura para las acciones, las acciones de terceros fijadas a los SHA de las confirmaciones en lugar de a etiquetas modificables, la salida restringida de los ejecutores y ejecutores independientes para los flujos de trabajo de lanzamiento sensibles. Un archivo de flujo de trabajo puede ser tan potente como el código de implementación en producción. No debería ser más fácil de modificar.

Detección

Ningún resultado de análisis por sí solo demuestra la exposición a Shai-Hulud o Megalodon. Las pruebas relevantes se encuentran repartidas por el historial del repositorio, los archivos de flujo de trabajo, los registros de los ejecutores de CI, los registros de red, los eventos de auditoría de GitHub, los registros de identidad en la nube y los archivos de bloqueo de paquetes. Las señales de comportamiento también perduran más que los indicadores atómicos, ya que el operador va rotando la infraestructura.

Entre las señales útiles se incluyen:

• cambios inesperados en .github/workflows
• Ejecución de un shell decodificado en base64 dentro de la integración continua (CI)
• flujos de trabajo «workflow_dispatch» nuevos o sin explicar
• Flujos de trabajo que solicitan un token de identificación: escritura sin un motivo claro
• subidas directas a las ramas predeterminadas
• nombres de autores desconocidos que parecen de bots y fechas de commit falsificadas
• tráfico saliente del CI Runner hacia 216.126.225.129
• nuevas claves de implementación, autorizaciones de OAuth o instalaciones de aplicaciones de GitHub
• Supuestos inusuales sobre el papel de la nube a partir de las identidades de GitHub Actions
• publicar el paquete poco después de que se produzcan cambios sospechosos en el flujo de trabajo
• versiones inesperadas de npm o PyPI en los archivos de bloqueo del periodo de exposición

Ejemplos de términos de búsqueda en GitHub:

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

Ejemplo de búsqueda de flujos de trabajo locales:

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

Estas comprobaciones son un punto de partida, no un certificado de buena salud.

Lista de verificación de medidas correctoras priorizadas

Revisar los repositorios: Analizar los cambios en los flujos de trabajo de GitHub Actions, especialmente los realizados en torno al 18 de mayo de 2026.

Búsqueda de IOC: busca SysDiag, Optimize-Build, ejecuciones sospechosas de base64 y la dirección C2 notificada.

Conservar registros: Guarda los registros de ejecución de los flujos de trabajo, los registros de auditoría de GitHub, los archivos de bloqueo de paquetes y los artefactos de compilación antes de la limpieza.

Rotación de claves: Rotar las credenciales expuestas a cualquier entorno de ejecución sospechoso.

Reforzar el OIDC: Limitar el alcance de las políticas de confianza en la nube a flujos de trabajo, sucursales, etiquetas o entornos específicos.

Restringir los cambios en los flujos de trabajo: exigir la revisión de las solicitudes de incorporación de cambios y la aprobación de los CODEOWNERS para .github/workflows.

Revisión de la incorporación de paquetes: comprueba si se han introducido en tu entorno versiones de paquetes que se sabe que están comprometidas.

Reforzar el CI/CD: Vincular las acciones de terceros a los SHA de los commits, restringir el tráfico saliente de los runners y minimizar los permisos predeterminados de los flujos de trabajo.

Inspeccionar los puntos finales de los desarrolladores: considerar las estaciones de trabajo de los desarrolladores como parte de la cadena de suministro, especialmente en los casos en que los responsables del mantenimiento hayan instalado paquetes afectados o dispongan de credenciales almacenadas localmente.

Por qué esto va más allá de una simple campaña

Lo importante de Shai-Hulud y Megalodon no es solo su magnitud, sino también la dirección de su avance. Los atacantes se desplazan río arriba, desde los puntos vulnerables hacia los sistemas de confianza que se encuentran detrás de ellos:

• credenciales del administrador
• puntos de conexión para desarrolladores
• Ejecutores de CI/CD
• Flujos de trabajo de GitHub Actions
• Identidades OIDC
• automatización de la publicación de paquetes
• sistemas de procedencia y firma
• funciones de implementación en la nube

Esto cambia el significado mismo de la seguridad del código abierto. Ya no basta con analizar un paquete una vez que ha entrado en tu entorno. Es necesario saber de dónde procede, cómo se ha compilado, si el proceso de compilación era fiable, qué ha cambiado con respecto a la última versión, si el paquete realiza alguna acción sospechosa durante la instalación o la compilación, si el editor o el repositorio se han visto comprometidos y si el componente seguirá recibiendo correcciones de seguridad tras su implementación.

Ese es el problema que SecureChain está diseñado para resolver. SecureChain ofrece a las organizaciones una fuente verificada de componentes de código abierto, con detección de malware, inspección a nivel de código fuente, trazabilidad y corrección continua de vulnerabilidades CVE a lo largo de todo el ciclo de vida de los componentes. En el caso de las nuevas versiones de los paquetes, está diseñada para analizar las diferencias entre versiones y señalar los cambios sospechosos antes de que se consideren fiables en las fases posteriores, incluyendo ganchos de ejecución en el momento de la compilación, cargas útiles ofuscadas, rutas de ejecución ocultas y comportamientos de exfiltración.

En un escenario al estilo «Megalodon», esto es importante porque el paquete puede haber sido publicado por el responsable legítimo desde la cuenta legítima. El cambio malicioso no se encuentra en el límite del registro, sino en el código fuente viciado que llegó al registro.

Shai-Hulud y Megalodon nos recuerdan que la cadena de suministro de software no es solo el código que se instala. Es el sistema que lo seleccionó, lo compiló, lo firmó, lo publicó y sigue manteniéndolo. Ahora es necesario proteger ese sistema igual que se protege la infraestructura de producción.

Descubre SecureChain →

PREGUNTAS FRECUENTES

¿El Megalodon es lo mismo que Shai-Hulud?

No. Shai-Hulud hace referencia a una familia de ataques a la cadena de suministro que se propagan de forma autónoma, especialmente a través de npm y PyPI. Megalodon fue una campaña masiva de inyección de flujos de trabajo en GitHub Actions que tuvo lugar el 18 de mayo de 2026. Ambos están relacionados por su cronología y sus técnicas de operación, pero no se ha confirmado que Megalodon sea la misma operación ni que lo lleve a cabo el mismo operador.

¿El proyecto «Megalodon» lo llevó a cabo sin duda alguna TeamPCP?

No. TeamPCP está estrechamente vinculado a la actividad de Shai-Hulud en su entorno, y Megalodon presenta similitudes con ese estilo de ataque, pero no se ha confirmado que sea obra suya. Los investigadores que han analizado el código de Megalodon consideran que lo más probable es que se trate de un imitador. Los responsables de la seguridad deben centrarse en la técnica más que en la identificación del autor.

¿La procedencia SLSA me protege de esto?

No por sí solo. Mini Shai-Hulud demostró que los paquetes maliciosos pueden incluir una procedencia válida de SLSA Build Level 3 si el atacante compromete el proceso de compilación. La procedencia ayuda a demostrar el origen y la integridad de la compilación. No demuestra que el código fuera seguro.

¿Garantiza el OIDC que el CI/CD esté a salvo del robo de credenciales?

El OIDC es más seguro que almacenar claves en la nube de larga duración en la infraestructura de integración continua (CI), pero sigue siendo necesario definir un ámbito de aplicación muy estricto. Si un flujo de trabajo malintencionado puede solicitar un «id-token: write» y la política de confianza en la nube es demasiado amplia, un atacante podría generar credenciales de corta duración a través de la identidad del canal de confianza.

¿Por qué la autenticación de dos factores (2FA) y el inicio de sesión no impidieron el ataque a Tiledesk?

Porque el atacante no necesitó comprometer la cuenta de npm. Megalodon contaminó el repositorio de código fuente, y el mantenedor legítimo publicó a partir de ese código contaminado. La autenticación de dos factores (2FA) y la firma protegen el proceso de publicación; no garantizan que el código fuente publicado estuviera limpio.

No gestiono muchos repositorios de GitHub. ¿Sigo estando expuesto?

Es posible. Aunque no te hayas visto afectado directamente, es posible que tus dependencias de nivel superior se hayan compilado o publicado a partir de repositorios comprometidos. Cualquier organización que utilice paquetes de código abierto hereda cierto riesgo de los procesos de compilación que hay detrás de dichos paquetes.

¿Cuál es la solución más importante a largo plazo?

Considera la CI/CD como infraestructura de producción. Limita los cambios en los flujos de trabajo, define estrictamente el alcance de OIDC, supervisa el comportamiento de los ejecutores, reduce el uso de secretos en la CI, revisa los paquetes antes de instalarlos y deja de considerar la procedencia o un editor conocido como una garantía absoluta de seguridad.

Fuentes

• Cloud Security Alliance – «Shai-Hulud/Megalodon: un ataque en dos fases contra la cadena de suministro de los desarrolladores de IA»
• Protos Labs – «La campaña Shai-Hulud de TeamPCP y la oleada de imitaciones»
• SafeDep – Análisis de la campaña «Megalodon» (conjunto de datos de confirmaciones, cascada de Tiledesk)
• OX Security – Análisis de la atribución de las imitaciones de Megalodon y Shai-Hulud
• StepSecurity – Análisis de la filtración de secretos en Megalodon GitHub Actions; análisis de Mini Shai-Hulud / TanStack
• Tenable – Mini Shai-Hulud CVE-2026-45321: Preguntas frecuentes
• Hudson Rock – Análisis de las causas fundamentales del robo de información por Megalodon
• Unit 42 (Palo Alto Networks) – Informe original sobre el gusano Shai-Hulud, septiembre de 2025
• The Hacker News – Cobertura de la campaña de Megalodon y Mini Shai-Hulud
• Socket: invalidación del token de npm y análisis de la campaña «Shai-Hulud»