Middleware can be one layer, but it should not be the sole check. A 2025 flaw in a popular web framework let attackers skip middleware, and with it any authorization done there. Enforce access again where the data is read, and keep the framework patched.
What happened
CVE-2025-29927 was published on 21 March 2025. The NVD description says that in Next.js, starting from version 1.11.4 and before 12.3.5, 13.5.9, 14.2.25 and 15.2.3, it was possible to bypass authorization checks in an application if the check occurred in middleware. The record gives a CVSS 3.1 base score of 9.1 from the GitHub advisory source. It also states a workaround for teams that could not patch: prevent external requests that contain the x-middleware-subrequest header from reaching the application.
The lesson is general. The specific header is not the point. The point is that a gate in one place can have a bypass nobody knew about.
Why edge and static setups are prone to this
Sites on CDNs and edge platforms often keep protection logic in a single early function: check a cookie, redirect to login. That is fast and tidy. It also means every protected path depends on that one function running, and on the platform routing every request through it.
Common ways a single gate fails:
- A framework or platform bug lets a request skip it, as above.
- A path pattern misses a route, such as an API path or a static file with a similar prefix.
- A cache serves a protected page to someone who should not see it.
- A new route is added and nobody updates the matcher.
Layered checks
| Layer | What it checks | Fails when |
|---|---|---|
| Edge or middleware | Is there a session at all | Gate is bypassed or misses a path |
| Route handler or page | Is this user allowed this page | Developer forgets to add it |
| Data access | Is this user allowed this record | Rarely, because it is closest to the data |
| Cache rules | Is private content kept out of shared caches | Headers are wrong |
Put the decisive check at the data access layer. Use middleware for convenience and early redirects.
Steps to take now
- Find your framework version and compare it with the NVD record's fixed versions if you use that framework.
- List every protected route and note where authorization is enforced. If the answer is "middleware" for any of them, add a second check.
- Write a test that requests a protected path without a session and expects a denial, and run it against the deployed environment.
- Confirm protected responses are not cacheable by shared caches. See purge the CDN cache after a security fix.
- If you cannot upgrade, consider a rule at your CDN or proxy that strips or rejects the header named in the workaround, and plan the upgrade.
Try it yourself
The exploitability check demo shows how to tell whether a published flaw applies to your deployment. Try it with the question: is my authorization really in the vulnerable component?
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans your dependencies for known vulnerabilities like this one and uses reachability analysis to show where the affected package is used. Free scan: gold.safeguard.sh/scan.
Quick check
Does this affect static files served from a CDN with no framework runtime?
The record concerns an application where the check occurs in middleware. A fully static export without that runtime does not use middleware. Confirm how your site is actually deployed.
Is a header block at the CDN a fix?
It is the workaround the advisory describes when patching is not possible. Upgrading to a fixed version is the real remedy.
Sources
- NVD, CVE-2025-29927: https://nvd.nist.gov/vuln/detail/CVE-2025-29927
Last reviewed: 19 October 2026.
