NPM bajo ataque: el gusano que roba credenciales y pone en jaque tus pipelines de CI

El 4 de agosto de 2026 se detectó una campaña de envenenamiento en npm que comenzó con la liberación maliciosa [email protected] y se expandió rápidamente por múltiples nombres de paquete y organizaciones. Se trató de un gusano diseñado para robar credenciales, que se activaba mediante un script de preinstalación y desplegaba un binario empaquetado capaz de exfiltrar tokens y claves de repositorios, registros, nubes y runners de integración continua (CI), además de incluir mecanismos para publicar nuevas versiones con identidades robadas.

La telemetría de investigadores independientes no concordó en un único conteo definitivo: SafeDep verificó cientos de versiones maliciosas en decenas de paquetes, Aikido presentó un recuento aún mayor y otras observaciones registraron puntos parciales. El número total de paquetes o versiones informadas indica escala, pero no equivale al número de sistemas víctimas; dicha determinación exige comprobar la versión exacta resuelta en cada máquina y, sobre todo, si el script de ciclo de vida se llegó a ejecutar.

Desde el punto de vista técnico, la campaña usó un archivo preinstall que invocaba setup.mjs y desplegaba un bundle compilado que buscaba runtimes como Bun, descargaba componentes y luego ejecutaba código que exploraba memoria del runner, leía secretos en archivos y variables de entorno, y colocaba un "watcher" cuya función era observar revocaciones de tokens. Ese watcher plantea un riesgo operativo importante: rotar primero las credenciales puede disparar un controlador local suministrado por el atacante, por lo que los equipos de respuesta deben neutralizar el malware antes de comenzar la rotación.

La superficie de ataque fue mayor porque el repositorio comprometido también contenía hooks para editores y entornos de desarrollo: archivos de configuración de Claude Code y de Visual Studio Code que, si se confían, pueden ejecutar setup.mjs al abrir el proyecto. En entornos de desarrollo y en runners de CI hay dos vectores independientes —el instalador de npm y la configuración del workspace— y ambos deben considerarse potencialmente peligrosos.

La campaña dejó en evidencia que las garantías de procedencia y firma de build no son una panacea: varias de las releases envenenadas llevaron firmas válidas y atestaciones SLSA porque el flujo de publicación pasó por el pipeline legítimo del proyecto. Una atestación que verifica el proceso de construcción no garantiza por sí sola que el código fuente que entró en ese proceso sea inocuo, y por eso la verificación de la cadena de suministro debe incluir controles sobre el repositorio fuente y sobre quién controló las credenciales de publicación.

Para detectar exposición en su entorno, es imprescindible recurrir a las fuentes locales: inspeccione package-lock.json, npm-shrinkwrap.json, yarn.lock y pnpm-lock.yaml para localizar las versiones exactas resueltas; revise si en esos paquetes el manifest contenía un script preinstall o archivos sospechosos (por ejemplo setup.mjs o nombres inusuales incluidos en la publicación); y analice logs de CI y de instalación para ver si se ejecutaron scripts de ciclo de vida. No confíe en listas públicas de paquetes "latest" ni en bloqueos por nombre de espacio; la verificación debe ser por nombre exacto y versión.

La respuesta técnica inmediata debe combinar aislamiento y eliminación del malware con un plan coordinado de rotación de credenciales. Primero, ponga en cuarentena máquinas y runners sospechosos y busque y elimine el watcher o cualquier artefacto persistente que pueda reaccionar a la revocación. A continuación, rote claves, tokens y certificados comprometidos. Si se rota sin antes neutralizar el watcher, existe el riesgo de activar código del atacante que aproveche la rotación. Finalmente, reconstruya artefactos y contenedores desde fuentes de confianza y desde árboles de código verificados.

En infraestructuras CI/CD y en políticas de desarrollo hay medidas concretas para reducir exposición futura: actualizar a clientes npm que bloqueen scripts de ciclo de vida por defecto cuando sea compatible con su flujo, deshabilitar la ejecución automática de tareas de workspace en VS Code y Claude Code, adoptar tokens efímeros y OIDC para despliegues, restringir permisos de publicación en los registros y exigir autenticación multifactor y revisiones humanas para liberaciones críticas. La seguridad efectiva combina herramientas (p. ej. bloqueo de lifecycle scripts), políticas (principio de privilegio mínimo) y procesos (revisión de commits y control de acceso a credenciales).

Los equipos de mantenimiento de paquetes deben auditar su árbol de trabajo y la historia de commits buscando cambios que hayan propagado archivos sospechosos a múltiples subpaquetes. Preste atención a commits firmados o verificados por bots que, aunque muestren una insignia de verificación, no identifican quién controló la credencial que firmó la acción. La verificación de firma es necesaria pero no suficiente; combine esa señal con controles sobre quién tenía acceso al pipeline y con revisiones de la integridad del código fuente.

Para consumidores y organizaciones, la recomendación práctica inmediata es identificar instancias concretas que pudieron instalar versiones afectadas y determinar si se ejecutaron scripts de instalación. Si confirma ejecución, aísle la máquina y el runner, preserve evidencias y proceda a limpieza y rotación de secretos según el orden descrito. Si no está seguro del estado de ejecución, trate las máquinas como potencialmente expuestas hasta demostrar lo contrario con imágenes o rebuilds desde fuentes limpias.

Para profundizar en las prácticas de verificación de firmas y en el marco SLSA recomendado para atestaciones de la cadena de suministro, consulte la documentación oficial de GitHub sobre verificación de firmas About commit signature verification y los principios del proyecto SLSA en slsa.dev. Para análisis de campañas y compromisos de repositorios, recursos como el blog de Semgrep recopilan ejemplos útiles y reglas que se pueden aplicar en escaneos de repositorio; vea su página de publicaciones en Semgrep Blog.

Este incidente subraya una lección clave: las defensas de la cadena de suministro deben ser proactivas, centradas en la precisión (versiones resueltas y lockfiles) y en la higiene de credenciales. Las organizaciones deben revisar sus procesos de publicación, endurecer pipelines, limitar el blast radius de tokens y preparar playbooks de respuesta que contemplen la campaña de rotación ordenada de secretos tras la eliminación de cualquier mecanismo de vigilancia instalado por el atacante.