La próxima versión principal de npm, la v12, prevista para julio de 2026, dejará de ejecutar scripts de instalación de dependencias por defecto.
Nos alivia saberlo. Desactivar los scripts de instalación es el cambio más útil que npm podría introducir en sus valores por defecto. La comunidad sufrió una avalancha de ataques a la cadena de suministro el año pasado, como Nx s1ngularity y Shai-Hulud, que explotaron scripts postinstall. Esta actualización de npm es un cambio muy esperado que reducirá un enorme vector de ataques a la cadena de suministro.
Qué está cambiando npm
Cuando ejecutas npm install hoy, cualquier paquete en cualquier parte de tu árbol de dependencias puede definir scripts de ciclo de vida llamados preinstall, install, o postinstall, y npm los ejecuta automáticamente por ti. El código se ejecuta en el momento de la instalación, antes de que importes nada o ejecutes tu propio código.
La v12 pone fin a esto. Los scripts solo se ejecutarán para los paquetes que hayas incluido en una lista de permitidos, que se construye con `npm approve-scripts`, bloqueando el resto con `npm deny-scripts`, y se confirma junto con el resto de tu proyecto.
Se incluyen otros cambios menores. Las dependencias de Git ya no se resuelven a menos que pases --allow-git, lo que cierra una ruta de ejecución más silenciosa donde el npmrc de una dependencia de Git podría sobrescribir el ejecutable de Git y ejecutar código incluso con --ignore-scripts establecido. Las dependencias de URL remotas, como los tarballs HTTPS, también dejan de resolverse a menos que pases --allow-remote, cerrando una ruta donde un atacante podría apuntar una dependencia a una URL externa que controla e intercambiar la carga útil en cualquier momento.
La lista de permitidos también cubre código que nunca aparece en el campo de scripts. Cuando un paquete incluye un `binding.gyp`, npm ejecuta una reconstrucción implícita de `node-gyp` para él durante la instalación, por lo que una dependencia con un `package.json` impecable aún puede ejecutar código simplemente al contener ese archivo de compilación. La v12 trata esa compilación como un script declarado, por lo que será bloqueada a menos que el paquete esté en tu lista de permitidos. Nuestro equipo de investigación ha trazado recientemente lo extraña y peligrosa que es esta posible ruta de ataque.
Todo esto ya está en npm 11.16.0, con advertencias, para que puedas ver qué se rompe antes de actualizar.
Los exploits postinstall que la modificación de npm corrige
Casi todos los gusanos y ladrones de credenciales que afectaron a npm desde el otoño pasado se ejecutaron durante el tiempo de instalación en lugar de en tiempo de ejecución. El patrón para estos generalmente implica que un atacante primero toma el control de un paquete de confianza, normalmente mediante phishing en la cuenta de npm de un mantenedor o robando un token de publicación. Luego, los atacantes publican una nueva versión con un script postinstall añadido a su `package.json`, a menudo dejando el código fuente real intacto, para que nada parezca obviamente fuera de lugar.
Cuando alguien ejecuta `npm install`, npm ejecuta ese script automáticamente como el usuario. Identifica la máquina, descarga la carga útil real de un servidor del atacante, la ejecuta y se elimina, mientras la carga útil busca tokens, claves SSH y otros elementos valiosos, y luego los envía.
En estos ataques, ni siquiera tienes que usar el paquete malicioso o importarlo para ser una víctima. Solo tienes que tener la mala suerte de ejecutar npm install mientras el paquete está infectado.
Con el valor por defecto de la v12, la instalación se detendría en el paquete malicioso a menos que ese paquete exacto esté en la lista de permitidos que has confirmado. El atacante aún puede publicar la versión envenenada, pero en una máquina con la v12, permanecerá como archivos inertes en `node_modules`.
Por qué esto es importante
La ola de ataques mediante scripts postinstall comenzó el otoño pasado y no ha cesado. Vimos este ataque a un paquete de Red Hat hace apenas una semana. Algunos de los grandes ataques que se aprovecharon de esto y mantuvieron a nuestros investigadores de seguridad despiertos por la noche incluyen:
- Nx s1ngularity, agosto de 2025. Un token de publicación robado publicó versiones maliciosas de Nx cuyo script post-instalación, telemetry.js, se ejecutó en la instalación. Recopiló tokens de GitHub, credenciales de npm, claves SSH y monederos de criptomonedas, y luego los subió a repositorios públicos de GitHub. Las aproximadamente 2.300 credenciales que recopiló sirvieron para sembrar futuros ataques.
- Shai-Hulud, noviembre de 2025. Un gusano autorreplicante que afectó a cerca de 500 paquetes en Zapier, ENS, PostHog, Postman y AsyncAPI, instaló el runtime de Bun durante la configuración, ejecutó TruffleHog para extraer secretos y los volcó en repositorios públicos de GitHub.
- The axios hijack, marzo de 2026. Una cuenta de mantenedor secuestrada envió una dependencia que solo existía para ejecutar un hook de postinstalación y soltar un RAT multiplataforma. axios realiza aproximadamente 100 millones de descargas a la semana.
- Mini Shai-Hulud, mayo de 2026. Un gusano derivado del Shai Hulud original, que insertó un hook de preinstalación que descargó el runtime de Bun y ejecutó un ladrón de credenciales. Se propagó a través de más de cien paquetes en TanStack, UiPath y Mistral AI, convirtiéndose en el primer gusano de npm en publicar malware con procedencia de compilación válida.
Esto no es solo un problema de npm, aunque npm es el objetivo más grande. La misma idea aparece en otros ecosistemas, como Composer de PHP, donde más de 200 versiones de Laravel-Lang fueron reescritas en mayo para ejecutar automáticamente un ladrón de credenciales a través del autoloader (Composer ahora cuenta con filtrado de malware nativo impulsado por Aikido para proteger a los usuarios downstream).
¿Qué hacer ahora?
Actualice a npm 11.16.0 o posterior, ya que los tres cambios ya están disponibles con advertencias. Si ya está en 11.15.0+, --allow-git ya está disponible, y --allow-remote desde 11.15.0, por lo que puede empezar a bloquearlos sin esperar a la v12. Para los scripts, ejecute npm approve-scripts --allow-scripts-pending para ver qué se bloquearía, apruebe los paquetes en los que confía y confirme el actualizado package.json. Todo lo que omita dejará de ejecutarse cuando llegue la v12. Revise esto, porque muchos paquetes legítimos utilizan scripts de instalación para compilaciones nativas y configuración, y una vez que el valor predeterminado cambie, esas instalaciones necesitarán aprobación.
También puede instalar Safe Chain de Aikido, un wrapper seguro y gratuito para npm, npx y yarn que se integra en su flujo de trabajo actual y verifica cada paquete en busca de malware antes de la instalación. Le impide instalar malware accidentalmente y aplica un período de espera en las nuevas versiones de paquetes, lo que evita que un buen número de paquetes comprometidos lleguen a su dispositivo.
Los buenos valores por defecto protegen a las personas que nunca abren un changelog (que es casi todo el mundo, casi todo el tiempo, excepto los investigadores de seguridad y los apropiadamente paranoicos). Que npm haga esto seguro por defecto es la decisión correcta. No debería haber tardado un año de estragos públicos en suceder, y no lo resolverá todo, pero nos alegra que esté aquí.
