CVE-2025-29927 Next.js Middleware Bypass Explained

CVE-2025-29927 is a critical security vulnerability in Next.js that can allow attackers to bypass middleware-based authorization controls. The flaw involves the x-middleware-subrequest HTTP header, which the framework uses internally to manage middleware execution. If an application relies on middleware as its primary access-control layer, a successful bypass may expose routes intended for authenticated users only.

Disclosed in March 2025, the vulnerability is particularly relevant to self-hosted Next.js deployments. Security teams should review their framework versions, assess where authorization is enforced, and apply the appropriate security updates. ProjectDiscovery’s technical analysis describes the underlying mechanism and detection approach.

What Causes CVE-2025-29927?

Next.js middleware can handle request filtering, redirects, URL rewrites, and access checks before a request reaches an application route. The x-middleware-subrequest header was designed for internal middleware processing, including preventing repeated execution loops.

The vulnerability arose because externally supplied header values could influence the framework’s decision to skip middleware execution. A specially constructed value containing the expected middleware identifier could trigger this behavior in affected versions. As a result, requests could reach protected routes without passing through the middleware checks developers expected to run.

This creates a serious risk for applications that depend exclusively on middleware for authentication or authorization. Sensitive operations should also enforce access controls at the application, API, or data-access layer.

Affected Next.js Versions

The original advisory identifies the following affected release ranges:

• Next.js 11.1.4 through 13.5.6: affected versions in this range require the recommended workaround or an appropriate patched release.
• Next.js 14.x: versions earlier than 14.2.25 are affected.
• Next.js 15.x: versions earlier than 15.2.3 are affected.

Fixes were also backported to Next.js 13.5.9 and 12.3.5. These are historical minimum fixed versions, not a recommendation to run outdated branches. Upgrade to a currently supported release that includes the security fix. Consult the official Next.js security advisory before planning an upgrade.

Potential Security Impact

• Authorization bypass: Attackers may reach protected pages or endpoints if middleware is the only control enforcing access.
• Security-header omissions: Content Security Policy or other security headers may not be applied if middleware responsible for setting them is skipped.
• Application data exposure: Sensitive records or administrative functions may become accessible if downstream routes do not perform their own authorization checks.
• Cache and routing risks: Applications relying on middleware to control caching or request routing may behave unexpectedly when those controls are bypassed.

The actual impact depends on the application’s architecture and the protections enforced beyond middleware. A successful detection signal should therefore be investigated rather than treated as proof that every listed impact is exploitable.

Detection and Security Testing

Security teams can start by identifying the installed Next.js version and reviewing which routes rely on middleware for access control. Authorized testing can then compare how a protected route responds to an ordinary unauthenticated request and to a request containing a crafted x-middleware-subrequest header.

For controlled testing, the following illustrates the header associated with the issue. Use it only against an application you own or have explicit permission to assess.

GET /dashboard/admin HTTP/1.1
Host: your-authorized-test-host
X-Middleware-Subrequest: middleware:middleware:middleware:middleware:middleware

A successful HTTP response alone does not confirm the vulnerability. Review the response body, authentication state, application logs, and expected authorization behavior. ProjectDiscovery also provides a Nuclei-based detection approach for authorized security assessments.

For broader web reconnaissance, the WhatWeb web scanner can help identify technologies exposed by a target, although technology identification alone does not confirm CVE-2025-29927.

Mitigation and Remediation

1. Upgrade Next.js: Move to a currently supported release containing the fix and follow the official migration guidance.
2. Filter the header: If an immediate upgrade is impossible, configure a trusted reverse proxy, web server, or load balancer to remove the externally supplied x-middleware-subrequest header before forwarding requests to Next.js.
3. Strengthen authorization: Enforce authentication and permission checks inside sensitive route handlers, API endpoints, and data-access operations rather than relying solely on middleware.
4. Validate the fix: Retest protected routes, inspect deployment configuration, and review logs for suspicious requests or unexpected access.

For Nginx deployments, a proxy configuration can remove the incoming header before sending the request upstream:

proxy_set_header x-middleware-subrequest "";

For Apache configurations using mod_headers, an equivalent request-header removal rule is:

RequestHeader unset x-middleware-subrequest

Apply these directives in the appropriate proxy configuration and verify that the upstream application does not receive the untrusted header. Configuration requirements vary by deployment, so test the change before relying on it. Header filtering is a temporary mitigation, not a replacement for installing the security fix.

Vercel-hosted deployments were reported as protected against CVE-2025-29927 by Vercel’s platform-level defenses. Organizations using other hosting providers or self-managed infrastructure should confirm their exposure with their provider and deployment configuration.

Ultimately, CVE-2025-29927 demonstrates why security boundaries should not depend on a single middleware layer. Prompt patching, independent authorization checks, and verification of reverse-proxy behavior provide a stronger defense against this class of vulnerability.