Breaking
Markets
EUR/USD1.1612 0.07%GBP/USD1.3400 0.05%USD/JPY159.03 0.05%USD/CHF0.7886 0.14%AUD/USD0.7111 0.08%USD/CAD1.3749 0.05%USD/CNY6.8207 0.21%USD/INR96.65 0.11%USD/BRL5.0310 0.16%USD/ZAR16.69 0.25%USD/TRY45.59 0.04%Gold$4,548.60BTC$77,589 1.09%ETH$2,137 1.26%SOL$86.08 2.13%
Tecnología

Mini Shai-Hulud golpea de nuevo: 314 paquetes de npm comprometidos

Hacker Newshace 1 d
Un candado sobre un teclado con código binario al fondo
Photo: Rafael Minguet Delgado / Pexels

Esta semana se ha hecho público un ataque a la cadena de suministro en npm, el gestor de dependencias más usado por la comunidad JavaScript. Según informa la firma de seguridad SafeDep, un grupo de atacantes que se hace llamar Mini Shai-Hulud colocó variantes maliciosas en 314 paquetes populares de npm. El ataque no se dirigió a un único desarrollador independiente, sino a las credenciales de publicación de los editores originales de esos paquetes.

El nombre alude a una campaña más amplia, Shai-Hulud, del mismo grupo en 2024. Aquella usaba una vulnerabilidad de pipeline CI/CD en GitHub Actions para comprometer unos 1.500 paquetes. Mini Shai-Hulud es la versión más pequeña pero más selectiva del mismo actor — esta vez ha entrado en las cuentas de npm mediante phishing de los tokens de acceso de los editores.

Entre los 314 paquetes afectados hay dos categorías populares. Un grupo lo forman bibliotecas de manipulación de archivos (plug-ins de fs-extra, variantes de glob) con bases de descargas semanales de unos 100.000. El segundo grupo lo forman bibliotecas de logs y diagnóstico, con base de usuarios menor pero alto uso empresarial. El análisis de SafeDep mostró que la mayoría de los editores afectados usaba un modo de autenticación con token único que evitaba la doble autenticación.

La técnica de ataque era un hook "postinstall" añadido de forma encubierta al archivo package.json. Se ejecuta automáticamente al lanzar el comando npm install; un pequeño script recoge variables de entorno del sistema del usuario — en particular AWS_ACCESS_KEY, NPM_TOKEN, GITHUB_TOKEN y OPENAI_API_KEY — y las envía a un servidor remoto de mando y control. La estructura no es sofisticada pero sí eficaz.

Según SafeDep, la campaña comenzó hacia la medianoche UTC del 17 de mayo y fue identificada 18 horas después. Durante ese tramo, los paquetes comprometidos recibieron unos 2,8 millones de descargas nuevas. La lista exacta de desarrolladores cuyo entorno personal fue exfiltrado aún no se conoce con detalle; SafeDep notificó a GitHub la mañana del 19 de mayo para bloquear las direcciones IP del servidor de mando y control.

npm Inc. confirmó el incidente y revirtió todos los paquetes afectados a versiones limpias. Al mismo tiempo, 23 cuentas de editores fueron suspendidas temporalmente, con la exigencia de que sus titulares se autentiquen de nuevo, activen la doble autenticación y roten los tokens usados en los últimos tres meses. Se espera además una actualización política más amplia para todos los editores de npm, con una propuesta de hacer obligatoria la doble autenticación.

Los consejos prácticos a la comunidad de desarrolladores se dividen en cuatro categorías. Primero, rotar las variables de entorno de cualquier sistema que haya ejecutado npm install en las últimas 18 horas. Segundo, hacer manualmente un diff de los archivos package-lock.json (para detectar scripts postinstall añadidos). Tercero, en entornos empresariales, ejecutar npm install dentro de un sandbox. Cuarto, usar Snyk, GitHub Dependabot o la propia herramienta de análisis de cadena de suministro de SafeDep en los proyectos.

El significado más amplio del ataque está en los problemas estructurales de seguridad del ecosistema JavaScript. npm alberga 3,2 millones de paquetes activos; si se admite que cerca del 14 % están mantenidos por un único editor, el compromiso de una sola cuenta puede afectar a una amplia base de usuarios. Desde que GitHub absorbió formalmente a npm en su plataforma el año pasado, la alineación de políticas de seguridad se sigue de cerca, pero la seguridad estructural sigue dependiendo de la elección del editor.

Del lado de la defensa, otro avance técnico importante es la firma de paquetes, cuya adopción ha crecido en los últimos doce meses. Desde marzo de 2026, GitHub permite verificar paquetes contra la firma del editor; alrededor del 18 % de los paquetes de npm usan hoy esta firma. Ninguno de los 314 paquetes afectados por Mini Shai-Hulud estaba firmado.

De cara al futuro, la frecuencia creciente de estos incidentes en el ecosistema JavaScript — unos 30 a 40 ataques notables a la cadena de suministro al año en npm en los últimos tres años — apunta a la necesidad de que la industria revise el nivel de seguridad por defecto de los gestores de paquetes. Los ecosistemas de Python (PyPI), Ruby (rubygems) y Rust (crates.io) tienen políticas por defecto más estrictas. Por comparación, la política tradicionalmente abierta de npm se considera amigable para los desarrolladores y, a la vez, menos segura.

Este artículo es un resumen editorial asistido por IA basado en Hacker News. La imagen es una foto de archivo de Rafael Minguet Delgado en Pexels.