Guías de seguridad
Gusanos en la cadena de suministro de npm: cómo roban credenciales durante la instalación y cómo defenderse
ChainDrop envenenó 444 paquetes de npm en menos de cuatro horas en agosto de 2026, y los publicó con procedencia (provenance) válida. Roba credenciales durante la instalación y usa el token de GitHub robado para copiar tus repositorios privados en repositorios públicos. Qué lo detiene de verdad.
Para quién es: cualquiera que desarrolle con npm o pnpm, guarde código en GitHub o despliegue desde CI. Se basa en investigaciones públicas de fabricantes y laboratorios, y no contiene pasos de explotación ni muestras.
Qué pasó (ChainDrop, agosto de 2026)
4 ago 2026
Se comprometió la cuenta de GitHub de un mantenedor de paquetes de caché muy usados. El atacante lanzó los flujos de publicación de GitHub Actions ya existentes en esos proyectos para publicar versiones envenenadas en npm.En cuatro horas
Se envenenaron 444 paquetes y 2.212 versiones, incluidos paquetes cuyas descargas semanales combinadas superan los 500 millones.Al instalar
Los hooks de instalación recogieron credenciales de npm, GitHub, la nube (AWS/GCP/Azure), claves SSH, Kubernetes y CI/CD; según el análisis publicado, incluso tokens OIDC de vida corta extraídos de la memoria del runner de CI.Después
Las credenciales robadas se usaron para volver a publicar todos los paquetes que la víctima podía publicar (autopropagación), y los secretos recogidos se filtraron a repositorios públicos de GitHub creados por el atacante.
El daño principal en esta familia: tus repos privados pasan a ser públicos
Los gusanos de la familia Shai-Hulud usan el token de GitHub robado para copiar los repositorios privados de la víctima en repositorios públicos; se han visto nombres que terminan en -migration. GitHub no fue vulnerado. Un token sacado de tu portátil o de tu runner de CI hace esto como una acción legítima, con tus propios privilegios. Por eso «esperar a que la plataforma lo arregle» no es una defensa aquí.
Por qué no se detuvo
Añadir una dependencia / instalar en CI
↓ preinstall / postinstall se ejecuta automáticamente
Código arbitrario en tu equipo o runner
↓ se recogen secretos de npm / GitHub / nube / SSH / CI
Acciones legítimas con tokens robados
repos privados copiados como públicos / paquetes republicados para propagarse
Lo que no sirvió
- Firmas y procedencia: se emitieron legítimamente con los privilegios del mantenedor, así que la verificación pasó
- «Es un paquete grande y popular»: los envenenados eran exactamente eso
- Fijar versiones, sin más: igualmente lo descargas en una instalación nueva o en la siguiente actualización
- Esperar una corrección de la plataforma: lo que se usó fueron tokens válidos y API públicas
Lo que sí sirve
- Scripts de instalación desactivados por defecto: el código nunca se ejecuta
- Un periodo de espera antes de adoptar versiones: evita el intervalo entre publicación y retirada
- Tokens de vida corta y alcance reducido: limitan qué puede hacer un token robado y durante cuánto tiempo
- Restricciones de salida en los runners de CI: cierran la vía de exfiltración
Cinco cosas que hacer hoy
Busca en tu propio lockfile
Comprueba si hay alguna versión reportada como envenenada (por ejemplo keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6). Un resultado limpio es una buena noticia, pero los pasos 2 en adelante te preparan para el próximo ataque similar, así que sigue.
Desactiva por defecto los scripts de instalación
Haz que CI use npm ci --ignore-scripts; en pnpm, pon ignore-scripts=true en .npmrc y permite de forma explícita solo las dependencias que de verdad necesitan compilarse. Es el cambio de mayor valor, porque elimina la etapa de ejecución de la que depende este ataque.
Espera unos días tras una nueva versión antes de adoptarla
No adoptes una versión en cuanto aparece: basta un periodo de espera de 3 a 7 días. Cuando el tiempo entre publicación y retirada es de horas a días, como aquí, solo con esperar lo evitas. Si usas PR automáticos de actualización, incluye ese retraso en la configuración.
Añadido el 2026-09-05: esto ya no tiene que depender de la disciplina. La guía oficial de seguridad de Node.js incluye, entre sus mitigaciones de cadena de suministro, configurar un periodo de espera de dependencias con --min-release-age (npm v11.10.0+) para no instalar paquetes publicados recientemente. Si puede ser configuración en lugar de disciplina, que sea configuración. Un procedimiento que depende de que alguien se acuerde suele saltarse en un día con mucho trabajo.
Haz inventario de tus tokens y reduce su vida y alcance
Pasa los tokens de acceso personal de GitHub de classic a fine-grained, acorta su caducidad y limítalos a los repositorios que los necesitan. No dejes tokens de publicación de npm guardados en CI. El manejo de claves y secretos se explica en qué es peligroso en .env y las claves de API y en mínimo privilegio para claves SSH. El objetivo es que un token robado pueda hacer poco daño.
Revisa tu propia cuenta de GitHub
Busca repositorios públicos que no creaste (nombres que terminan en -migration, descripciones desconocidas), flujos de GitHub Actions que no añadiste, configuración ejecutable dejada en .vscode/tasks.json o .claude/, y claves de API o SSH que no reconoces. Para vigilar de forma automática las vulnerabilidades conocidas en tus dependencias, consulta primeros pasos con osv-scanner.
Si sospechas una infección, sigue el orden correcto
Los investigadores insisten en un punto que vale la pena repetir: elimina cualquier componente residente que quede en el equipo (scripts que vigilan los tokens y similares) ANTES de revocar los tokens. Si inviertes el orden, la parte residente puede reaccionar a la revocación. A grandes rasgos:
1. Desconecta de la red
2. Elimina la persistencia y los archivos sospechosos
3. Revoca y vuelve a emitir en el orden npm → GitHub → nube → SSH → Kubernetes
4. Borra node_modules y las cachés y reinstala desde cero
5. Revisa tus repositorios públicos y el historial de publicación de paquetes
Si no tienes registros, la respuesta es «desconocido», no «limpio». Actúa como si te hubieran comprometido.
La opinión de este sitio: una firma acredita el origen, no la seguridad
Firmar y la procedencia han sido durante años la recomendación estrella para la cadena de suministro, y esta campaña las superó. No es una sorpresa: una firma te dice quién publicó algo, no si su contenido es seguro. Una firma válida de una cuenta comprometida es válida y peligrosa a la vez. Por eso tratamos la procedencia no como un control que te da seguridad, sino como una herramienta forense para delimitar el impacto tras un incidente. La prevención depende de otras dos cosas: no ejecutar código ajeno durante la instalación y no dejar secretos donde ese código se ejecuta.
Fuentes
- Unit 42 (Palo Alto Networks) — ChainDrop: Inside a Self-Propagating npm Worm (propagación, credenciales recogidas, indicadores)
- StepSecurity — ChainDrop npm Worm (indicadores de detección y orden de remediación)
- Elastic Security Labs — CHAINDROP worm hits 400+ npm packages
- Node.js, «Security Best Practices» — nodejs.org (vectores de ataque a la cadena de suministro y mitigaciones:
--ignore-scripts, lockfiles,npm ciy el periodo de espera--min-release-age; consultado el 5 de septiembre de 2026) - SecurityWeek — Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack (escala y secuencia)
- Wiz — Shai-Hulud npm Supply Chain Attack (la técnica de copiar repositorios privados como públicos)
Para seguir leyendo
- Un caso de 2026: la cadena TanStack, Nx Console y GitHub: qué deben comprobar los desarrolladores (en inglés)
- Práctica: vigila automáticamente los CVE de tus dependencias con osv-scanner / detén los secretos al hacer commit con gitleaks
- Fundamentos: qué es peligroso en .env y las claves de API / mínimo privilegio para claves SSH
- Comparación: Git autoalojado frente a GitHub: cuál es más seguro
- Fallos que llegan a través de dependencias: contaminación de prototipos en Node.js (cuenta aunque el merge lo haya escrito una dependencia)
- Términos: qué es el malware
- El patrón: las brechas de 2026 entraron con credenciales válidas (en inglés; la misma forma: un token robado realizando acciones normales)
FAQ
Q¿Cómo puede ejecutar npm install robar mis credenciales?
Porque los paquetes pueden incluir scripts que se ejecutan automáticamente durante la instalación (preinstall / postinstall). Añadir una dependencia equivale, por tanto, a dejar que ese código se ejecute con tus privilegios. ChainDrop usó exactamente eso para recoger credenciales de npm, GitHub, la nube, SSH y CI/CD.
Q¿Qué significa que los repositorios privados se publiquen?
Los gusanos de esta familia usan el token de GitHub robado para copiar los repositorios privados de la víctima en repositorios públicos; se han visto nombres que terminan en -migration. GitHub en sí no fue vulnerado: un token sacado de tu equipo o de tu CI realiza la acción con tus propios privilegios. Por eso esperar una corrección de la plataforma no te protege.
Q¿No son seguros los paquetes firmados y con procedencia?
Eso es justo lo que se eludió aquí. El atacante usó los privilegios del mantenedor para lanzar el flujo de publicación ya existente del proyecto, así que las versiones envenenadas salieron con procedencia válida. Una firma acredita quién publicó algo, no si su contenido es seguro. Una firma válida de una cuenta comprometida sigue siendo una firma válida.
Q¿Qué es lo más eficaz que puedo hacer hoy?
Dos cosas: desactivar por defecto los scripts de instalación (npm ci --ignore-scripts, o ignore-scripts=true en pnpm) y dejar de adoptar al instante las versiones recién publicadas, esperando unos días. Lo primero impide que el código llegue a ejecutarse; lo segundo evita el periodo más peligroso, las horas o días entre la publicación y la retirada.