Next.js mayo 2026: 13 vulnerabilidades críticas, actualiza ahora

El 7 de mayo de 2026, Vercel publicó el security release coordinado más grande en la historia de Next.js: 13 advisories que cubren denial of service, bypass de autorización en middleware, SSRF, cache poisoning y XSS. Si tienes Next.js en producción, necesitas leer esto ahora.

El resumen ejecutivo

Categoría	Severidad máxima	Afecta a
Middleware/proxy bypass	High	Apps con autenticación en middleware
Denial of Service	High	Apps con RSC, Cache Components, Image API
SSRF	High	Apps con WebSocket upgrades
Cache poisoning	Moderate	Apps con caching delante de RSC
XSS	Moderate	Apps con CSP nonces o scripts externos

Versiones afectadas: Next.js 13.x, 14.x (todas), 15.x ≤ 15.5.17, 16.x ≤ 16.2.5.

Versiones parcheadas: 15.5.18 y 16.2.6.

Si estás en Next.js 13 o 14, necesitas migrar. No hay parches retroactivos para esas versiones.

El problema más grave: bypass de autorización en middleware

La categoría con más CVEs y la que más me preocupa desde el punto de vista arquitectónico. Si usas middleware.js o proxy.js para proteger rutas, varias de estas vulnerabilidades permiten saltarse esa capa por completo.

// middleware.ts — patrón común de protección
export function middleware(request: NextRequest) {
  const token = request.cookies.get('session');

  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
};

Este patrón, que mucha gente usa como única capa de autorización, es exactamente lo que varias de estas vulnerabilidades permiten eludir. Los vectores identificados incluyen:

• Segment-prefetch URL bypass: rutas con prefetch especialmente construidas pueden eludir el matcher del middleware.
• i18n default-locale path bypass: en apps con internacionalización, la ruta de locale por defecto en Pages Router no pasaba por el proxy correctamente.
• Dynamic route parameter injection: parámetros de ruta dinámica manipulados evitan la ejecución del middleware.

La lección de fondo es la misma de siempre: el middleware de Next.js no debe ser tu única línea de defensa. La autorización real tiene que ocurrir también en los Server Components y en las API routes.

// ✅ Defensa en profundidad: validar también en el Server Component
// app/dashboard/page.tsx
import { auth } from '@/lib/auth';
import { redirect } from 'next/navigation';

export default async function DashboardPage() {
  const session = await auth();

  if (!session) {
    redirect('/login');
  }

  // Ahora sí, renderizar el contenido
  return <Dashboard user={session.user} />;
}

DoS en React Server Components (CVE-2026-23870)

Este es especialmente interesante porque es una vulnerabilidad en React, no en Next.js, que fue identificada y corregida de forma coordinada. Afecta a aplicaciones que usan Server Functions (antes conocidas como Server Actions).

Una request especialmente construida puede provocar un bucle infinito en el proceso de deserialización del payload RSC, consumiendo CPU hasta tumbar el proceso.

El fix está en react-server-dom-* 19.0.6 / 19.1.7 / 19.2.6. Si usas Turbopack, Webpack o Parcel como bundler, necesitas actualizar el paquete específico de tu toolchain:

# Con Turbopack (Next.js 15+)
pnpm add react-server-dom-turbopack@19.2.6

# Con Webpack (Next.js clásico)
pnpm add react-server-dom-webpack@19.2.6

SSRF via WebSocket upgrades

Si tu aplicación gestiona WebSocket upgrades a través de Next.js, existe un vector de SSRF que permite redirigir esas peticiones a servicios internos de la infraestructura. En entornos cloud esto puede exponer metadatos de instancias o servicios internos no expuestos públicamente.

// Patrón vulnerable (simplificado):
// Un atacante puede manipular la cabecera Upgrade para apuntar
// a URLs internas como http://169.254.169.254/latest/meta-data/
// en instancias AWS

// El fix en 15.5.18 valida el destino del upgrade
// contra una allowlist de hosts permitidos

Si no usas WebSockets directamente en Next.js, el riesgo es bajo. Pero si los usas, actualiza antes de hacer cualquier otra cosa.

XSS con CSP nonces

Dos CVEs de severidad moderada afectan a XSS en escenarios específicos:

App Router con CSP nonces: si generates nonces para tu Content Security Policy y los pasas a componentes de App Router, existe un vector donde el nonce puede filtrarse a contenido no confiable.

// Patrón afectado en versiones vulnerables
// app/layout.tsx
export default function RootLayout({ children }: { children: React.ReactNode }) {
  const nonce = generateNonce(); // Este nonce podía filtrarse

  return (
    <html>
      <head>
        <script nonce={nonce} src="/trusted-script.js" />
      </head>
      <body>{children}</body>
    </html>
  );
}

beforeInteractive scripts: scripts con estrategia beforeInteractive que consumen input del usuario sin sanitizar tenían un vector XSS. Si no pasas datos del usuario directamente a estos scripts, no estás afectado.

Cache poisoning en RSC

Dos CVEs adicionales afectan a aplicaciones con capas de caché delante de respuestas RSC. Si usas un CDN o Varnish delante de Next.js y tienes RSC activado, las respuestas de componentes de servidor podían ser envenenadas para servir contenido incorrecto a otros usuarios.

La mitigación inmediata, además del parche, es verificar que tu configuración de caché incluye las cabeceras Vary apropiadas:

Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch

Cómo migrar

# Next.js 15
pnpm add next@15.5.18

# Next.js 16
pnpm add next@16.2.6

# Verificar versión instalada
pnpm list next

Vercel ha confirmado que no hay WAF rules disponibles para mitigar estas vulnerabilidades a nivel de red. El parche es la única solución.

Para proyectos en Next.js 13 o 14, no hay parche disponible. La recomendación oficial es migrar a 15.x o 16.x. Si la migración no es inmediata, considera añadir validación de autorización en cada capa de tu aplicación como mitigación parcial.

Lección arquitectónica

Este release es un recordatorio de que la seguridad en Next.js no puede delegarse completamente al framework. Las capas que deberías tener independientemente:

1. Middleware para redirects rápidos y lógica de sesión básica.
2. Server Components con validación de autorización propia.
3. API Routes con validación de input y autorización en cada endpoint.
4. Base de datos con Row Level Security donde aplique.

El middleware es conveniente, pero no es suficiente por sí solo.