Next.js 16.2.6 and 15.5.18 patch Middleware bypass and RSC DoS across 13 advisories

TL;DR

Impact Parts of Next.js 13.x through 16.x. The actual exposure depends on whether your app uses App Router, Middleware / Proxy, React Server Components, or a self-hosted Node.js server

Action Upgrade to 16.2.6 (v16) or 15.5.18 (v15). Both release pages list the same 13 advisories

Interim If you cannot upgrade immediately: do not rely on Middleware alone for authorization, block WebSocket upgrade requests that should not reach origin, and review shared cache behavior for RSC responses

Next.js 16.2.6 and 15.5.18 shipped on May 7, 2026 (UTC).
The release pages list 7 High, 4 Moderate, and 2 Low security advisories.

Upgrading Next.js is all you need to do.
But looking at the names on the list — RSC, Middleware / Proxy, App Router, Pages Router, Image Optimization, WebSocket upgrade, Cache Components — the surface is wide.
None of these are as dramatic as last year’s React2Shell RCE, but the more server-side Next.js features you use in production, the more advisories are relevant to your environment.

Multiple Middleware bypasses in App Router

The worst pattern among the Highs is that several advisories target Middleware / Proxy bypass from different angles.
GHSA-267c-6grr-h53f describes how apps relying on Middleware or Proxy-based authorization in App Router can be reached through .rsc segment-prefetch URLs, bypassing the protection layer.
CVSS (a 0–10 severity score for vulnerabilities) is 7.5. Affected versions: 15.2.0 to below 15.5.16, 16.0.0 to below 16.2.5.

This hits any design built on “Middleware blocks unauthenticated users, so we’re fine.”
The advisory’s own workaround says the same thing: if you cannot upgrade immediately, enforce authorization at the actual route or page level rather than relying on Middleware alone.

The same release also includes a follow-up fix for an incomplete segment-prefetch route patch, dynamic route parameter injection, Middleware / Proxy bypass when Pages Router uses i18n, and redirect cache poisoning.
The entry points differ, but from an operations perspective they all point in the same direction.
Treat Middleware as part of the boundary, not the boundary itself.

RSC-originated DoS and cache poisoning

GHSA-8h8q-6873-q5fj is a DoS (Denial of Service) tied to React Server Components.
Tracked upstream as CVE-2026-23870, a crafted HTTP request sent to an App Router Server Function endpoint causes excessive CPU consumption during deserialization.
CVSS is 7.5. Affected versions: 13.0.0 to below 15.5.16, 16.0.0 to below 16.2.5.

As with the React2Shell incident, RSC vulnerabilities are hard to assess by asking “did I write any dangerous APIs?”
If your app uses App Router and exposes RSC or Server Function endpoints on the server side, checking the dependency version is faster.

The Moderate-severity GHSA-wfc6-r584-vfw7 is cache poisoning on RSC responses.
Under conditions where a shared cache does not correctly separate response variants, a URL expecting HTML may serve an RSC payload instead.
If you cannot upgrade right away, the workarounds are: ensure CDN or reverse proxy includes RSC-related headers in the cache key, respect Vary, and disable shared caching for affected responses.

I wrote about moving static-HTML-heavy sites to Astro in an earlier post on migrating from Next.js.
The same logic applies here: an SSG-only site and a site running RSC, Middleware, Image Optimization, and WebSocket upgrade in production have very different attack surfaces even though both use Next.js.

WebSocket upgrade SSRF on self-hosted Node.js server

GHSA-c4j6-fc7j-m34r is an SSRF (Server-Side Request Forgery — tricking a server into making requests to unintended destinations) in the self-hosted built-in Node.js server.
A crafted WebSocket upgrade request can be proxied to internal services or cloud metadata endpoints.
CVSS is 8.6 — the highest in this batch.

The advisory explicitly states that Vercel-hosted deployments are not affected.
If you only deploy on Vercel, this SSRF does not apply.
On the other hand, if you run the Next.js Node.js server directly in Docker or a VM, or pass upgrade requests through a reverse proxy to the origin, upgrade promptly.

Interim mitigations if you cannot upgrade: do not expose the origin server directly to the internet, block WebSocket upgrades at the reverse proxy or load balancer if they are not needed, and restrict egress from the origin to metadata services and internal networks.
This is less Next.js-specific and more of a baseline for any self-hosted SSR application.

Upgrading to 16.2.6 and 15.5.18

The release notes list RSC DoS, App Router / Pages Router Middleware / Proxy bypass, connection exhaustion with Cache Components, and WebSocket upgrade SSRF as High.
Moderate includes XSS (cross-site scripting) when using CSP nonce (Content Security Policy one-time token), XSS via beforeInteractive scripts, DoS against the Image Optimization API, and RSC response cache poisoning.
Low covers RSC cache-busting collision and Middleware / Proxy redirect cache poisoning.

The patched versions on the GitHub advisory pages mostly say 15.5.16 / 16.2.5.
However, the actual release tags from May 7, 2026 are 15.5.18 / 16.2.6, so upgrading to the latest release tag is the natural choice.

Upgrading is straightforward.

pnpm up next@16.2.6

If staying on the 15.x line:

pnpm up next@15.5.18

For npm or yarn, specify the same version.
After updating the lockfile, run next build and test any routes involving authorization, Middleware / Proxy, image optimization, and WebSocket upgrade.
If Dependabot or Renovate already opened a PR, treat this one as a security release rather than routine minor tracking.