About Author
Hi, I'm Sharon, a product manager at Chaitin Tech. We build SafeLine, an open-source Web Application Firewall built for real-world threats. While SafeLine focuses on HTTP-layer protection, our emergency response center monitors and responds to RCE and authentication vulnerabilities across the stack to help developers stay safe.
A logic flaw in Next.js middleware exposes protected routes in major AI applications. Here's what happened—and how to fix it.
Next.js, the full-stack web framework developed by Vercel, powers many modern SSR/SSG and Edge Function apps. But in March 2025, a critical vulnerability (CVE-2025-29927) was publicly disclosed—affecting authentication and security middleware in real-world deployments.
Vulnerability Summary
The issue lies in how Next.js middleware handles a special internal request header: x-middleware-subrequest.
Originally designed for internal use only, this header was not properly validated—allowing attackers to spoof it in external requests. As a result, authentication logic, redirects, or other security-related middleware could be silently bypassed.
This flaw is especially dangerous for apps using Edge Middleware (enabled by default) to protect routes such as admin panels or APIs. Researchers at Chaitin Tech confirmed the bug could affect several popular AI-powered web applications.
Root Cause
Next.js trusted the presence of x-middleware-subrequest without verifying its origin.
By injecting this header manually, attackers can trick the framework into skipping middleware execution, effectively bypassing logic that enforces authentication, permissions, or headers like CSP.
Conditions for Exploitation
- App uses Next.js middleware for auth, redirects, or request filtering.
- Middleware runs in Edge Function mode (default in recent versions).
- External requests can include custom headers.
Impact
- Auth Bypass: Attackers gain access to protected pages or APIs (e.g., admin dashboards, user data).
- Security Controls Bypassed: Middleware-defined CSP, header injection, or other filters can be skipped, increasing risk of XSS or similar attacks.
- No User Interaction Needed: Exploitable remotely, without login or user clicks.
| Risk Level | HIGH |
|---|---|
| Attack Vector | Remote / Network |
| Auth Required | None |
| Affected Config | Default (Edge on) |
| Exploit Maturity | POC Public |
| Fix Complexity | Low (patch available) |
Affected Versions
The bug affects the following Next.js versions:
-
11.1.4to13.5.6 -
14.0.0to14.2.24 -
15.0.0to15.2.2
Fixed in:
14.2.2515.2.3
How to Fix It
Upgrade Now
If you're using one of the vulnerable versions, update to a patched version immediately:
npm install next@14.2.25
# or
npm install next@15.2.3
Temporary Mitigation
If immediate upgrade isn't possible, apply these workarounds:
-
Strip the Header: Use a reverse proxy (e.g., Nginx) to remove
x-middleware-subrequestfrom all external requests. - Filter at CDN/WAF: Block or sanitize this header at the gateway level.
Reproduction
Researchers have publicly released a working POC showing how to exploit the bug by sending crafted requests with the forged header.
Timeline
- Mar 23, 2025: Vulnerability publicly disclosed
- Mar 23, 2025: Chaitin Security Lab reproduced the exploit
- Mar 24, 2025: Emergency advisory released by Chaitin
References
- GitHub Advisory: https://github.com/advisories/GHSA-f82v-jwr5-mffw
Join the SafeLine Community
Stay secure. Always verify what headers you're trusting—and never assume they're safe just because they exist.
Top comments (2)
CVE-2025-29927 was a wake-up call. I’ve always trusted Next.js for secure routing, so discovering this middleware flaw forced me to android course in kochi reevaluate our app’s authentication layers. After patching and adding server-side checks, I’m now even more cautious about relying solely on middleware for access control in production environments.
CVE-2025-29927 was a wake-up call. I’ve always trusted Next.js for secure routing, so discovering this middleware flaw forced me to android course in kochi reevaluate our app’s authentication layers. After patching and adding server-side checks, I’m now even more cautious about relying solely on middleware for access control in production environments.