CVE-2025-29927: Next.js Middleware Authorization Bypass 
Related Materials
Authorization Bypass in Next.js Middleware
Timeline 
- 2025-02-27T06:03Z: Disclosed to the- Next.jsteam via- GitHubprivate vulnerability report.
- 2025-03-14T17:13Z:- Next.jsteam began triaging the report.
- 2025-03-14T19:08Z: Patch pushed for- Next.js 15.xversions.
- 2025-03-14T19:26Z: Patch pushed for- Next.js 14.xversions.
- 2025-03-17T22:44Z:- Next.js 14.2.25version released.
- 2025-03-18T00:23Z:- Next.js 15.2.3version released.
- 2025-03-18T18:03Z:- GitHubpublished the- CVE-2025-29927report.
- 2025-03-21T10:17Z: Security advisory published.
- 2025-03-22T21:21Z:- Next.js 13.5.9version released.
- 2025-03-23T06:44Z:- Next.js 12.3.5version released.
Overview 
On 2025.3.21, a critical security vulnerability CVE-2025-29927 was disclosed, with a CVSS (Common Vulnerability Scoring System) score of 9.1 / 10.0, rated as Critical. It primarily affects applications using middleware for authorization checks. Attackers can bypass authorization checks by setting the x-middleware-subrequest header, tricking the system into treating external requests as internal sub-requests.
The Next.js team quickly released patches after the vulnerability disclosure and collaborated with cloud service providers (such as Vercel and Cloudflare) to provide network-level mitigations.
Affected Versions 
This vulnerability affects almost all Next.js versions and has been patched in Next.js versions 14.2.25 and 15.2.3.
Fixed Versions
- 14.2.25: Released on- 2025.3.17published- 14.2.25
- 15.2.3: Released on- 2025.3.18published- 15.2.3
Users of older Next.js versions (11.1.4 ~ 13.5.6) have not yet received available patches. In particular, any applications using these earlier versions and relying on Middleware for authorization checks may be affected.
Mitigation Strategies 
- Upgrade to Latest Version - It is recommended to upgrade to - Next.jsversion- 14.2.25or- 15.2.3and above, which include patches for- CVE-2025-29927.
- Filter - x-middleware-subrequestHeader- If immediate upgrade is not possible, you can filter this header through server or proxy configuration to prevent external requests from carrying - x-middleware-subrequest. For example, you can use a reverse proxy (like- Nginx) or- WAFrules (such as- Cloudflare WAF) to implement this functionality.
Fix Details 
Related Materials
const randomBytes = new Uint8Array(8); 
crypto.getRandomValues(randomBytes); 
const middlewareSubrequestId = Buffer.from(randomBytes).toString('hex'); 
(globalThis as any)[Symbol.for('@next/middleware-subrequest-id')] =
  middlewareSubrequestId; // If this request didn't origin from this session we filter
// out the "x-middleware-subrequest" header so we don't skip
// middleware incorrectly
if (
  header === 'x-middleware-subrequest' &&
  headers['x-middleware-subrequest-id'] !==
    (globalThis as any)[Symbol.for('@next/middleware-subrequest-id')] 
) {
  delete headers['x-middleware-subrequest']; 
}Next.js generates a unique middleware sub-request identifier for each session and stores it in the Symbol.for('@next/middleware-subrequest-id') property of the globalThis object. Only sub-requests from the current session can use the special marker to skip middleware, preventing requests from other sessions from bypassing the middleware processing flow through forged headers.
Follow-up 
Next.js Official 
Related Materials
After releasing the patch, the Next.js team also updated the docs documentation, clarifying that Next.js middleware is not suitable for authorization checks.
Some common scenarios where Middleware is effective include:
- Quick redirects after reading parts of the incoming request
- Rewriting to different pages based on A/B tests or experiments
- Modifying headers for all pages or a subet of pages
Middleware is _not_ a good fit for:
- Slow data fetching
- Session managementCommunity 
The middleware design is more suitable for simple request preprocessing rather than core security logic. CVE-2025-29927 exposed its inadequacies in header validation.
| Category | Content | Source | 
|---|---|---|
| Middleware Design Limitations | Not suitable for complex permission validation, vulnerable to header manipulation attacks | Reddit Discussion, Medium Article | 
| Recommendation to Move to Routes or API Layer | Implement stricter validation in backend routes, use middleware only for simple interception | ZeroPath Blog, ProjectDiscovery Blog | 
| Necessity of Multi-layer Defense | Combine WAF and server-side validation to ensure security | Hacker News, ProjectDiscovery Blog | 
| Correct Use of Middleware | Normative for global authentication | GitHub Pull Request Comment | 
 XiSenao
 XiSenao