Next.js lanza avisos de seguridad formales: qué cambia

Next.js ha lanzado un programa formal de avisos de seguridad que centraliza las vulnerabilidades del framework en GitHub Security Advisories con numeración CVE propia. Para las empresas que corren aplicaciones Next.js en producción esto significa notificaciones estructuradas y verificables, pero también una ventana de explotación más corta: en cuanto se publica el aviso, un atacante tiene la misma información que tú para construir el exploit.

Hasta ahora, cuando aparecía un fallo de seguridad en Next.js, el aviso solía llegar disperso: un commit en GitHub sin etiquetar como fix de seguridad, un hilo en Discord, o una nota breve en el changelog de una versión menor. El nuevo programa cambia ese flujo: cada vulnerabilidad relevante recibe un identificador CVE propio, un GitHub Security Advisory (GHSA) con descripción técnica, versión afectada, versión parcheada y vector de ataque documentado según el estándar CVSS. Esto no es cosmético. Un CVE con GHSA asociado entra automáticamente en los feeds que alimentan herramientas de escaneo de dependencias como Dependabot, Snyk o npm audit, lo que dispara alertas en cualquier pipeline de CI/CD que las tenga configuradas. Antes, una empresa podía pasar semanas sin enterarse de que su versión de Next.js tenía un fallo crítico salvo que siguiera manualmente el repositorio. Ahora, si tiene el escaneo de dependencias activado, la alerta llega sola.

Por qué Vercel se convirtió en CVE Numbering Authority (CNA)

El detalle técnico que casi ningún artículo explica es que Vercel, la empresa detrás de Next.js, ha asumido el rol de CNA (CVE Numbering Authority) para el framework. Esto significa que ya no depende de un tercero para asignar el identificador CVE: puede reservarlo, coordinar el embargo con quien reporta el fallo, y publicar el aviso y el parche de forma sincronizada. En la práctica, esto acorta el tiempo entre que alguien encuentra el fallo y que el mundo se entera, porque elimina intermediarios burocráticos. También le da a Vercel control total sobre el mensaje: decide qué severidad asigna, qué mitigaciones recomienda y cuándo se hace público. Para una empresa que depende de Next.js, esto es una mejora real de transparencia frente al modelo anterior, donde muchos fixes de seguridad se colaban silenciosamente en releases menores sin ninguna etiqueta que los distinguiera de un bugfix normal.

Aquí está la parte contraintuitiva que conviene entender antes de asumir que ahora todo es más seguro. Un aviso formal con CVE, GHSA y descripción técnica detallada no solo informa a los defensores: también le da al atacante un mapa exacto de qué buscar. En cuanto Vercel publica el parche junto al aviso, cualquiera puede comparar el commit de la corrección contra la versión vulnerable y deducir el vector de ataque exacto, incluso sin haber encontrado el fallo por su cuenta. Esta técnica, conocida como explotación n-day, es precisamente lo que ocurrió con CVE-2025-29927: en cuestión de días desde la publicación del aviso aparecieron pruebas de concepto públicas explotando el bypass de autorización en producción. La formalización del proceso reduce la ambigüedad, pero comprime la ventana entre saber que existe un fallo y que haya un exploit funcional circulando. Para una empresa, esto convierte la velocidad de parcheo en el factor que de verdad importa, más que la calidad del aviso en sí.

La verdad incómoda que conviene decir sin rodeos: si tu aplicación Next.js no corre sobre la infraestructura de Vercel, el programa de avisos de seguridad no te protege automáticamente de nada. Cuando apareció CVE-2025-29927, Vercel desplegó mitigaciones de WAF a nivel de plataforma para sus clientes hospedados, bloqueando las cabeceras maliciosas que explotaban el fallo antes incluso de que las empresas actualizaran el paquete. Quien corre Next.js autoalojado, en un VPS, en Docker propio o en Kubernetes, no tuvo esa red de seguridad: dependía por completo de aplicar el parche manualmente. La mayoría de pymes españolas que usan Next.js lo hacen en infraestructura propia o de terceros distintos de Vercel, por control de costes o por requisitos de residencia de datos, así que este matiz no es marginal. Y hay un problema previo aún más básico: muchas empresas ni siquiera saben con certeza qué versión exacta de Next.js tienen fijada en producción, porque el package-lock.json no se revisa desde el despliegue inicial.

• Comprueba la versión exacta desplegada con next --version en el servidor de producción, no la del repositorio.
• Verifica si tu hosting es Vercel (mitigación automática de plataforma) o autoalojado (parcheo manual obligatorio).
• Activa alertas de Dependabot o Snyk sobre el repositorio para recibir el aviso en cuanto se publique el GHSA.
• Revisa si tu aplicación usa middleware.ts para control de acceso: fue el vector exacto de CVE-2025-29927.

Aquí conviene ser honestos: no todas las empresas necesitan contratar una auditoría de seguridad externa para gestionar esto. Si tu equipo ya tiene un proceso mínimamente disciplinado de actualización de dependencias y un pipeline de CI/CD con escaneo activado, el programa formal de avisos de Next.js simplemente hace ese proceso más fiable, no añade una carga nueva. El problema real no suele ser la falta de herramientas, sino la falta de disciplina para actuar cuando la alerta llega: equipos que ven la notificación de Dependabot y la posponen porque ya se verá en el siguiente sprint. Para la mayoría de pymes, la solución no es más presupuesto en seguridad sino un acuerdo interno simple: quién revisa las alertas de dependencias, con qué frecuencia, y qué plazo de parcheo se aplica según la severidad del CVE.

• Definir un plazo interno de parcheo por severidad (ej: crítico 48h, alto 1 semana)
• Asignar a una persona responsable de revisar alertas de Dependabot o Snyk cada semana
• Documentar si el despliegue es Vercel o autoalojado, y quién aplica el parche en cada caso
• Auditar el uso de middleware.ts y validar que la autorización no dependa solo de cabeceras
• Suscribirse al feed de GitHub Security Advisories del repositorio vercel/next.js

Cuándo sí conviene pedir ayuda externa

La ayuda externa tiene sentido cuando la aplicación Next.js maneja datos sensibles (financieros, sanitarios, de clientes) y el equipo interno no tiene capacidad para mantener un plazo de parcheo real, cuando hay múltiples aplicaciones desplegadas en infraestructura autoalojada sin un inventario claro de versiones, o cuando ya ha habido un incidente previo relacionado con dependencias desactualizadas. También conviene una revisión puntual si el middleware de la aplicación gestiona autenticación o control de acceso, dado que fue exactamente el punto débil del fallo más grave conocido hasta ahora en el framework. Fuera de esos escenarios, una empresa con buena higiene interna de dependencias no necesita un servicio recurrente para esto.