La última campaña dirigida a la cadena de suministro no solo puso en peligro los registros de código abierto. También se apropió del proceso de lanzamiento de una de las organizaciones más preocupadas por la seguridad del mundo, y el punto de entrada fue una instalación rutinaria de una dependencia de npm.
El 11 de mayo de 2026, el grupo de ciberdelincuentes TeamPCP llevó a cabo la cuarta oleada de su campaña del gusano Shai-Hulud, ahora conocida como Mini Shai-Hulud. El ataque afectó a 84 versiones de paquetes maliciosos repartidos en 42 paquetes de TanStack en el registro npm en un intervalo de seis minutos, extendiéndose finalmente a más de 170 paquetes en los registros de código fuente de npm y PyPI (Python Package Index), incluidos los espacios de nombres pertenecientes a Mistral AI, UiPath y OpenSearch. Al menos uno de los paquetes afectados, @tanstack/react-router, recibe aproximadamente 12 millones de descargas semanales.
Esta es la cuarta oleada de una campaña cada vez más intensa. Las oleadas anteriores incluyen el ataque inicial a npm (Shai-Hulud 1.0) y la oleada 2.0 dirigida a las credenciales de GitHub.
OpenAI reveló esta semana que se produjeron incidencias de seguridad en dos dispositivos de empleados. No se vieron afectados los datos de los usuarios, los sistemas de producción ni la propiedad intelectual, pero las medidas de contención requirieron aislar los sistemas, renovar las credenciales, contratar a expertos forenses externos y llevar a cabo una renovación completa de los certificados de firma de código en macOS, Windows, iOS y Android, todo ello a raíz de la instalación de una única dependencia.
Mini Shai-Hulud, cuarta tanda: datos clave
- Fecha del ataque: 11 de mayo de 2026
- Paquetes afectados: 84 versiones maliciosas en 42 paquetes de @tanstack/*; más de 170 en total en los registros de npm y PyPI
- CVE: CVE-2026-45321, puntuación CVSS: 9,6 (crítico)
- Atribución: TeamPCP (también conocido como PCPcat, UNC6780)
- Mecanismo: Tres vulnerabilidades encadenadas en GitHub Actions: Pwn Request, envenenamiento de caché y extracción de tokens OIDC (OpenID Connect) de la memoria del proceso del ejecutor
- Víctima destacada: OpenAI —se vieron comprometidos los dispositivos de dos empleados; se filtraron secretos, entre ellos certificados de firma de código para macOS, iOS, Windows y Android, sustraídos de los repositorios internos de código fuente—
- Versiones anteriores: Shai-Hulud 1.0 (septiembre de 2025), 2.0 (noviembre de 2025) y 3.0 (diciembre de 2025)
- Repercusiones: entornos de desarrollo y de CI/CD comprometidos ; cuentas de administradores y paquetes secuestrados; y la procedencia SLSA y las compilaciones firmadas ya no son «seguras por defecto».
- Riesgos clave: Paquetes maliciosos que superan la certificación de procedencia de nivel tres de SLSA (Niveles de la cadena de suministro para Software )
Cómo se llevó a cabo el ataque
La cuarta oleada de Mini Shai-Hulud es la versión técnicamente más sofisticada de esta campaña hasta la fecha. Mientras que las oleadas anteriores se valían de cuentas de administradores comprometidas para publicar paquetes maliciosos directamente, la cuarta oleada encadenó tres vulnerabilidades de GitHub Actions para secuestrar el propio proceso de lanzamiento legítimo.
La secuencia del ataque:
- Bifurcación y camuflaje: el atacante bifurcó el repositorio TanStack/router y lo renombró como zblgg/configuration para que no apareciera como una bifurcación evidente en las vistas de la lista de bifurcaciones de GitHub.
- Activación del flujo de trabajo: se ha abierto una solicitud de incorporación de cambios que ha activado el flujo de trabajo «pull_request_target», el patrón «Pwn Request» que concede al flujo de trabajo acceso al código bifurcado
- Contaminar la caché: el código de la bifurcación del atacante introdujo una entrada contaminada de pnpm-store de 1,1 GB en la caché de GitHub Actions, configurada de tal manera que el flujo de trabajo de lanzamiento la restaurara posteriormente
- Borrar las huellas: A continuación, la solicitud de incorporación de cambios maliciosa se forzó a un estado inactivo y se cerró para ocultar las pruebas del ataque
- Espera a que se active el mecanismo: cuando los mantenedores legítimos de TanStack fusionaron solicitudes de incorporación de cambios no relacionadas con el proyecto principal, se activó el flujo de trabajo de lanzamiento y se restauró la caché contaminada
- Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
- Publicación a través del canal de distribución: esos tokens se utilizaron para publicar 84 versiones maliciosas de paquetes en el registro de npm a través del propio canal de distribución legítimo de TanStack.
- El resultado: paquetes que incluían certificados de procedencia válidos de nivel tres de SLSA Build, certificados válidos de Sigstore y firmas legítimas de GitHub Actions, generados por el proceso de lanzamiento legítimo, pero que contenían malware diseñado para robar credenciales. Tal y como confirmó TanStack en su análisis posterior al incidente, desde el punto de vista de un desarrollador, los paquetes parecían auténticos desde el punto de vista criptográfico, sin indicios visibles de que hubieran sido comprometidos.
Se revelaron secretos: la carga útil del malware sustrajo información confidencial —credenciales y tokens a los que se podía acceder directamente en los sistemas comprometidos— a través de tres canales redundantes: un dominio de typosquatting (git-tanstack[.]com), la red descentralizada de mensajería Session y puntos API de GitHub utilizando tokens robados. Las credenciales objetivo incluían tokens de GitHub, secretos en la nube de AWS, GCP y Azure, material de autenticación de CI/CD, credenciales de Kubernetes, Vault HashiCorp Vault y claves SSH.
En los equipos de los desarrolladores, el malware instalaba un demonio persistente llamado «gh-token-monitor» (a través de LaunchAgent en macOS o de systemd en Linux) que consultaba GitHub cada 60 segundos. Al recibir un error 40X debido a la revocación del token, el demonio intentaba ejecutar «rm -rf ~/», borrando así el directorio de inicio del usuario. El demonio se cerraba automáticamente tras 24 horas.
El impacto de OpenAI y lo que nos dice
La comunicación de OpenAI es precisa en cuanto a lo que se filtró: material limitado relacionado con credenciales procedente de un subconjunto de repositorios de código fuente internos a los que tenían acceso los dos empleados afectados, incluidos certificados de firma de código para productos de macOS, iOS, Windows y Android. OpenAI confirmó que no hay pruebas de que esos certificados se utilizaran para firmar software malicioso, pero los está renovando todos por precaución y exige a los usuarios de macOS que actualicen sus aplicaciones antes del 12 de junio de 2026, fecha a partir de la cual las aplicaciones firmadas con los certificados antiguos podrían dejar de funcionar.
Hay un segundo detalle en la comunicación de OpenAI que merece atención. Los dos dispositivos afectados aún no habían recibido las configuraciones actualizadas del gestor de paquetes —que incluían controles como la comprobación de la antigüedad mínima de las versiones y la validación de la procedencia de los paquetes— que se estaban implantando en todo el entorno de la organización. El ataque se produjo durante ese periodo de implantación.
Esto pone de manifiesto una vulnerabilidad real y habitual. Los controles de seguridad se implementan de forma gradual. Durante cualquier implementación por fases, un subconjunto de sistemas queda más expuesto. La campaña de TeamPCP se desarrolló de forma ininterrumpida durante semanas, publicando paquetes maliciosos en los registros y esperando a que se instalaran. La elección del momento no fue casual.
Comprueba Software de tu Software para prevenir Supply Chain
La solución MetaDefender Software ™ está diseñada para ayudar a las organizaciones a inspeccionar los artefactos, paquetes y binarios reales que entran en el ciclo de vidaSoftware (SDLC), incluidos los paquetes que llevan firmas válidas o certificados de procedencia, lo que proporciona visibilidad del software a lo largo de todo el proceso en el momento en que se utilizan los paquetes.
Tres funciones deSupply Chain MetaDefender Software Supply Chain abordan directamente las vulnerabilidades que este ataque aprovechó:
Metascan™ Multiscanning: combina más de 30 motores antimalware comerciales para analizar paquetes procedentes de registros de código fuente, como npm y PyPI, antes de que lleguen a las estaciones de trabajo de los desarrolladores o a los procesos de CI/CD. En los casos en que un único motor de detección no detecte una variante recién publicada, la superficie de detección combinada reduce el margen de tiempo durante el cual un paquete malicioso puede ejecutarse sin ser detectado.
Generación de SBOM (Software de materialesSoftware ) : ofrece visibilidad sobre los componentes de software de toda una pila, las dependencias directas y transitivas, el historial de versiones y los metadatos del registro, con compatibilidad con más de diez lenguajes de programación. La SBOM ayuda a detectar cambios inesperados en los paquetes antes de que se propaguen a las fases posteriores del proceso, y permite la exportación en formatos CycloneDX y SPDX para facilitar el cumplimiento de los requisitos normativos, incluida la DORA (Ley de Resiliencia Operativa Digital).
Proactive DLP™: analiza el código fuente en busca de secretos codificados de forma rígida —contraseñas, API , tokens y credenciales incrustadas en el código— antes de que queden expuestas a los atacantes. Esto difiere de la respuesta ante la filtración de credenciales: la tecnología Proactive DLP™ aborda el riesgo de que los secretos que quedan dentro del código fuente o de los archivos de configuración queden accesibles cuando se ve comprometido un repositorio, como ocurrió en el incidente de OpenAI.
MetaDefender Software Supply Chain se integra de forma nativa con GitHub, GitLab, Azure DevOps y Nexus, situando la inspección dentro del proceso en lugar de al margen del mismo. Una versión reciente, la 3.3.0, añade compatibilidad con la transferencia segura de artefactos entre entornos aislados mediante la transferencia unidireccional de datos con tecnología de diodo de datos, lo que permite a las organizaciones en entornos aislados o de alta seguridad validar los artefactos antes de que crucen los límites de la red, con un proceso de activación disponible que se adapta a los flujos de trabajo DevSecOps existentes.
Medidas inmediatas recomendadas
Para cualquier organización que haya instalado paquetes afectados durante el periodo de Mini Shai-Hulud:
- Comprueba si hay un demonio «gh-token-monitor» en ejecución antes de revocar los tokens: aísla y crea una imagen de los sistemas afectados primero; una revocación prematura activa la carga útil de borrado.
- Renueva las credenciales expuestas: PAT de GitHub, tokens de npm, claves SSH y credenciales de la nube para cualquier desarrollador o canalización que haya instalado paquetes durante el periodo afectado; activa la autenticación de dos factores (MFA).
- Elimina los paquetes afectados: borra la caché de npm y el directorio `node_modules`; fija las versiones de los paquetes a las publicadas después del 12 de mayo de 2026.
- Revisa las acciones de GitHub y los flujos de trabajo de CI/CD: busca eventos de publicación inesperados, nuevos flujos de trabajo o conexiones salientes a puntos finales desconocidos.
- Reforzar la seguridad de los sistemas: restringir los scripts de ciclo de vida, limitar el acceso a la red de salida y reducir al mínimo el alcance de los tokens.
- Combina las comprobaciones de procedencia con la inspección del contenido: una procedencia válida indica el origen del proceso, no su integridad; utiliza el análisis de malware junto con la verificación de certificados.
Puntos clave
El certificado de procedencia indica el origen, no la integridad
Wave Four generó paquetes maliciosos con certificados válidos porque el propio proceso de lanzamiento se vio comprometido. Las comprobaciones de firmas y procedencia son una indicación útil, pero no una garantía de que el contenido sea seguro.
El «periodo de implementación» es un «periodo de exposición»
. El incidente de OpenAI se produjo durante la implantación gradual de nuevos controles en la cadena de suministro. Toda organización presenta lagunas similares durante la implementación de controles. La inspección del contenido en cada fase ayuda a reducir la dependencia de que la cobertura de las políticas esté completa antes de que se produzca un ataque.
Esta campaña sigue en curso
. Mini Shai-Hulud es la cuarta oleada de una campaña cuya sofisticación técnica ha ido aumentando sistemáticamente desde septiembre de 2025. Considerar que cualquier incidente aislado está resuelto sin abordar las vulnerabilidades subyacentes del proceso deja a las organizaciones expuestas a la siguiente oleada.
La combinación de la visibilidad de la SBOM, el análisis múltiple de malware y la detección de secretos codificados ayuda a reducir la superficie de exposición en los entornos modernos de desarrollo de software. No confíes en ningún archivo. No confíes en ningún dispositivo.
¿Estás listo para proteger tu proceso de desarrollo de software frente a ataques a la cadena de suministro como el de Mini Shai-Hulud?
