La próxima versión principal de npm, la v12, cuyo lanzamiento está previsto para julio de 2026, dejará de ejecutar scripts de instalación de dependencias de forma predeterminada.
Nos alegra saberlo. Desactivar los scripts de instalación es el cambio más útil que npm podría introducir en su configuración predeterminada. La comunidad sufrió una avalancha de ataques a la cadena de suministro el último año, como Nx s1ngularity y Shai-Hulud, que aprovechaban los scripts de postinstalación. Esta actualización de npm es un cambio muy esperado que reducirá un importante vector de ataque a la cadena de suministro.
Qué cambios va a introducir npm
Cuando ejecutas npm install Hoy en día, cualquier paquete del árbol de dependencias puede definir scripts de ciclo de vida denominados preinstall, instalar, o postinstall, y npm los ejecuta automáticamente por ti. El código se ejecuta en el momento en que lo instalas, antes de que importes nada o ejecutes tu propio código.
La versión 12 pone fin a eso. Los scripts solo se ejecutan para los paquetes que hayas incluido en una lista de permitidos, que se crea con «npm approve-scripts», mientras que el resto se bloquea con «npm deny-scripts» y se integra junto con el resto del proyecto.
También incluye algunos otros cambios menores. Las dependencias de Git ya no se resuelven a menos que se especifique --allow-git, lo que cierra una vía de ejecución más discreta en la que el archivo npmrc de una dependencia de Git podría anular el ejecutable de Git y ejecutar código incluso con --ignore-scripts configurado. Las dependencias de URL remotas, como los archivos tar de https, tampoco se resuelven a menos que se especifique --permitir-remoto, lo que impide que un atacante pueda dirigir una dependencia a una URL externa bajo su control y sustituir la carga útil en cualquier momento.
La lista de permitidos también incluye código que nunca aparece en el campo «scripts». Cuando un paquete incluye un archivo «binding.gyp», npm ejecuta una reconstrucción implícita de «node-gyp» durante la instalación, por lo que una dependencia con un archivo «package.json» impecable puede ejecutar código simplemente por contener ese único archivo de compilación. La versión 12 trata esa compilación como si fuera un script declarado, por lo que se bloqueará a menos que el paquete figure en tu lista de permitidos. Nuestro equipo de investigación ha analizado recientemente lo extraña y peligrosa que es esta posible vía de ataque.
Todo esto ya está incluido en npm 11.16.0, aunque con advertencias, por lo que puedes ver qué es lo que deja de funcionar antes de actualizar.
Los vulnerabilidades postinstalación que corrige la actualización de npm
Casi todos los gusanos y programas de robo de credenciales que han afectado a npm desde el otoño pasado se ejecutaban durante la instalación, en lugar de durante el tiempo de ejecución. El patrón habitual consiste en que el atacante se apodera primero de un paquete de confianza, normalmente mediante un ataque de phishing a la cuenta de npm del mantenedor o el robo de un token de publicación. A continuación, los atacantes publican una nueva versión con un script de postinstalación añadido a su archivo package.json, dejando a menudo el código fuente original intacto, de modo que nada parece sospechoso a simple vista.
Cuando alguien ejecuta «npm install», npm ejecuta ese script automáticamente en nombre del usuario. El script identifica el equipo, descarga la carga útil real desde un servidor del atacante, la ejecuta y se elimina a sí mismo, mientras que la carga útil busca tokens, claves SSH y otros datos valiosos, para luego enviarlos
En estos ataques, ni siquiera hace falta utilizar el paquete malicioso ni importarlo para convertirse en víctima. Basta con tener la mala suerte de ejecutar npm install mientras el paquete está infectado.
Con la configuración predeterminada de la versión 12, la instalación se detendría al llegar al paquete malicioso, a menos que ese paquete concreto figure en la lista de permitidos que hayas configurado. El atacante aún puede publicar la versión maliciosa, pero en un equipo con la versión 12, esta permanecerá allí como archivos inactivos en «node_modules».
Por qué es importante
La oleada de ataques mediante scripts postinstalación comenzó el otoño pasado y, en realidad, no ha cesado. Hace apenas una semana observamos este tipo de ataque en un paquete de Red Hat. Entre los ataques más graves que se aprovecharon de esta vulnerabilidad y que mantuvieron despiertos a nuestros investigadores de seguridad durante la noche se encuentran:
- Nx Singularity, agosto de 2025. Un token de publicación robado propició la difusión de versiones maliciosas de Nx cuyo script de postinstalación, telemetry.js, se ejecutaba durante la instalación. Este script recopilaba tokens de GitHub, credenciales de npm, claves SSH y carteras de criptomonedas, y luego los subía a repositorios públicos de GitHub. Las aproximadamente 2300 credenciales que recopiló sirvieron de base para 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 entorno de ejecución Bun durante la configuración, ejecutó TruffleHog para extraer datos confidenciales y los publicó en repositorios públicos de GitHub.
- El secuestro de axios, marzo de 2026. Una cuenta de mantenedor secuestrada distribuyó una dependencia cuyo único propósito era ejecutar un gancho de postinstalación e instalar un RAT multiplataforma. Axios registra unos 100 millones de descargas a la semana.
- Mini Shai-Hulud, mayo de 2026. Un gusano derivado del Shai-Hulud original, que insertaba un gancho preinstalado que extraía el tiempo de ejecución de Bun y ejecutaba un programa de robo de credenciales. Se propagó a través de más de un centenar de paquetes en TanStack, UiPath y Mistral AI, y se convirtió en el primer gusano de npm en publicar malware con una procedencia de compilación válida.
No se trata solo de un problema de npm, aunque este sea el principal objetivo. La misma idea se da en otros ecosistemas, como Composer de PHP, donde en mayo se reescribieron más de 200 versiones de Laravel-Lang para ejecutar automáticamente un programa de robo de credenciales a través del autocargador (Composer cuenta ahora con un filtro de malware nativo basado en Aikido para proteger a los usuarios finales).
¿Qué hacer ahora?
Actualiza a npm 11.16.0 o una versión posterior, ya que los tres cambios ya están incluidos, aunque con advertencias. Si ya tienes la versión 11.15.0 o superior, --allow-git ya está disponible, y...-permitir-remoto desde la versión 11.15.0, así que ya puedes empezar a configurarlas sin esperar a la versión 12. Para los scripts, ejecuta npm approve-scripts --allow-scripts-pending para ver qué se bloquearía, aprueba los paquetes en los que confías y confirma la actualización package.json. Todo lo que omitas dejará de funcionar cuando se lance la versión 12. Comprueba esto, ya que muchos paquetes legítimos utilizan scripts de instalación para la compilación nativa y la configuración, y una vez que cambie la configuración predeterminada, esas instalaciones necesitarán aprobación.
También puedes instalar Safe Chain de Aikido, un envoltorio de seguridad gratuito para npm, npx y yarn que se integra en tu flujo de trabajo actual y comprueba si hay malware en cada paquete antes de instalarlo. Evita que instales malware por error y aplica un periodo de espera a las nuevas versiones de los paquetes, lo que impide que un buen número de paquetes comprometidos lleguen a tu dispositivo.
Una buena configuración predeterminada protege a quienes nunca leen el registro de cambios (es decir, casi todo el mundo, casi siempre, salvo los investigadores de seguridad y los que tienen un nivel adecuado de recelo). Que npm haya optado por esta configuración segura de forma predeterminada es una decisión acertada. No debería haber hecho falta un año de caos público para que esto ocurriera, y no lo resolverá todo, pero nos alegra que se haya hecho.
