Tu agente de código añade una dependencia para terminar una app, haces push y Vercel detiene el despliegue. En el log aparece el nombre y la versión de un paquete npm bloqueado. Es tentador quitar el error como sea para sacar la web hoy; aquí conviene hacer lo contrario: entender qué versión llegó al proyecto y cambiarla con el lockfile. Desde el 2 de noviembre de 2026, Vercel anunció controles automáticos antes y durante la instalación de dependencias en los builds nuevos.
La novedad importa a quienes construyen rápido con IA porque una sugerencia de instalación puede acabar en producción sin que nadie revise el árbol de dependencias. Según el [anuncio oficial](https://vercel.com/changelog/blocking-malicious-npm-packages-before-and-during-installation), Vercel consulta una lista de versiones específicas bloqueadas por malware o vulnerabilidades. Revisa lockfiles compatibles antes de instalar, incluso cuando se restaura una caché de build, y bloquea descargas afectadas del npm público durante la instalación. Si detecta una versión bloqueada, falla el despliegue, muestra paquete y versión e intenta invalidar la caché afectada.
Qué cambia y quién lo recibe
El control se aplica automáticamente a los builds nuevos en todos los planes, sin configuración adicional, según Vercel. No hay que activar una bandera ni cambiar el SDK. Eso no significa que Vercel haya auditado todo tu proyecto o garantice que cada paquete descargado es seguro: su anuncio habla de una lista de versiones seleccionadas y de controles en fases concretas del build. Tampoco confirma por sí mismo que una app ya desplegada esté libre de riesgos. La decisión práctica es tratar un fallo por paquete bloqueado como señal de seguridad, no como ruido de CI.
Qué hacer cuando un build se detiene
- Lee el error exacto. Anota nombre, versión y fase del build. No supongas que el paquete está declarado directamente en tu
package.json; puede llegar como dependencia transitiva. Conserva el log para la revisión, sin pegar secretos del entorno en un chat. - Encuentra quién lo trae. Si el proyecto usa npm y tienes un entorno local confiable con dependencias instaladas, ejecuta
npm explain NOMBRE_DEL_PAQUETE, sustituyendo el marcador por el nombre del log. La [documentación de npm](https://docs.npmjs.com/cli/v11/commands/npm-explain/) explica que este comando muestra la cadena que hizo instalar el paquete. Si no hay entorno seguro para ejecutar código de ese árbol, inspecciona primero el lockfile y la dependencia que lo referencia. - Actualiza la causa, no solo el síntoma. Si es dependencia directa, elige una versión corregida y compatible tras revisar la recomendación del mantenedor. Si es transitiva, actualiza el paquete padre o aplica una resolución controlada que tu gestor soporte. Regenera el lockfile con el mismo gestor usado por el proyecto. Borrar el lockfile a ciegas puede cambiar muchas versiones y hacer difícil saber qué arregló el problema.
- Verifica el cambio. Revisa el diff de
package.jsony del lockfile, ejecuta pruebas en un entorno aislado y vuelve a desplegar. Comprueba que el build ya no reporta esa versión y que la app funciona. Si el paquete ya se ejecutó en un entorno con credenciales, el incidente puede exigir una revisión adicional; un build posterior exitoso no borra lo que pudo ocurrir antes.
npm audit puede complementar la revisión de vulnerabilidades conocidas; [npm explica](https://docs.npmjs.com/cli/v11/commands/npm-audit/) que consulta el registro configurado y calcula remediaciones. No es una prueba de que el paquete bloqueado por Vercel aparezca allí ni sustituye el error específico del despliegue. Evita npm audit fix --force solo para hacer pasar CI: puede cambiar versiones mayores y generar un problema funcional distinto.
La prueba útil de esta semana
Abre el último despliegue de una app Vercel y confirma qué gestor y lockfile usa; documenta quién revisaría un bloqueo y cómo se aprobaría una actualización. Si tienes un fallo real, sigue el recorrido anterior y registra versión inicial, versión corregida, diff y resultado del nuevo build. No instales un paquete malicioso para provocar el aviso. Esta nota se basa en el anuncio y la documentación primaria; no he reproducido un bloqueo con una cuenta de Vercel ni afirmo una tasa de detección. La utilidad está en saber cómo responder cuando el control actúe.
Fuentes: Vercel, anuncio del 2 de noviembre de 2026; npm explain; npm audit.