Mini Shai-Hulud: la campaña que expone la fragilidad de la cadena de suministro de código abierto en npm, PyPI y GitHub Actions

La campaña conocida como Mini Shai‑Hulud, atribuida al actor TeamPCP, vuelve a poner de manifiesto la fragilidad de la cadena de suministro de código abierto: paquetes legítimos en npm y PyPI usados por proyectos como TanStack, Mistral AI, OpenSearch y Guardrails AI fueron alterados para incluir un cargador malicioso que no solo roba credenciales, sino que también intenta persistir y propagarse como un verdadero gusano dentro del ecosistema de paquetes y CI/CD.

Lo más preocupante de este incidente es el nivel de sofisticación técnico y táctico. Los atacantes utilizaron un archivo ofuscado en JavaScript ("router_init.js") para perfilar entornos y lanzar un robador de credenciales capaz de extraer secretos de proveedores cloud, carteras de criptomonedas, herramientas de IA, mensajería y sistemas CI como GitHub Actions. Además, para evadir filtros corporativos, exfiltraron datos a una infraestructura basada en Session Protocol (dominio filev2.getsession[.]org) y, como plan de respaldo, los subieron a repositorios GitHub usando tokens robados bajo la identidad "[email protected]".

El vector de entrada técnico fue una cadena de compromisos en GitHub Actions: uso del disparador pull_request_target, envenenamiento de cache de Actions y extracción en tiempo de ejecución de tokens OIDC desde el proceso del runner. Esto permitió a los atacantes publicar paquetes maliciosos a través del pipeline legítimo del proyecto con pruebas de procedencia SLSA válidas, una escalada rara y peligrosa que ataca precisamente la confianza que busca garantizar SLSA. Más información sobre cómo endurecer GitHub Actions está disponible en la documentación oficial: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions, y sobre SLSA en https://slsa.dev/.

El gusano demostró además capacidad de autorreplicación: localizaba tokens de publicación npm con la bandera bypass_2fa=true, enumeraba paquetes de los mismos mantenedores y cambiaba tokens OIDC por tokens por paquete para eludir la autenticación tradicional. El resultado fue la creación y propagación de versiones maliciosas con SLSA Build Level 3 aparentando ser legítimas. El incidente ha recibido el identificador CVE‑2026‑45321 y una calificación CVSS crítica de 9.6, afectando decenas de paquetes y versiones.

Las muestras detectadas incluyen comportamientos extremos y geofencing: análisis de Microsoft sobre la muestra de Mistral describe un descargador que evita entornos de habla rusa y que contiene una rama destructiva con probabilidad de ejecutar "rm -rf /" en ciertos países, mientras que el paquete comprometido guardrails-ai ejecutaba código en el momento de la importación que descargaba y ejecutaba un artefacto remoto sin verificaciones de integridad. Esto ilustra no solo la pérdida de secretos, sino el riesgo real de daño irreversible en sistemas de producción.

Para mantenedores de proyectos afectados o en riesgo, la respuesta debe ser inmediata y multifacética: revocar y rotar todos los tokens de publicación y OIDC, auditar los logs de GitHub Actions en busca de forks con payloads, commits y usos de cuentas sospechosas (p. ej. "[email protected]"), revocar credenciales con bypass_2fa y deshabilitar o restringir el uso de pull_request_target en flujos de trabajo que hacen operaciones sensibles. Es crucial verificar los artefactos publicados y la cadena de suministro: reconstruir, firmar y verificar hashes y firmas de paquetes antes de aceptarlos en producción.

Los equipos de seguridad de organizaciones consumidoras deben detectar y mitigar compromisos derivados de dependencias: auditar dependencias transitorias, bloquear versiones comprometidas en los gestores (npm y PyPI), escanear entornos de desarrollo y CI en busca de procesos que se conecten a dominios sospechosos como filev2.getsession[.]org, api.masscan[.]cloud o git-tanstack.com, y revisar las máquinas de desarrolladores y runners de CI por persistencias en IDEs (extensiones/integraciones de VS Code y Claude Code) y servicios como gh-token-monitor.

Hay implicaciones estratégicas mayores: la campaña muestra cómo la confianza en atestaciones de build puede ser manipulada si workflows legítimos y tokens OIDC quedan expuestos, por lo que las organizaciones deben aplicar el principio de menor privilegio a las identidades de CI, adoptar caducidad corta para tokens, habilitar políticas de acceso condicional y revisar el modelo de confianza para forks externos y caches de Actions. Recomendaciones operativas y de defensa pueden consultarse en la guía de endurecimiento de GitHub Actions citada arriba.

Desde la perspectiva legal y de gobernanza, los mantenedores deben coordinar la divulgación responsable con registros de paquetes (npm/PyPI), GitHub y, cuando corresponda, autoridades regulatorias. Los consumidores deben seguir las instrucciones de los proyectos y repositorios de seguridad para actualizar o retirar versiones afectadas, y registrar evidencias operacionales antes de limpiar entornos comprometidos.

En resumen, este incidente no es solo otro paquete malicioso: es una advertencia sobre cómo la combinación de automatización CI, tokens de alto privilegio y procedimientos de confianza pueden ser explotados para introducir malware que se propaga y persiste. La mitigación exige cambios técnicos (rotación de credenciales, restricciones a workflows, revisión de permisos), operativos (auditorías continuas, detección de exfiltración) y culturales (menos confianza implícita en automatizaciones). Actuar rápido y coordinar con proveedores y la comunidad es la única manera de limitar el alcance y prevenir futuras campañas similares.