Next.js just patched 13 security advisories. Self-hosted teams have the most work.

On May 7, Vercel shipped a coordinated security release covering 13 advisories across Next.js and React Server Components. The bundle includes high-severity issues for denial-of-service, server-side request forgery, cache poisoning, and several middleware-bypass flaws affecting App Router. If your team runs self-hosted Next.js on Node, you have the most ground to cover.

The fixes land in 15.5.18 and 16.2.6. React users on react-server-dom should jump to 19.0.6, 19.1.7, or 19.2.6 depending on the line they track. Versions 13.x and 14.x are not getting patches at all, so anyone still on those needs to plan an upgrade rather than wait for a cherry-pick.

What's actually in the bundle

The headline CVE most outlets are quoting is CVE-2026-23870, a high-severity DoS in the React Flight protocol deserialization. A specially crafted HTTP request to any App Router server function can pin a CPU core. Bad, but a known shape of bug, the kind a WAF or rate limiter can blunt.

The class worth reading more carefully is the middleware-bypass set. The advisories describe variants where .rsc and segment-prefetch URLs resolve to the same page as a normal request, but skip the middleware matcher rules. Translation: if your middleware.ts is the only thing between an unauthenticated request and a protected page, an attacker can ask for the same content via a different transport and walk in. There's a related Pages Router variant tied to i18n locale handling, plus a follow-up advisory for the Turbopack code path because the original fix didn't cover it.

The remaining advisories cover SSRF via WebSocket upgrade requests on self-hosted Node (Vercel-hosted apps are not affected), DoS in the Image Optimization API, XSS, and cache poisoning of RSC responses.

Why "middleware as auth" keeps biting teams

In our pentesting engagements, this is one of the patterns we test for first when we see Next.js in scope. The shape repeats: a single middleware.ts checks the session cookie, redirects to login if missing, and the team treats every route below it as protected. It feels clean. It reads well in PRs. And it usually has a transport-variant gap that someone will eventually find.

Middleware in Next.js is a routing concern. It runs early, has limited APIs, and has historically had quirks around how matchers apply to internal request shapes (RSC payloads, prefetches, dynamic segments, locale-prefixed paths). Each of those quirks has surfaced as a CVE class at some point. This week's batch is the latest reminder.

When we build cloud-native apps with App Router, we treat middleware as a fast-path filter and put real authorization checks in the route handler, the server action, or the server component itself. The cookie value becomes the input, not the verdict. That extra check costs almost nothing and removes a whole family of bypass risk.

What to do this week

A short list:

1. Upgrade next to 15.5.18 or 16.2.6. If you publish on Pages Router with i18n through the OpenNext adapter, also bump it to 5.15.11.
2. If you depend on react-server-dom-* directly, match the 19.x patch line you're on (19.0.6, 19.1.7, or 19.2.6).
3. Plan the move off 13.x or 14.x. Those branches will not get these fixes.
4. Audit your middleware.ts. If a route is protected only by middleware, add a server-side auth check inside the route handler, server action, or layout. Do not skip this just because you upgraded.
5. For self-hosted Node deployments, look at edge or proxy logs for unusual .rsc requests, WebSocket upgrades to unexpected origins, and Image Optimization traffic spikes. The SSRF and DoS issues will show up in self-hosted environments first.

A note on self-hosted vs platform

Several of these issues are explicitly scoped to self-hosted Node. Vercel says hosted projects had WAF rules in front of the patch. Netlify says some of the advisories don't apply to their serverless model at all. That gap is worth thinking about when you decide where to run Next.js.

From our cloud-native development work, we've seen plenty of teams pick self-hosting for cost or compliance reasons (Swiss enterprise clients especially), and that's a fine call. But you carry more of the responsibility for runtime security yourself, and patch cadence becomes part of the operating budget, not a quarterly afterthought.

If keeping a self-hosted Next.js stack hardened and patched on a real schedule sounds familiar, let's talk. We do this work across web and mobile builds and security reviews, and the answer is rarely "more middleware".