El 4 de agosto de 2026, alguien publicó una versión maliciosa del paquete
keyv en el registro de npm. No hizo falta que ese alguien
atacara a cada empresa que usa keyv una por una: el malware
se encargó de propagarse solo, usando las mismas credenciales robadas del
mantenedor para infectar automáticamente otros paquetes. En horas, la
cadena de suministro de software de miles de organizaciones —muchas sin
saberlo todavía— quedó comprometida.
El caso: cómo Shai-Hulud se propagó sin ayuda del atacante
Según análisis técnico publicado por
Wiz
y confirmado por una
alerta de la Agencia de Ciberseguridad de Singapur,
el ataque comenzó con el compromiso de la cuenta de GitHub de un
mantenedor del ecosistema keyv/cacheable. Desde
ahí, los atacantes publicaron una versión maliciosa del paquete
(documentada como la 6.0.0) que instalaba una variante del malware
Shai-Hulud.
Lo distintivo de Shai-Hulud es que, una vez dentro, no necesita que el atacante mueva un dedo para seguir creciendo: usa las credenciales que acaba de robar para publicar automáticamente versiones maliciosas de otros paquetes a los que esa misma identidad tenía acceso. Así se propagó a más de 400 paquetes distintos de npm en esta campaña —parte de una ola mayor que, según reportes de la industria, superó las 1.300 versiones de paquetes afectadas y paquetes con más de 2.000 millones de descargas combinadas.
paquetes de npm distintos quedaron comprometidos en esta campaña, sin que el atacante tuviera que intervenir manualmente en cada uno. El propio malware decidió a dónde propagarse a continuación.
Qué hace el malware una vez dentro de tu entorno de desarrollo
Shai-Hulud no se limita a robar una credencial y desaparecer. El análisis de Wiz documentó un espectro de datos sensibles capturados:
- Credenciales de proveedores cloud y configuraciones de CI/CD (Jenkins, Argo CD)
- Tokens de GitHub y llaves SSH
- Credenciales de herramientas de IA (Claude, OpenAI, Cursor)
- Billeteras de criptomonedas
- Archivos sensibles del sistema operativo
Para persistir, el malware se ancla a herramientas que un desarrollador usa a diario —hooks de asistentes de código y tareas configuradas en el editor— asegurando que vuelva a activarse en futuras sesiones de trabajo. Su infraestructura de comando y control es igual de sofisticada: obtiene los dominios a los que reportar desde un contrato inteligente de Ethereum, lo que hace mucho más difícil desactivarla centralizadamente.
Por qué esto no es "un problema de otro equipo"
Es tentador pensar que esto es un problema exclusivo de quienes publican paquetes open source. No lo es. Una aplicación moderna típica depende, directa o indirectamente, de cientos o miles de paquetes de terceros que nadie dentro de la organización revisa línea por línea. Cuando uno de esos paquetes —a menudo varios niveles de profundidad en el árbol de dependencias— se compromete, el riesgo entra a tu entorno sin pasar por ninguno de tus controles perimetrales tradicionales.
Es el mismo patrón que ya vimos con el 0-day que explotó Lazarus: el punto de entrada real casi nunca es donde uno mira primero. Ahí fue una oferta de trabajo falsa; acá, una cuenta de mantenedor comprometida en un paquete que ni siquiera sabías que usabas.
Qué puedes hacer esta semana
1. Construye un inventario real de tus dependencias (SBOM)
Un Software Bill of Materials actualizado te permite responder en minutos "¿estamos usando el paquete comprometido?", en lugar de días de búsqueda manual en cada repositorio.
2. Fija versiones y verifica integridad
Evita actualizar automáticamente a la última versión sin revisión. Usa lockfiles, verifica checksums cuando sea posible, y considera un allowlist de dependencias para los componentes más críticos.
3. Rota credenciales si hubo exposición, y aísla lo comprometido
Si detectas un paquete afectado en tu entorno de desarrollo o CI/CD, trata esos sistemas como potencialmente vulnerados: rota tokens de GitHub, llaves SSH y credenciales cloud, no solo elimines la versión maliciosa.
4. Audita a tus terceros de forma continua, no una vez al año
La cadena de suministro de software es una extensión de tu riesgo con terceros. Nuestro servicio de Auditoría de Seguridad incluye evaluación de terceros y cadena de suministro, y nuestro servicio de CTI monitorea fuentes abiertas y propias en busca de señales de compromiso —incluidas filtraciones asociadas a componentes que tu organización utiliza.
Preguntas frecuentes
¿Qué es un ataque a la cadena de suministro de software?
Es un ataque que compromete un componente en el que muchas organizaciones confían indirectamente —una librería, un paquete, una herramienta de desarrollo— en lugar de atacar a cada organización una por una.
¿Qué es Shai-Hulud y por qué se le llama gusano?
Es una familia de malware que usa las credenciales robadas de un mantenedor para publicar automáticamente versiones maliciosas de otros paquetes a los que esa cuenta tiene acceso, propagándose sin intervención manual del atacante.
¿Mi empresa está en riesgo si no publicamos paquetes en npm?
Sí, si tu software usa como dependencia —directa o indirecta— alguno de los paquetes comprometidos. La gran mayoría de aplicaciones modernas dependen de cientos de paquetes de terceros sin revisión individual.
¿Qué es un SBOM y por qué ayuda ante este tipo de incidentes?
Es un inventario detallado de todos los componentes de una aplicación. Permite responder rápidamente si estás usando un paquete comprometido, en lugar de días de revisión manual.
¿Cómo se relaciona esto con la auditoría de terceros?
La cadena de suministro de software es una extensión de tu superficie de riesgo con terceros. Auditar regularmente qué componentes y proveedores sostienen tu operación es la forma de detectar esta exposición antes de que se convierta en un incidente.