Guías de seguridad
¿Next.js y React tienen muchas vulnerabilidades? Lo que muestran realmente los datos de CVE
Lo comprobamos en el NVD: Next.js tiene 56 CVE (28 en 2026) y React tiene 6, y todos los CVE recientes de React están en los Server Components. El riesgo no está en el código del front-end, sino en las funciones de servidor que ahora aporta el framework.
Para quién es: equipos que usan Next.js en producción y cualquiera que esté decidiendo si adoptarlo. El objetivo es sustituir la vaga sensación de que «los frameworks tienen muchos CVE» por las cifras reales y lo que hay dentro de ellas.
Los datos (NVD, a 22 de agosto de 2026)
| Next.js | React | |
|---|---|---|
| En total | 56 | 6 |
| Por año | 2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28 | 2018:1 / 2025:4 / 2026:1 |
| Gravedad | CRITICAL 2, HIGH 21, MEDIUM 29, LOW 4 | CRITICAL 1, HIGH 3, MEDIUM 2 |
| El peor caso | CVE-2025-29927: elusión de la autorización cuando se hace en el middleware (CVSS 9.1) | CVE-2025-55182: RCE previa a la autenticación en React Server Components (CVSS 10.0) |
Cómo leer un recuento de CVE
Una cifra alta no significa tecnología peligrosa. Una adopción más amplia trae más investigación, y más investigación produce más informes. Una cifra baja puede significar «seguro» o puede significar «nadie está mirando». El recuento es solo un punto de partida; la decisión sale de dónde aparecen los problemas y de qué tipo son. Las cifras de aquí proceden de consultar el NVD por CPE (vercel:next.js, facebook:react), así que no se cuenta nada que no tenga un CPE asignado.
Dónde aparecen
Clasificando los CVE de Next.js publicados en 2025–2026 según la función que nombran sus descripciones:
| Dónde | Cómo se manifiesta |
|---|---|
| Caché | Confusión y envenenamiento de la caché: la respuesta de un usuario se sirve a otro |
| Middleware / enrutamiento | Elusión de la autorización: una ruta que crees protegida por el middleware deja pasar la petición |
| Optimización de imágenes | SSRF y agotamiento de recursos al descargar URL remotas |
| Server Actions / RSC | Deserialización de cuerpos de petición no fiables; sobrecarga provocada por peticiones |
| rewrites / redirects | Interpretaciones distintas del destino del reenvío |
La distribución por CWE dice lo mismo: CWE-770 (asignación de recursos sin control), CWE-918 (SSRF), CWE-502 (deserialización), CWE-400 (agotamiento de recursos), CWE-444 (interpretación incoherente de peticiones), CWE-288/285 (elusión y fallo de la autorización). Es una lista de debilidades de servidores y proxies.
Lado del navegador: React renderizando componentes
un CVE del NVD para el propio React, de 2018
Lado del servidor 1: React Server Components
aquí están los cinco CVE recientes de React (el peor: RCE previa a la autenticación)
Lado del servidor 2: middleware / caché / optimizador de imágenes / rewrites de Next.js
elusión de la autorización, SSRF, envenenamiento de la caché, agotamiento de recursos
El problema que vuelve una y otra vez: la autorización en el middleware
Un patrón que se repite importa más que cualquier CVE aislado.
Marzo de 2025: CVE-2025-29927 (CVSS 9.1)
Una petición con una cabecera concreta podía eludir las comprobaciones de autorización hechas en el middleware. Corregido en 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.Mayo de 2026: CVE-2026-44574 (CVSS 8.1)
Unos parámetros de consulta manipulados podían cambiar el valor de la ruta dinámica que veía la página sin cambiar la ruta visible, mostrando contenido protegido sin pasar la comprobación del middleware. Corregido en 15.5.16 / 16.2.5.Julio de 2026: CVE-2026-64642 (CVSS 8.2)
Con App Router y Turbopack, y una sola entrada enconfig.i18n.locales, unas peticiones manipuladas podían eludir la autenticación basada en middleware o proxy. Corregido en 16.2.11.
La conclusión de diseño que esto impone
Tres elusiones de alta gravedad de la autorización en el middleware en dieciocho meses. No es una racha de fallos de implementación aislados; es lo que ocurre cuando la decisión se toma antes de la ruta y la interpretación de esa ruta puede cambiar. Nuestra postura: deja el middleware como una primera comprobación general y vuelve a tomar la decisión real de autorización justo antes de tocar los datos (en la página, en el route handler o en la capa de datos). Escribir la comprobación dos veces cuesta menos que el daño de una sola elusión.
Parte depende de cómo lo alojes
Fácil de pasar por alto: el mismo CVE puede afectarte de forma distinta según si lo alojas tú mismo. CVE-2026-44578 (CVSS 8.6) permite SSRF mediante peticiones de actualización a WebSocket manipuladas en despliegues autoalojados que usan el servidor de Node.js integrado, con posibilidad de llegar a servicios internos o a los puntos de metadatos de la nube; el aviso indica que los despliegues alojados en Vercel no están afectados.
Así que «una vulnerabilidad de Next.js» no es una sola cosa. Que te afecte o no depende de cómo lo ejecutas y de qué funciones usas.
Qué hacer
Autoriza dos veces (lo más rentable)
Mantén la comprobación del middleware como primera comprobación general y vuelve a decidir justo antes de tocar los datos. Eso habría contenido las tres elusiones de arriba. Para separar los dos conceptos, consulta autenticación frente a autorización.
Usa una lista de permitidos para lo que tu servidor puede descargar
Limita las URL remotas que cargará el optimizador de imágenes, los destinos del fetch en el servidor y los destinos de los rewrites. Los problemas de SSRF hacen más daño donde los destinos salientes no tienen restricciones. Comprueba también si el punto de metadatos de tu nube es accesible desde la aplicación.
Pon los puntos de acceso de las Server Actions y de RSC detrás de autenticación
Son rutas que deserializan cuerpos de petición, y ahí se han publicado CVE de CWE-502. No las dejes fuera de la autenticación, aplica límites de frecuencia y asegúrate de que unos datos inesperados no puedan tumbar el proceso. Trátalas exactamente igual que /api.
Convierte la actualización en un mecanismo
Next.js publica correcciones rápido, y eso solo ayuda si actualizas. Los detalles (juzgar por la versión que realmente se ejecuta y monitorizar las dependencias de forma automática) están en ejecutar Next.js de forma segura y primeros pasos con osv-scanner. Con 28 CVE al año, la atención manual no da abasto.
La visión de este sitio: la pregunta sobre el framework no va de cifras
«¿Debemos evitar Next.js porque tiene muchos CVE?» es la pregunta equivocada. Lo que muestran los datos es que Next.js ha ido asumiendo cada vez más responsabilidades de servidor: autoriza en el middleware, descarga imágenes remotas, mantiene una caché, deserializa peticiones. En la práctica, una sola dependencia te da a la vez un proxy inverso y un servidor de aplicaciones. Así que lo que hay que evaluar no es la cifra, sino cuáles de esas funciones de servidor usas de verdad y quién las defiende. Desactiva lo que no necesites; refuerza tus propios controles alrededor de lo que sí usas. Planteado así, la elección deja de ser una cuestión de gustos y pasa a ser una pregunta sobre tu capacidad operativa.
Fuentes
- NVD (NIST): cifras obtenidas al consultar
cpe:2.3:a:vercel:next.jsycpe:2.3:a:facebook:reactel 22 de agosto de 2026 - CVE-2025-29927 (elusión de la autorización en el middleware) / CVE-2026-44574 (cambio del valor de la ruta dinámica) / CVE-2026-64642 (elusión de la autenticación con App Router + Turbopack)
- CVE-2026-44578 (SSRF mediante WebSocket en despliegues autoalojados; los alojados en Vercel no están afectados)
- CVE-2025-55182 (RCE previa a la autenticación en React Server Components, CVSS 10.0) / CVE-2026-23864 (denegación de servicio en RSC)
Leer a continuación
- Implementación: contaminación de prototipos en Node.js (el área que el runtime declaró fuera de su alcance)
- Operaciones: ejecutar Next.js de forma segura sin quedarse atrás con los CVE / monitorizar las dependencias de forma automática con osv-scanner
- Diseño: autenticación frente a autorización / la suplantación de X-Forwarded-For y los proxies de confianza
- Términos: qué es el SSRF / qué es un CVE
FAQ
Q¿Next.js tiene muchas vulnerabilidades?
En número, sí, y la cifra va en aumento. Una consulta al NVD el 22 de agosto de 2026 devuelve 56 CVE asociados a Next.js: 6 publicados en 2024, 14 en 2025 y 28 en 2026. Pero no leas una cifra alta como «tecnología peligrosa»: una adopción más amplia trae más investigación y, con ella, más informes. Lo que importa es dónde aparecen los problemas, no cuántos hay.
Q¿React tiene pocas vulnerabilidades?
React como biblioteca de interfaz en el navegador tiene muy pocas: seis en el NVD. Y, salvo una de 2018, todas las recientes afectan a React Server Components (react-server-dom-parcel / turbopack / webpack), que se ejecutan en el servidor. Una de ellas, CVE-2025-55182, es una ejecución remota de código previa a la autenticación con una puntuación CVSS de 10.0.
QEntonces, ¿dónde está el riesgo real?
En las funciones de servidor. Los CVE recientes de Next.js se concentran en el middleware, la caché, la optimización de imágenes, las Server Actions y los rewrites, y los CWE principales son SSRF (CWE-918), deserialización de datos no fiables (CWE-502), consumo de recursos sin control (CWE-770/400) y fallos de autorización (CWE-285/288). Nada de eso tiene que ver con cómo escribes los componentes.
Q¿Qué es lo más rentable de cambiar?
Cuatro cosas: (1) deja de confiar solo en el middleware para la autorización, porque se han publicado elusiones una y otra vez; (2) usa una lista de permitidos para los destinos salientes de la optimización de imágenes, del fetch en el servidor y de los rewrites; (3) mantén los puntos de acceso de las Server Actions y de RSC detrás de autenticación y límites de frecuencia; (4) convierte la actualización en un mecanismo y no en una intención. El punto 1 es el más importante, porque la misma forma de elusión apareció tanto en 2025 como en 2026.