Security Guides
Do Next.js and React Have a Lot of Vulnerabilities? What the CVE Data Actually Shows
We queried NVD to settle it: Next.js has 56 CVEs (28 in 2026), React has 6 — and every recent React CVE is in Server Components. The risk is not front-end code; it is the server your framework quietly became.
Who this is for: teams running Next.js in production, and anyone deciding whether to adopt it. The goal is to replace a vague "frameworks have a lot of CVEs" feeling with the actual numbers, and what is inside them.
The data (NVD, as of 22 August 2026)
| Next.js | React | |
|---|---|---|
| All time | 56 | 6 |
| By year | 2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28 | 2018:1 / 2025:4 / 2026:1 |
| Severity | CRITICAL 2, HIGH 21, MEDIUM 29, LOW 4 | CRITICAL 1, HIGH 3, MEDIUM 2 |
| Worst single item | CVE-2025-29927 — authorization bypass when auth is done in middleware (CVSS 9.1) | CVE-2025-55182 — pre-authentication RCE in React Server Components (CVSS 10.0) |
How to read a CVE count
A high count does not mean dangerous technology. Adoption attracts researchers, and more eyes mechanically produce more reports. A low count may mean "safe" — or it may mean "nobody is looking". The count is an entry point; the decision comes from where the issues land and what kind they are. The figures here come from querying NVD by CPE (vercel:next.js, facebook:react), so anything without an assigned CPE is not counted.
Where they land
Classifying the Next.js CVEs published in 2025–2026 by the feature named in their descriptions:
| Where | What it looks like |
|---|---|
| Caching | Cache confusion and poisoning — one user's response served to another |
| Middleware / routing | Authorization bypass: a route you believe middleware protects gets through |
| Image optimization | SSRF and resource exhaustion via fetching remote URLs |
| Server Actions / RSC | Deserialization of untrusted request bodies; request-driven overload |
| rewrites / redirects | Divergent interpretation of the forwarding target |
The CWE distribution says the same thing: CWE-770 (uncontrolled resource allocation), CWE-918 (SSRF), CWE-502 (deserialization), CWE-400 (resource exhaustion), CWE-444 (inconsistent request interpretation), CWE-288/285 (authorization bypass and failure). That is a list of server and proxy weaknesses.
Browser side — React rendering components
one NVD CVE for React itself, from 2018
Server side 1: React Server Components
all five recent React CVEs live here (worst: pre-auth RCE)
Server side 2: Next.js middleware / cache / image optimizer / rewrites
authorization bypass, SSRF, cache poisoning, resource exhaustion
The shape that keeps coming back: authorization in middleware
A repeated pattern matters more than any single CVE.
March 2025 — CVE-2025-29927 (CVSS 9.1)
A request carrying a particular header could bypass authorization checks performed in middleware. Fixed in 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.May 2026 — CVE-2026-44574 (CVSS 8.1)
Crafted query parameters could alter the dynamic route value the page saw while leaving the visible path unchanged, rendering protected content without passing the middleware check. Fixed in 15.5.16 / 16.2.5.July 2026 — CVE-2026-64642 (CVSS 8.2)
On App Router with Turbopack and a single entry inconfig.i18n.locales, crafted requests could bypass middleware/proxy-based authentication. Fixed in 16.2.11.
The design conclusion this forces
Three high-severity "middleware authorization can be walked past" issues in eighteen months. That is not a run of individual implementation bugs — it is what happens when the decision is made ahead of the route, and the interpretation of that route can shift. So our position is simple: keep middleware as a coarse gate, and make the real authorization decision again right before you touch data (in the page, the route handler, or the data layer). Writing it twice costs less than one bypassed day.
Some of it depends on how you host
Easy to miss: the same CVE can affect you differently depending on whether you self-host. CVE-2026-44578 (CVSS 8.6) allows SSRF through crafted WebSocket upgrade requests on self-hosted deployments using the built-in Node.js server, potentially reaching internal services or cloud metadata endpoints — and the advisory states that Vercel-hosted deployments are not affected.
So "a Next.js vulnerability" is not one thing. Whether it applies depends on how you run it and which features you use.
What to do
Authorize twice (highest value)
Keep the middleware check as a coarse gate, and decide again immediately before touching data. All three bypasses above would have been contained by that. On separating the two concepts, see authentication versus authorization.
Allow-list what your server may fetch
Constrain the remote URLs the image optimizer will load, the destinations of server-side fetch, and rewrite targets. SSRF issues bite hardest where outbound destinations are unrestricted — and check whether your cloud metadata endpoint is reachable from the app.
Put Server Action and RSC endpoints behind authentication
These are paths that deserialize request bodies — and CWE-502 CVEs have actually shipped there. Do not leave them outside auth, apply rate limits, and make sure unexpected payloads cannot take the process down. Treat them exactly as you would /api.
Make updating a system
Next.js ships fixes quickly, which only helps if you follow. The mechanics — judging by the version actually running, and machine-monitoring dependencies — are in running Next.js safely and getting started with osv-scanner. At 28 CVEs a year, manual attention does not scale.
This site's view: the framework question is not about counts
"Should we avoid Next.js because it has many CVEs?" is the wrong question. What the data shows is that Next.js has steadily taken on more server responsibility — it authorizes in middleware, fetches remote images, holds a cache, deserializes requests. That is a reverse proxy and an application server arriving as one dependency. So the thing to evaluate is not the count but which of those server features you actually use, and who defends them. Turn off what you do not need; double up your own controls around what you do. Framed that way, the choice stops being a matter of taste and becomes a question about your operating capacity.
Sources
- NVD (NIST) — figures from querying
cpe:2.3:a:vercel:next.jsandcpe:2.3:a:facebook:reacton 22 August 2026 - CVE-2025-29927 (middleware authorization bypass) / CVE-2026-44574 (dynamic route value shift) / CVE-2026-64642 (App Router + Turbopack auth bypass)
- CVE-2026-44578 (self-hosted WebSocket SSRF; Vercel-hosted not affected)
- CVE-2025-55182 (pre-auth RCE in React Server Components, CVSS 10.0) / CVE-2026-23864 (RSC denial of service)
Read next
FAQ
QDoes Next.js have a lot of vulnerabilities?
By count, yes, and the count is rising. Querying NVD on 22 August 2026 returns 56 CVEs associated with Next.js: 6 published in 2024, 14 in 2025 and 28 in 2026. But do not read a high count as 'dangerous technology' — wider adoption attracts more researchers and mechanically produces more reports. What matters is where the issues land, not how many there are.
QDoes React have few vulnerabilities?
React as a browser-side UI library has very few: six in NVD. And apart from one from 2018, all of the recent ones concern React Server Components (react-server-dom-parcel / turbopack / webpack) — the server half. One of them, CVE-2025-55182, is a pre-authentication remote code execution rated CVSS 10.0.
QSo where is the actual risk?
In server features. Recent Next.js CVEs cluster in middleware, caching, image optimization, Server Actions and rewrites, and the leading CWEs are SSRF (CWE-918), deserialization of untrusted data (CWE-502), uncontrolled resource consumption (CWE-770/400) and authorization failures (CWE-285/288). None of that is about how you write components.
QWhat is the highest-value thing to change?
Four things: (1) stop relying on middleware alone for authorization — bypasses have shipped repeatedly; (2) allow-list outbound destinations for image optimization, server-side fetch and rewrites; (3) keep Server Action and RSC endpoints behind authentication and rate limits; (4) make updating a system rather than an intention. Item 1 matters most, because the same shape of bypass appeared in both 2025 and 2026.