Introducción
Los equipos de DevOps y seguridad que gestionan dependencias JavaScript con npm enfrentan un cambio disruptivo en su flujo de trabajo. npm 12, liberado el 14 de agosto de 2026, invertió el comportamiento por defecto de tres mecanismos de ejecución de código durante la instalación de paquetes, passing de opt-out a opt-in. Este ajuste, anunciados originalmente en junio y disponibles con advertencias desde npm 11.16.0, busca cerrar vectores de ataque explotados en el 53% de los incidentes maliciosos reportados en el ecosistema npm durante el último año según JFrog.
Qué ocurrió
npm 12 modificó tres configuraciones clave para requerir consentimiento explícito. El cambio más visible es que allowScripts ahora defaulta a false, desactivando la ejecución automática de scripts preinstall, install y postinstall durante npm install. Esto incluye los builds implícitos de node-gyp para paquetes con archivos binding.gyp, incluso si no declaran un script de instalación explícito. También se bloquearon los scripts prepare de dependencias provenientes de Git, archivos locales o links simbólicos.
Los otros dos cambios afectan fuentes externas al registry oficial:
- –allow-git ahora defaulta a none, eliminando la descarga de dependencias desde repositorios Git.
- –allow-remote defaulta a none, bloqueando la instalación desde tarballs HTTPS.
Estos cambios no afectan las banderas –allow-file y –allow-directory, que mantienen su comportamiento anterior.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto más inmediato se observará en pipelines de CI/CD y entornos de desarrollo donde npm install ejecutaba scripts automáticamente. Paquetes populares como esbuild, sharp, core-js, puppeteer y bcrypt dependen de scripts de lifecycle para funcionalidades critiques (compilación de binarios, descarga de assets, etc.). Según datos de GitHub, estos paquetes tienen millones de descargas semanales: sharp supera los 15 millones, core-js los 60 millones y puppeteer los 10 millones.
La adopción de este modelo de confianza explícita tiene implicancias para la seguridad:
- Reducción de superficie de ataque: Los tres vectores modificados (scripts, Git dependencies, remote tarballs) fueron usados en el 53% de los ataques maliciosos a npm en el último año. El CVSS base score para ejecutar código arbitrario via postinstall scripts es 7.8 ( Alto).
- Cambio en la visibilidad: Los ataques podrían migrar a vectores menos monitorizados, como prepublish scripts o hooks de Git.
- Riesgo de fatiga de aprobar: Los equipos deberán revisar y aprobar scripts para cada nueva dependencia, lo que podría llevar a aceptar solicitudes sin análisis adecuado.
Para los equipos de infraestructura, el impacto se extiende a:
- Tiempo de build: Los pipelines deberán incluir pasos para aprobar scripts, aumentando la duración de las builds.
- Mantenimiento: Las dependencias transitivas que requieran scripts podrán romper builds existentes.
- Gestión de secretos: Los scripts que antes consumían variables de entorno (como NODE_ENV) ahora requieren aprobarse explícitamente.
Detalles técnicos
Comportamiento de allowScripts
Con allowScripts=false (default en npm 12), los siguientes scripts no se ejecutan:
- preinstall, install, postinstall (de cualquier dependencia)
- prepublish, postpublish (solo durante npm publish)
- prepare (excepto para el package root)
- Builds implícitos de node-gyp (para paquetes con binding.gyp o gypfile)
Para aprobar scripts, npm 12 introduce dos nuevos comandos:
npm approve-scripts
npm deny-scripts
El flujo de trabajo recomendado es:
{
«npmInstallScripts»: {
«allow»: [«canvas», «sharp»]
}
}
Limitaciones conocidas:
- Si el proyecto tiene ignore-scripts=true en .npmrc, este toma precedencia y silencia la allowlist.
- npm approve-scripts falla con ENOMATCH si el paquete no está instalado (problema de «huevo y gallina» para nuevas dependencias).
Configuración para casos especiales
Para instalar paquetes que requieren scripts (como canvas o sharp) globalmente o via npx, se debe usar la configuración:
npm config set allow-scripts=canvas,sharp –location=user
Cambios en fuentes de dependencias
- Git dependencies: Requerirán –allow-git o la configuración allow-git en .npmrc.
- Remote tarballs: Requerirán –allow-remote o la configuración allow-remote.
Versiones afectadas
- Los cambios están disponibles desde npm 11.16.0 (con warnings)
- npm 12.0.0 (14 de agosto de 2026) los activa por defecto
- Node.js 20+ incluye npm 10.x por defecto; los usuarios deberán actualizar manualmente a npm 12.
Qué deberían hacer los administradores y equipos técnicos
Para pipelines de CI/CD
npm install -g npm@12
O usar la imagen oficial de Node.js 22 (que incluirá npm 12).
npm ls –scripts
Identificar paquetes con scripts preinstall, install, postinstall o prepare.
– Para proyectos existentes:
npm install –omit=script
npm approve-scripts –all
Revisar y editar el package.json generado.
– Para nuevos proyectos, empezar con una allowlist vacía y aprobar scripts bajo demanda.
– Para paquetes como sharp o canvas, agregar a npmInstallScripts.allow en package.json.
– Para dependencias de Git o remote tarballs, configurar allow-git o allow-remote en .npmrc:
allow-git=true
– Documentar el nuevo flujo de trabajo para onboarding de desarrolladores.
– Actualizar runbooks de recuperación para fallas de build por scripts no aprobados.
Para entornos de desarrollo
– Asegurar que los editors (VS Code, etc.) usen npm 12 para la detección de dependencias.
– Configurar allow-scripts a nivel de usuario para herramientas globales:
npm config set allow-scripts=true –location=user
(Solo si es aceptable el riesgo para herramientas de desarrollo).
– Usar npm why para entender por qué un paquete requiere scripts antes de aprobarlo.
– Considerar alternativas sin scripts para paquetes problemáticos (ej: esbuild tiene una versión sin scripts para uso programático).
– Configurar alertas para fallas de build causadas por scripts no aprobados.
– Revisar logs de npm install en busca de advertencias sobre scripts bloqueados.
Para equipos de seguridad
– Actualizar políticas de gestión de dependencias para requerir approval explicita de scripts.
– Incluir la allowlist de scripts en los scans de seguridad de package.json.
– Auditar prepublish scripts en paquetes internos (se ejecutan durante npm publish).
– Revisar hooks de Git (como pre-commit) que podrían ser abuseados.
– Explicar los riesgos de aprobar scripts sin revisión (ej: CVE-2021-41117, donde un postinstall en node-ipc inyectaba código malicioso).
– Proporcionar guías para evaluar la legitimidad de scripts (ej: verificar el repositorio del paquete, el maintainer, el contenido del script).
Conclusión
npm 12 marca un cambio de paradigma en la gestión de dependencias JavaScript, alineándose con las prácticas de seguridad ya adoptadas por pnpm, Yarn y bun. Aunque el cambio reduce significativamente la superficie de ataque, su efectividad dependerá de cómo los equipos manejen el nuevo proceso de approval. La migración requerirá esfuerzo inicial para auditar y configurar scripts, pero el resultado será un supply chain más seguro y predecible. Para minimizar la fricción, los equipos deberían priorizar la actualización de pipelines y documentar claros criterios para aprobar scripts.
Fuentes
- https://www.infoq.com/news/2026/08/npm-12-released/
- https://github.com/npm/cli/releases/tag/v12.0.0
- https://github.com/npm/cli/discussions/7126
- https://jfrog.com/blog/npm-malicious-packages-real-time-blocked-by-jfrog/