Introduction
A middleware authorization bypass in Next.js allows unauthenticated attackers to silently retrieve protected server side rendered page data from any application using the Pages Router with internationalization enabled. For organizations that rely on Next.js middleware as their authorization boundary, this vulnerability means that confidential page content, including user dashboards, admin panels, and internal data views, may already be accessible to anyone who knows the right URL pattern.
Technical Information
Root Cause: The Matcher Logic Gap
The vulnerability originates in how Next.js internally resolves data fetching requests when the Pages Router operates with i18n configuration. During normal client side navigation, Next.js fetches page data via internal JSON endpoints following the pattern /_next/data/<buildId>/<locale>/<page>.json. The framework's middleware matcher is responsible for translating these internal URL paths back to their logical page paths so that middleware route patterns can evaluate them and enforce authorization.
The flaw is specific to i18n configurations. When i18n is enabled, the matcher expects data route requests to include a locale prefix (e.g., /en/, /fr/). A request like /_next/data/<buildId>/en/dashboard.json is correctly resolved to the logical page /dashboard, middleware fires, and authorization checks run as intended.
However, requests that omit the locale prefix entirely were not recognized by the matcher. A request to /_next/data/<buildId>/dashboard.json (without the /en/ segment) fell through the matching logic entirely. The matcher did not identify this unprefixed data route as belonging to a page that should trigger middleware execution. The result: the server happily returned the full SSR JSON payload with no middleware, and therefore no authorization, ever running.
This is classified under CWE-863 (Incorrect Authorization), which is accurate: the authorization mechanism exists but fails to apply to a reachable code path.
Attack Flow
The exploitation path is direct and requires no authentication, no user interaction, and no specialized tooling:
-
The attacker identifies a target Next.js application using the Pages Router with i18n enabled. This can often be inferred from observing locale prefixed URLs in the application's navigation (e.g.,
/en/dashboard,/fr/settings). -
The attacker determines the application's current build ID. This value is typically exposed in page source, static assets, or prior
/_next/data/responses observed during normal browsing. -
The attacker constructs a request to the target page's data endpoint, deliberately omitting the locale prefix:
GET /_next/data/<buildId>/dashboard.jsonInstead of the expected locale prefixed form:
GET /_next/data/<buildId>/en/dashboard.json -
Because the middleware matcher does not recognize the locale-less data route, middleware never executes. The server processes the request as a valid data fetch and returns the complete SSR JSON response for the
/dashboardpage. -
The attacker receives the same JSON payload that an authenticated, authorized user would receive during a client side page transition, containing all props returned by
getServerSidePropsor equivalent server side data fetching functions.
Exploitability Profile
The CVSS v3.1 metrics paint a clear picture of the risk:
| Metric | Value | Context |
|---|---|---|
| Attack Vector | Network | Exploitable remotely over the internet |
| Attack Complexity | Low | No specialized conditions required |
| Privileges Required | None | Unauthenticated attackers can exploit this |
| User Interaction | None | Fully automatable |
| Confidentiality Impact | High | Direct access to protected SSR JSON data |
| Integrity Impact | None | No data modification possible |
| Availability Impact | None | Application remains operational |
The combination of network accessibility, zero authentication requirements, and high confidentiality impact at a CVSS score of 7.5 makes this vulnerability particularly suitable for automated, large scale data harvesting against internet facing applications.
Patch Information
Vercel addressed CVE-2026-44573 as part of a coordinated Next.js security release on May 6 through 7, 2026, which shipped fixes for 13 advisories simultaneously. The fix for this specific vulnerability was first introduced in Next.js v15.5.16 (for the 15.x line) and Next.js v16.2.5 (for the 16.x line). A subsequent release, v16.2.6, also carries the fix along with a follow up correction for a separate advisory.
What the Fix Changes
The core correction updates the middleware matcher logic to perform the same route matching on locale-less /_next/data/ requests as it would on a standard non-i18n data route. In practical terms, the framework now normalizes the incoming data route URL consistently, whether or not a locale prefix is present, before evaluating it against middleware route patterns. After the patch, both /_next/data/<buildId>/en/dashboard.json and /_next/data/<buildId>/dashboard.json correctly resolve to the logical page /dashboard and trigger middleware, closing the bypass.
It is worth noting that the exact commit implementing the fix has not been disclosed in the public advisory or release notes. This is typical for security patches within coordinated releases where diffs are merged privately before tagging a release.
Upgrade Commands
According to Vercel's official changelog, the latest recommended upgrade targets are v15.5.18 and v16.2.6, which bundle all fixes from the May 2026 coordinated release:
# For 15.x projects (recommended latest): npm install [email protected] # For 16.x projects (recommended latest): npm install [email protected]
Workaround for Teams Unable to Upgrade
For organizations that cannot upgrade immediately, the recommended structural workaround is to move authorization checks into the page's server side data path (e.g., within getServerSideProps) rather than relying solely on middleware. This ensures authorization is enforced regardless of how the request reaches the page handler.
Vercel explicitly noted that WAF rules were not deployed for this vulnerability, as the advisory class cannot be reliably blocked at the WAF layer. Upgrading the framework itself is the only complete resolution.
Affected Systems and Versions
The affected version range is extensive, spanning nearly four years of Next.js releases:
| Branch | Affected Versions | Fixed Version |
|---|---|---|
| 12.x through 15.x | 12.2.0 through 15.5.15 | 15.5.16 (recommended: 15.5.18) |
| 16.x | 16.0.0 through 16.2.4 | 16.2.5 (recommended: 16.2.6) |
The vulnerability specifically requires:
- Pages Router in use (not the App Router)
- Internationalization (i18n) configured in
next.config.js - Middleware or proxy based authorization as the primary access control mechanism for protected pages
Applications using the App Router, or Pages Router applications without i18n configuration, are not affected by this specific vulnerability.
Vendor Security History
The May 2026 coordinated release from Vercel addressed thirteen distinct security advisories in a single window, covering middleware bypasses, denial of service vulnerabilities, server side request forgery, cache poisoning, and cross site scripting. This volume of concurrent fixes across multiple vulnerability classes suggests that Next.js underwent a significant security audit or received a cluster of related reports in a short timeframe. The consolidation of all fixes into versions 15.5.18 and 16.2.6 demonstrates a responsive security team, but it also underscores the importance of maintaining automated dependency update pipelines for any project built on Next.js.
References
- CVE-2026-44573 NVD Record
- GHSA-36qx-fr4f-26g5: Vercel Security Advisory
- GHSA-36qx-fr4f-26g5: GitHub Advisory Database
- Next.js v15.5.16 Release
- Next.js v16.2.5 Release
- Next.js v16.2.6 Release
- Vercel Changelog: Next.js May 2026 Security Release
- dwisiswant0: Next.js v16.2.4 Security PoC Collection
- Cloudflare: WAF and Framework Adapter Mitigations for React and Next.js
