On this page · 12 sections
- What actually shipped, and when
- The version matrix
- The four ways middleware got bypassed
- What is exposed, and what is not
- A 30-minute triage
- The three denial-of-service and cache issues
- Why this keeps happening to middleware
- India-specific considerations
- What to change beyond the patch
- FAQ
- How eCorpIT can help
- References
Summary. In early May 2026, Vercel published 13 security advisories against Next.js in one coordinated release: 7 rated High, 4 Moderate, 2 Low. Four of them let an attacker reach content that middleware was supposed to protect. The worst, GHSA-c4j6-fc7j-m34r, is a server-side request forgery scored 8.6 on CVSS v3, and it only affects self-hosted deployments running the built-in Node.js server. Every advisory in that batch names 15.5.16 and 16.2.5 as the patched versions. Then on 7 May 2026, a fourteenth advisory landed: GHSA-26hh-7cqf-hhc6 disclosed that the fix for the segment-prefetch bypass never applied to middleware.ts under Turbopack. Its patched versions are 15.5.18 and 16.2.6. If your team read the first batch, upgraded to 16.2.5, and closed the ticket, the authentication bypass is still open in your build. For Indian teams the stake is not only uptime: the Digital Personal Data Protection Act 2023 sets a maximum penalty of ₹250 crore for failure to take reasonable security safeguards, and an authorization bypass that exposes personal data is exactly that failure.
This article maps each advisory to the versions it affects, separates the issues that matter for self-hosted apps from the ones that do not, and gives you a triage you can run against a production repository in about half an hour.
What actually shipped, and when
The batch was published by Tim Neutkens on the vercel/next.js repository. The eight advisories this article examines in detail carry publication dates of 6 May 2026, except the Turbopack follow-up, which is dated 7 May 2026. All 13 are listed in the release notes for 15.5.18 and 16.2.6, which Vercel describes as containing "security fixes and backported bug fixes".
The advisories fall into five groups:
- Authorization bypass (4 advisories). Requests reach a protected page without middleware running against them.
- Denial of service (3 advisories). CPU exhaustion, connection exhaustion, and an image-optimization endpoint issue.
- Cache poisoning (3 advisories). Responses stored under keys an attacker can influence.
- Cross-site scripting (2 advisories). Nonce handling and
beforeInteractivescripts.
- Server-side request forgery (1 advisory). The highest-scored issue in the batch, and self-hosted only.
The authorization group is the one that changes your risk posture, because it converts a routing quirk into unauthenticated access to data. The rest are real, but they degrade a service rather than hand over its contents.
The version matrix
Every row below comes from the advisory page itself. Note the lower bounds carefully: they are not uniform, and a team running Next.js 13 is inside the affected range for four of these.
| Advisory | Affected versions | Patched in |
|---|---|---|
| GHSA-267c-6grr-h53f (segment-prefetch bypass, High, 7.5) | >= 15.2.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-26hh-7cqf-hhc6 (same bug, Turbopack, High, 7.5) | >= 15.2.0 < 15.5.18; >= 16.0.0 < 16.2.6 | 15.5.18, 16.2.6 |
| GHSA-492v-c6pp-mqqv (route param injection, High, 8.1) | >= 15.4.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-36qx-fr4f-26g5 (Pages Router i18n data routes, High, 7.5) | >= 12.2.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-c4j6-fc7j-m34r (WebSocket SSRF, High, 8.6) | >= 13.4.13 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-8h8q-6873-q5fj (Server Components DoS, High, 7.5) | >= 13.0.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-mg66-mrh9-m8jx (Cache Components DoS, High, 7.5) | >= 15.0.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
| GHSA-ffhc-5mcf-pf4q (CSP nonce XSS, Moderate, 4.7) | >= 13.4.0 < 15.5.16; >= 16.0.0 < 16.2.5 | 15.5.16, 16.2.5 |
The practical reading of that table is one line: upgrade to 15.5.18 or 16.2.6, not 15.5.16 or 16.2.5. The intermediate versions leave GHSA-26hh-7cqf-hhc6 open for anyone whose middleware.ts is processed by Turbopack.
The four ways middleware got bypassed
Segment-prefetch routes
GHSA-267c-6grr-h53f, published 6 May 2026 and rated High at CVSS 7.5, is the cleanest example of the class. App Router pages are reachable over more than one transport. Besides the normal HTML URL, there are .rsc variants and segment-prefetch URLs that the client router uses to fetch parts of a page. Middleware matchers were generated against the page URL only.
The advisory puts it plainly: "specially crafted .rsc and segment-prefetch URLs can resolve to the same page without being matched by the intended middleware rule, which can allow protected content to be reached without the expected authorization check." The weakness is classified CWE-288, authentication bypass using an alternate path or channel, which is exactly what it is. The fix generates middleware matchers that include App Router transport variants.
The follow-up advisory the next day, GHSA-26hh-7cqf-hhc6, is two sentences long and matters more than its length suggests: "It was found that the fix addressing CVE-2026-44575 did not apply to middleware.ts with Turbopack." Same CVSS 7.5, same CWE-288, higher patch floor.
Dynamic route parameter injection
GHSA-492v-c6pp-mqqv is the highest-scored bypass at CVSS 8.1, and it is the sneakiest. Query parameters can change the dynamic route value the page sees while the visible path stays the same. Middleware matches on the path it can see. The page renders against a different route parameter. Protected content comes back.
Vercel's fix stops honouring externally supplied parameter encodings and only trusts internal route-parameter normalization. The advisory's workaround is the same advice that runs through this whole batch: "If you cannot upgrade immediately, enforce authorization in route or page logic instead of relying solely on middleware path matching."
Note the lower bound, 15.4.0. This one is younger than the others.
Pages Router with i18n
GHSA-36qx-fr4f-26g5 has the widest affected range in the batch, starting at 12.2.0. If you run the Pages Router with i18n configured and put authorization in middleware, a request to /_next/data/<buildId>/<page>.json without a locale prefix does not run middleware at all. The server-side rendered JSON for a protected page comes back to an unauthenticated caller.
That is a four-year version range on a router plenty of production applications still use. Teams that migrated to the App Router years ago are clear. Teams that kept a Pages Router admin surface around because it works are not.
The pattern underneath
All four bypasses are the same mistake in different clothing: middleware runs against one representation of a route, while the framework serves the page through another. Vercel's own postmortem on the 2025 incident said the quiet part out loud. In that document, Ty Sbano, the author of Vercel's postmortem on the Next.js middleware bypass, wrote: "We do not recommend Middleware to be the sole method of protecting routes in your application."
That was published on 25 March 2025, after CVE-2025-29927, a critical bypass triggered by an x-middleware-subrequest header that security researchers Rachid Allam and Yassir Alam disclosed on 27 February 2025. Fourteen months later, four more advisories describe four more alternate paths. The guidance did not change because the architecture did not change: middleware runs before caching and routing, in a separate process, and any transport the router adds is a new surface the matcher has to know about.
The engineering judgement worth carrying out of this: middleware is a good place to redirect and a bad place to decide.
What is exposed, and what is not
Not every advisory applies to every deployment. This is where teams waste the most time, so it is worth being specific.
| Deployment | Exposed to WebSocket SSRF (GHSA-c4j6-fc7j-m34r) | Exposed to the four middleware bypasses |
|---|---|---|
| Vercel-hosted | No, the advisory states Vercel-hosted deployments are not affected | Yes, if running an affected version |
Self-hosted next start |
Yes, this is the primary affected configuration | Yes |
Self-hosted output: 'standalone' |
Yes, it uses the built-in Node.js server | Yes |
| Static export | No, no server runtime | No, middleware does not run |
| Behind a proxy blocking upgrades | Reduced, if WebSocket upgrades are blocked upstream | Yes, the proxy does not help here |
The SSRF is worth reading twice if you self-host. GHSA-c4j6-fc7j-m34r scores 8.6 partly because its CVSS vector carries a changed scope (S:C). An attacker can make the server proxy requests to arbitrary internal or external destinations, which the advisory notes can expose internal services or cloud metadata endpoints. On AWS that means the instance metadata service; a successful hit there is a credential disclosure, not a nuisance. The fix applies the same safety checks to WebSocket upgrades that already applied to normal HTTP requests.
A 30-minute triage
Run this in order. It is written for a single repository; loop it if you run a monorepo.
1. Find the version you actually ship, not the one in `package.json`.
npm ls next --depth=0
cat package-lock.json | grep -m1 '"node_modules/next"' -A3
A caret range in package.json tells you nothing. The lockfile is the build.
2. Ask npm whether your resolved version is inside a published advisory range.
npm audit --omit=dev
npm view next versions --json | tail -20
3. Decide your target. If you are on the 15.x line, the target is 15.5.18. On 16.x, it is 16.2.6. Do not stop at 15.5.16 or 16.2.5.
npm install next@15.5.18 # 15.x line
npm install next@16.2.6 # 16.x line
4. Confirm whether Turbopack is in play, because that decides whether GHSA-26hh-7cqf-hhc6 applies to you.
grep -rn "turbopack" next.config.* package.json
grep -rn "next dev\|next build" package.json
5. Inventory what middleware is currently deciding. This is the step teams skip, and it is the one that survives the next advisory.
cat middleware.ts
grep -rn "matcher" middleware.ts next.config.*
For every route that middleware protects, ask whether the page or route handler behind it would also reject an unauthenticated request on its own. If the answer is no, the route is one alternate transport away from being public, patched or not.
6. If you cannot upgrade this week, apply the advisory workarounds at the edge.
| Advisory | Workaround from the advisory | Where to apply it |
|---|---|---|
| GHSA-267c-6grr-h53f | Enforce authorization in the underlying route or page logic | Application code |
| GHSA-492v-c6pp-mqqv | Enforce authorization in route or page logic, not middleware path matching | Application code |
| GHSA-36qx-fr4f-26g5 | Enforce authorization in the page's server-side data path | getServerSideProps |
| GHSA-c4j6-fc7j-m34r | Block WebSocket upgrades at the reverse proxy if not required; restrict origin egress | Proxy, load balancer, security group |
| GHSA-mg66-mrh9-m8jx | Block requests containing the Next-Resume header at the edge |
CDN or WAF rule |
| GHSA-ffhc-5mcf-pf4q | Strip inbound Content-Security-Policy request headers from untrusted traffic |
Proxy or CDN |
Two of those, the Next-Resume strip and the inbound CSP header strip, are one-line rules in most CDNs and buy you real time. Neither is a substitute for the upgrade.
The three denial-of-service and cache issues
GHSA-8h8q-6873-q5fj is not really a Next.js bug. It is CVE-2026-23870, an upstream React Server Components issue republished against Next.js because the framework ships the affected packages. A crafted HTTP request to any App Router Server Function endpoint triggers excessive CPU on deserialization. It carries CWE-770, allocation of resources without limits or throttling, and the affected range starts at 13.0.0, the widest of the App Router issues. There is no workaround section on that advisory, which is the honest answer: you upgrade.
GHSA-mg66-mrh9-m8jx affects applications using Partial Prerendering through Cache Components. A crafted POST to a server action causes a request-body handling deadlock, holding connections open and consuming file descriptors until real users are refused. The fix treats the Next-Resume header as internal-only and strips it from untrusted requests, which is also the shape of the edge workaround. If you adopted Cache Components during the Next.js 16 migration, this one is yours; our Next.js 16 migration notes on async request APIs and Cache Components cover where that feature usually gets turned on.
GHSA-ffhc-5mcf-pf4q is the Moderate XSS, scored 4.7. App Router applications that derive CSP nonces from request headers, deployed behind a shared cache, could see malformed nonce values reflected into rendered HTML. An attacker poisons a cached response and the script executes for later visitors. The attack complexity is High and it needs user interaction, which is why the score is where it is. The combination of nonce-from-header plus shared cache is uncommon; if you have it, you know.
Why this keeps happening to middleware
Three observations from the advisory text itself, none of which require speculation.
First, only two of the seven advisories reviewed here carry a CWE classification at all. Four state "No CWEs". Two carry no CVE: GHSA-c4j6-fc7j-m34r and GHSA-mg66-mrh9-m8jx both read "No known CVE". If your vulnerability management process keys on CVE identifiers pulled from an NVD feed, two High-severity issues in this batch never reach your dashboard. That is a tooling gap worth fixing this quarter, and it is the same class of gap we wrote about in our MCP server hardening notes on CVEs and configs.
Second, the patched versions are not uniform across the batch, and a rollup release is not the same thing as the advisory's stated patch floor. Reading the release notes for 16.2.6 gives you the list; reading the individual advisories gives you the floors. You need both.
Third, an incomplete fix shipped one day after the original. That is not a criticism of the Next.js team, who found and disclosed it themselves. It is a reason to treat "we patched it" as a claim to verify rather than a state to assume. The 2025 postmortem committed Vercel to a published support policy and a partner mailing list, and the May 2026 batch shows the disclosure process working. It also shows that a framework whose routing layer keeps gaining transports will keep gaining matcher gaps.
India-specific considerations
For teams building in India, the compliance exposure is concrete. Under the Digital Personal Data Protection Act 2023, the maximum penalty for failure to take reasonable security safeguards to prevent a personal data breach is ₹250 crore. The DPDP Rules were notified on 14 November 2025, and reporting on the implementation timeline places the transition from guidance to active supervision through late 2026, with the harder enforcement posture expected from May 2027.
An unauthenticated caller retrieving a protected page's server-rendered JSON is a personal data breach in the ordinary meaning of the Act, whichever router served it. Two practical consequences:
- Your patch evidence has to be dated. "We are on the latest version" is not a record. A lockfile diff with a commit date is. Teams working through this for the first time may find our DPDP Act engineering playbook for Indian startups useful for what else needs to be written down.
- Dependency provenance belongs in the same review. A framework upgrade is only as trustworthy as the registry path it came through, which is the subject of our notes on npm OIDC trusted publishing and cache poisoning and on npm 12 install-script approval in CI.
Indian product teams shipping to EU or US customers carry the local obligation and the customer's contractual one at the same time. The version matrix above is the cheap part of that. The expensive part is proving, six months from now, which build was running on which date.
What to change beyond the patch
The upgrade closes eight known holes. It does not change the design that produced them.
Move the authorization decision to the resource. A route handler, a server action, and a getServerSideProps all have access to the session; make each of them reject an unauthorized caller on its own, then let middleware do what it is good at, which is redirecting a browser to a login page so the user sees something sensible. When the next transport variant appears, and it will, the decision layer is already behind it.
Two smaller changes are worth making in the same pull request. Pin the framework version in the lockfile and gate upgrades through CI rather than caret ranges, so "which version is in production" has one answer. And add an advisory watch that keys on the GHSA identifier for npm:next rather than on CVE feeds, because as this batch shows, two High-severity issues here have no CVE at all.
FAQ
How eCorpIT can help
eCorpIT runs framework upgrade and application security reviews for teams shipping Next.js in production, including the awkward cases: a Pages Router admin surface nobody wants to touch, a self-hosted deployment behind a proxy that was never audited for upgrade handling, or a middleware file that has quietly become the only thing standing between the internet and your customer data. Our senior engineering teams work through the version matrix, move authorization decisions to the resources that own them, and leave you with dated evidence of what changed. If you want a second pair of eyes on a Next.js codebase before the next advisory lands, get in touch.
References
- GHSA-26hh-7cqf-hhc6: Middleware / Proxy bypass via segment-prefetch routes, Incomplete Fix Follow-Up
Last updated: 20 July 2026.
