Shai-Hulud expone la debilidad de la cadena de suministro de npm y PyPI al robar credenciales con firmas aparentes

La campaña conocida como Shai‑Hulud ha vuelto a golpear el ecosistema de paquetes: cientos de artefactos en npm y PyPI han sido publicados con código malicioso diseñado para robar credenciales y propagarse entre proyectos de desarrolladores. Lo más inquietante no es solo el volumen, sino la técnica: los atacantes aprovecharon tokens OpenID Connect (OIDC) legítimos para firmar y publicar versiones maliciosas con attestaciones de procedencia válidas (SLSA Build Level 3), lo que hace que las piezas comprometidas parezcan “criptográficamente auténticas”. Para entender la magnitud, basta con repasar investigaciones como las de Endor Labs y el análisis de Snyk, que documentan cientos de versiones y artefactos comprometidos y explican cómo los atacantes encadenaron fallos en flujos de CI/CD para subir paquetes maliciosos.

El ataque, atribuido al grupo TeamPCP, comenzó afectando ecosistemas como TanStack y Mistral AI y se extendió rápidamente a proyectos populares como Guardrails AI, UiPath y OpenSearch, incluso alcanzando paquetes oficiales como algunos de SAP y la CLI de Bitwarden. Según el post‑mortem de TanStack, los operadores encadenaron tres vectores: un flujo de trabajo inseguro de pull_request-target, envenenamiento de caché de GitHub Actions y el robo de tokens OIDC desde la memoria de los runners. Además, abusaron de un truco con commits huérfanos en forks para forzar a npm a descargar y ejecutar código controlado por el atacante mediante una dependencia opcional.

Estas técnicas tienen consecuencias muy claras: cuando el pipeline de CI publica paquetes maliciosos con firmas y attestaciones legítimas, la confianza automática en la proveniencia deja de ser suficiente. Los desarrolladores que instalaron versiones afectadas deben asumir que sus secretos pueden haber sido exfiltrados. La muestra de malware detectada extrae tokens y credenciales (GitHub OIDC y PATs, tokens npm, credenciales AWS, secretos de Vault, tokens de cuentas de servicio Kubernetes, SSH keys, archivos .env y configuraciones de IDE) leyendo la memoria de procesos y ficheros conocidos, y utiliza la red P2P de Session para camuflar el tráfico de exfiltración, lo que complica bloqueos y derribos.

Además de robar secretos, el malware persiste dentro del entorno de desarrollo: escribe hooks en herramientas como Claude Code y tareas auto‑ejecutables en VS Code, de modo que desinstalar el paquete malicioso no borra la infección. La operación también se auto‑propaga: con credenciales robadas modifican tarballs, inyectan payloads y republican versiones infectadas en los paquetes que mantiene el usuario comprometido.

En términos prácticos para equipos y responsables de seguridad, la recomendación inicial es tajante: si descargaste una versión afectada, trátala como una fuga de credenciales. Debes rotar de inmediato todos los tokens y secretos relevantes —incluyendo tokens de CI/CD, tokens npm, claves de nube, tokens de Vault y cuentas de servicio Kubernetes— y revisar los logs y configuraciones de CI para detectar publicaciones no autorizadas. Es imprescindible auditar las máquinas de desarrollo y CI en busca de archivos persistentes o hooks maliciosos (por ejemplo, ficheros como router_runtime.js o setup.mjs que hayan sobrevivido a instalaciones), y eliminar cualquier tarea o configuración de IDE que no reconozcas.

En el plano organizativo conviene revisar y endurecer los flujos de CI/CD: evitar workflows que permitan que un pull request no confiable ejecute procesos con permisos de publicación, reducir el alcance y la duración de los tokens OIDC y usar credenciales efímeras y con el mínimo privilegio. También es recomendable forzar instalaciones con lockfile‑only para prevenir actualizaciones automáticas silenciosas, y complementar la verificación de provenance (SLSA) con análisis de comportamiento en tiempo de instalación y firmas adicionales que verifiquen identidad del builder y ruta del workflow, no solo la firma del artefacto.

Para mitigar campañas similares en el futuro conviene implementar controles técnicos y operativos: restringir el acceso de los runners, vaciar o asegurar la memoria crítica tras ejecuciones sensibles, desactivar cachés que puedan ser envenenados para acciones de publicación, usar runners efímeros y automatizar la rotación de credenciales tras indicios de exposición. A nivel de red, bloquear a nivel DNS/proxy la infraestructura de mando y control conocida asociada a esta campaña (por ejemplo dominios documentados por los análisis) puede contener la exfiltración y las comunicaciones de los atacantes.

La comunidad de seguridad ha publicado listados y guías para identificar versiones afectadas y limpiar entornos: además de las notas de investigación citadas, revisa los avisos del propio TanStack y de proveedores de seguridad que han rastreado los artefactos comprometidos. Consulta el informe de TanStack para detalles del flujo explotado y las versiones publicadas, y sigue las recomendaciones operativas de respuesta y rotación de credenciales. Evitar la complacencia frente a attestaciones válidas y combinar controles de identidad, análisis dinámico y buenas prácticas en CI será clave para reducir la ventana de exposición ante este tipo de campañas de cadena de suministro.