A single HTTP header should never be enough to bypass an application’s authentication system. Yet that is exactly what happened with CVE-2025-29927, a critical vulnerability in Next.js that allowed attackers to skip middleware-based security checks and potentially access routes intended only for authenticated users.
The vulnerability was publicly disclosed on March 21, 2025, after security researchers discovered that an internal request header could be manipulated to prevent Next.js middleware from executing. Applications that depended exclusively on middleware to enforce authentication or authorization could therefore expose protected resources without requiring valid credentials.
What makes CVE-2025-29927 particularly interesting is that the underlying problem was not a broken password mechanism, a stolen session token, or a vulnerability in a third-party authentication library. The weakness existed in the framework’s request-processing logic. An attacker could influence whether security middleware executed at all, effectively removing an application-level security boundary before the request reached its destination.
According to the official GitHub Security Advisory GHSA-f82v-jwr5-mffw, the vulnerability received a CVSS v3.1 score of 9.1, placing it in the Critical severity category. Its attack vector was network-based, and successful exploitation did not inherently require authentication or user interaction. The actual impact, however, depended on whether the application relied on middleware as its only authorization enforcement point.
Although patches have been available since March 2025, CVE-2025-29927 remains an important case study in web application security. It demonstrates how internal framework mechanisms can become attack surfaces when information supplied by external users is mistakenly treated as trusted execution state.
What Is CVE-2025-29927?
CVE-2025-29927 is an authorization bypass vulnerability affecting the middleware execution mechanism in certain versions of Next.js, the popular React framework used to build server-rendered and full-stack web applications.
Next.js middleware allows developers to inspect and modify incoming HTTP requests before those requests reach their final destinations. It is commonly used to implement redirects, authentication checks, access restrictions, localization, and request rewriting.
For example, a developer might configure middleware to prevent unauthenticated visitors from accessing /dashboard, /admin, or other private application routes. When a user attempts to access one of these paths, the middleware checks for a valid authentication session. If the required session does not exist, the application redirects the user to a login page.
Under normal circumstances, this provides a convenient first layer of access control. The problem uncovered in CVE-2025-29927 was that vulnerable versions of Next.js trusted a specially constructed internal header named x-middleware-subrequest.
The framework uses this header to track middleware-related subrequests and prevent recursive execution. However, vulnerable implementations did not sufficiently distinguish legitimate internal header values from attacker-controlled values arriving through ordinary external HTTP requests.
By supplying a crafted value, an attacker could cause the framework to treat an incoming request as one that should not execute middleware. The request would then continue toward its destination without the expected middleware checks.
Les National Vulnerability Database entry for CVE-2025-29927 identifies the issue as an authorization bypass affecting multiple Next.js release branches. The vulnerability is associated with improper or incorrect authorization, and its most serious consequences arise when protected application functionality is reachable without additional server-side permission checks.
The distinction matters: CVE-2025-29927 does not automatically defeat every authentication mechanism in a Next.js application. It bypasses middleware execution. Applications that independently verify user permissions inside API handlers, server-side data-access functions, and other sensitive operations retain those protections.
Why Next.js Middleware Became a Security Boundary
To understand the vulnerability, it helps to examine how middleware fits into the Next.js request lifecycle.
In many web applications, authentication is enforced directly inside an API endpoint or server-side controller. Before returning sensitive information, the endpoint verifies the user’s session and determines whether that user has permission to access the requested resource.
Next.js provides another option. Developers can place authentication-related logic in a central middleware.ts file, allowing requests to be examined before they reach protected routes.
Consider a simplified application that contains an administrative dashboard. Its middleware might look like this:
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const session = request.cookies.get('session');
if (
request.nextUrl.pathname.startsWith('/admin') &&
!session
) {
return NextResponse.redirect(
new URL('/login', request.url)
);
}
return NextResponse.next();
}
export const config = {
matcher: ['/admin/:path*'],
};This example illustrates a common architectural pattern rather than a complete or secure authentication implementation. Checking whether a cookie exists does not establish that the session is valid. Real applications must verify session integrity, expiration, and the user’s permissions.
Nevertheless, it demonstrates why developers might place authorization-related behavior in middleware. A central file provides a convenient way to define which routes require authentication, reducing repeated code across individual pages and endpoints.
The danger appears when the application assumes that reaching a protected route is proof that middleware has already approved the request.
Imagine that an administrative page loads sensitive records directly from a database without repeating the authorization check. Under normal conditions, the middleware redirects unauthenticated visitors before the page executes. But if an attacker can make the framework skip middleware, the administrative page may execute without ever establishing the visitor’s identity.
This is the trust boundary that CVE-2025-29927 crossed.
The flaw exposed a broader architectural risk: a security mechanism that depends on one framework execution stage can fail completely if that stage is bypassed. The authentication code itself might be logically correct, but it provides no protection when the framework does not execute it.
Vercel acknowledged this design concern in its official postmortem on the Next.js middleware bypass, emphasizing that middleware should not serve as an application’s only means of protecting sensitive routes.
How CVE-2025-29927 Works
The central element of CVE-2025-29927 is the HTTP header:
x-middleware-subrequestUnlike an ordinary application header such as Content-Type ou Autorisation, this header was intended for internal framework operations.
Next.js middleware can make requests that indirectly trigger further middleware execution. Without safeguards, recursive subrequests could create unnecessary repeated processing or even infinite loops.
To prevent this behavior, Next.js introduced an internal mechanism that uses x-middleware-subrequest to track middleware execution.
In vulnerable versions, the framework examined this header when deciding whether middleware should run. The critical mistake was accepting a value provided by an external client as though it represented trusted internal execution state.
Security researchers Rachid Allam and Yassir Alam demonstrated that the middleware execution logic could be manipulated by constructing a header value that matched the framework’s internal expectations. Their research also showed that the precise header value varied across Next.js versions and application layouts.
The Middleware Recursion Mechanism
In newer vulnerable implementations, Next.js tracked how many times a particular middleware identifier appeared in the internal subrequest chain.
The framework used a recursion limit of five to avoid repeatedly processing the same middleware.
This created an unintended security weakness. If an attacker could make an external request appear to have already traversed middleware five times, the framework could decide not to execute that middleware again.
For example, the researchers demonstrated the following header value against certain vulnerable Next.js implementations:
x-middleware-subrequest: middleware:middleware:middleware:middleware:middlewareFor projects that placed middleware in the src directory, the corresponding identifier could differ:
x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middlewareThese examples are version-dependent. Earlier implementations used different middleware identifiers and did not necessarily require the same repetition pattern.
The important point is not the number of characters in the header. It is the relationship between attacker-controlled request metadata and framework execution decisions.
The vulnerable framework interpreted the header as an instruction about the request’s internal history. As a result, a remote client could influence whether the middleware responsible for authentication, authorization, or another security-sensitive operation actually executed.
What Happens During an Attack?
Consider a hypothetical Next.js application with an administrative endpoint at /admin/reports.
Under normal conditions, an unauthenticated request follows this sequence:
Normal request processing
Incoming HTTP Request
Next.js Middleware
Authentication and authorization checks execute
Unauthenticated request redirected to login
Vulnerable request processing
Incoming request with crafted internal header
Middleware execution skipped
Framework trusts the attacker-controlled subrequest state
Protected route reached
Access succeeds only if the route lacks independent authorization checks
The second request never passes through the expected middleware verification logic. If the destination performs no additional authorization checks, the attacker may receive the protected response.
This is why CVE-2025-29927 is classified as an authorization bypass rather than a general-purpose remote code execution vulnerability. Its direct effect is to skip middleware, while the resulting security impact depends on the protected application’s behavior.
Which Next.js Versions Are Affected by CVE-2025-29927?
CVE-2025-29927 affects multiple generations of Next.js, including older applications that may still be running in production environments.
The official security advisory and NVD vulnerability record identify affected release ranges beginning with Next.js 11.1.4 and extending into the 15.x release line.
| Next.js Version | Versions vulnérables | Version corrigée |
|---|---|---|
| 11.x | 11.1.4 and later 11.x releases | No 11.x fix; upgrade |
| 12.x | 12.0.0 – 12.3.4 | 12.3.5 |
| 13.x | 13.0.0 – 13.5.8 | 13.5.9 |
| 14.x | 14.0.0 – 14.2.24 | 14.2.25 |
| 15.x | 15.0.0 – 15.2.2 | 15.2.3 |
These versions describe the original affected and fixed release branches, not a recommendation to continue operating an outdated Next.js release. Development teams should prefer a current, supported release that includes subsequent security fixes.
The patched versions are documented in the Next.js GitHub Security Advisory. GitHub also records the associated security classification and patch references.
One detail is especially important: the presence of a vulnerable Next.js version does not mean that every application is automatically exploitable.
Actual exposure depends on how the application is deployed and whether it depends on middleware for security-sensitive decisions.
Self-Hosted Next.js Applications
Self-hosted deployments represented the principal affected deployment category identified during the original investigation.
Applications running through next start or using output: 'standalone' could process attacker-supplied headers through vulnerable middleware execution logic.
This includes potentially exposed applications deployed using Docker containers, virtual machines, Kubernetes, or other hosting environments where the vulnerable Next.js server receives external requests.
A reverse proxy or CDN does not automatically eliminate the vulnerability. The relevant question is whether the infrastructure prevents untrusted x-middleware-subrequest headers from reaching the affected Next.js runtime.
An organization might, for example, operate a Next.js application behind Nginx while assuming that all administrative paths are protected by middleware. If the proxy forwards the crafted header unchanged and the application lacks secondary authorization checks, the deployment may remain exploitable.
Are Vercel, Netlify, and Cloudflare Workers Affected?
Not every hosting environment was affected in the same way.
Vercel confirmed that applications hosted on its platform were protected because the platform’s routing architecture was separated from the vulnerable Next.js application-level routing behavior.
In its official post-incident analysis, Vercel also reported that Netlify and Cloudflare Workers deployments were not affected by this vulnerability due to their respective routing architectures.
These findings should not be generalized to every application running behind Cloudflare or using a custom deployment adapter. A self-hosted Next.js server placed behind a reverse proxy requires its own evaluation.
The complete explanation is available in the Vercel security postmortem published on March 25, 2025.
Real-World Attack Scenarios and Security Impact
The security implications of CVE-2025-29927 extend beyond reaching a page that would normally redirect visitors to a login screen.
Middleware frequently acts as a shared enforcement point for multiple application behaviors. When developers place critical security logic exclusively in that layer, bypassing middleware can affect several features simultaneously.
Unauthorized Access to Administrative Dashboards
Administrative interfaces are particularly sensitive because they commonly expose account management functions, internal analytics, user records, and business configuration settings.
Imagine a SaaS platform using Next.js to serve both its public website and an administrative dashboard. The developers have configured middleware to restrict /admin routes to authenticated employees.
If the dashboard itself assumes that the middleware has already checked the user’s permissions, an unauthenticated attacker may be able to reach administrative functionality by bypassing the middleware.
Depending on the application, this could expose internal information or permit unauthorized operations.
The crucial condition is that authorization must be absent from the underlying application logic. A correctly implemented server-side permission check would continue to deny access even if the middleware were skipped.
Exposure of Sensitive API Endpoints
Another potentially serious scenario involves applications that use middleware to protect API routes.
For example, a developer might configure middleware to verify an authentication cookie before requests can reach /api/account, /api/invoicesou /api/users.
This arrangement may appear efficient because it centralizes authentication checks.
However, if the API endpoints do not independently validate the user’s identity and authorization, CVE-2025-29927 could allow requests to reach endpoint logic that was never intended to be publicly accessible.
Possible consequences include unauthorized data retrieval, access to other users’ resources, and modifications to sensitive records.
The degree of exposure depends on the data-access controls implemented after middleware.
An endpoint that verifies ownership of every requested resource remains substantially better protected than one that returns a database record solely because the incoming request reached the endpoint.
Bypassing Security Headers and Request Rewrites
The original researchers also demonstrated that the vulnerability could affect middleware functions unrelated to authentication.
Some applications use middleware to attach HTTP security headers, including Content Security Policy directives. Others use middleware to perform URL rewrites, localization, or additional request restrictions.
When middleware execution is skipped, those transformations may not occur.
For example, if a Content Security Policy is attached exclusively by middleware, the response might be returned without that particular policy. This does not automatically establish an exploitable cross-site scripting vulnerability, but it can remove a security control that was expected to be present.
Similarly, bypassing a rewrite can expose routes or response behavior that normal application traffic would not encounter.
In their original technical research on the Next.js middleware vulnerability, the discoverers described authorization bypasses, security-header bypasses, and potential cache-related denial-of-service conditions. The cache-related impact depends on how the application and its caching infrastructure handle the resulting responses.
These examples reveal why the issue is broader than a single login bypass. A vulnerable middleware implementation can undermine multiple security assumptions simultaneously.
How to Test for CVE-2025-29927
Security teams should approach CVE-2025-29927 testing as an authorization-verification exercise rather than relying only on version detection.
Finding a vulnerable dependency is an important first step, but the most meaningful assessment determines whether attacker-controlled requests can reach functionality that should remain inaccessible.
Testing should be performed only against applications and environments for which authorization has been granted.
Step 1: Identify the Installed Next.js Version
Start by identifying which Next.js version the application uses.
From the project directory, run:
npm ls nextAlternatively, inspect the dependency declaration:
npm pkg get dependencies.nextThe first command helps identify the installed dependency version, while the second displays the version range declared in package.json.
For projects using alternative package managers, inspect the corresponding lockfile and resolved dependencies.
A declaration such as ^14.2.0 does not prove that a patched version is installed. The lockfile, deployment artifact, and actual production runtime must be considered.
This distinction matters in containerized deployments, where the production image might contain a different dependency version from the developer’s local environment.
Step 2: Identify Security-Sensitive Middleware
Next, inspect the application’s middleware implementation.
In affected Next.js versions, relevant files commonly include:
middleware.ts
middleware.js
src/middleware.ts
src/middleware.jsLook for middleware logic involving authentication cookies, session validation, user roles, administrative route restrictions, API access controls, or redirects to login pages.
The existence of such logic is not itself proof of exploitability. The next question is whether equivalent permission checks exist at the application endpoint or data-access layer.
For example, if middleware restricts access to /admin, examine the relevant page, route handler, and database queries to determine whether the application independently validates the requesting user’s permissions.
Step 3: Compare Authorized Test Requests
A controlled test can compare the behavior of a protected endpoint under ordinary and modified request conditions.
On a locally hosted, intentionally vulnerable test application, an unauthenticated baseline request might look like this:
curl -i http://localhost:3000/adminWhen authentication enforcement is functioning, the response might redirect to a login page or return a 401 Non autorisé ou 403 Forbidden status, depending on the application.
A second request can be used to assess whether middleware execution changes when the internal header is supplied:
curl -i \
-H 'x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware' \
http://localhost:3000/adminThis header value is relevant to particular vulnerable implementations. It should not be assumed to work across every affected version or application layout.
In a deliberately vulnerable test application, a significant behavioral difference between the requests may indicate that middleware execution is being bypassed.
However, receiving an HTTP 200 OK response is not sufficient evidence on its own. Some applications return login pages with a 200 status, while others serve public content on routes that resemble protected paths.
A credible verification process should establish that the modified request actually reaches a protected resource or operation without satisfying the required authorization conditions.
The test should not retrieve real user data, modify production records, or perform destructive actions. A controlled non-sensitive test route is sufficient to validate the middleware behavior.
Step 4: Check Whether Independent Authorization Prevents Exposure
A particularly useful test compares the middleware behavior with server-side authorization enforcement.
Suppose a crafted header causes middleware to be skipped, but the destination endpoint still returns 403 Forbidden.
This result may demonstrate that the framework’s middleware execution is vulnerable while also showing that the application has an additional authorization boundary protecting the resource.
Conversely, if the same request can access protected data that was unavailable in the baseline test, the impact is considerably more serious.
Security assessments should document both findings separately.
The first is evidence of middleware bypass. The second is evidence of an application-level authorization failure resulting from that bypass.
This distinction prevents exaggerated vulnerability reports and helps engineering teams understand which controls need to be corrected.
How to Detect Exploitation Attempts
Network and application logs can provide useful evidence of attempts to exploit CVE-2025-29927.
Because the vulnerability depends on an HTTP header that normal external clients generally have no reason to supply, unexpected occurrences of x-middleware-subrequest in public-facing requests deserve investigation.
Security teams should examine HTTP request logs from reverse proxies, API gateways, web application firewalls, and other infrastructure components that can observe inbound request headers.
Repeated values containing middleware, src/middleware, or historical middleware identifiers may indicate vulnerability probing.
That said, the presence of the header alone does not prove successful exploitation. Automated scanners may send the same request to applications that are patched, unaffected, or configured with independent authorization controls.
Example Detection Logic
A simplified detection rule for security monitoring could be expressed as:
IF inbound_request.header_name == "x-middleware-subrequest"
AND request_origin == "external"
THEN flag_for_security_reviewIn practice, HTTP header names are case-insensitive. Detection logic should normalize header names before evaluating them.
Investigations can then correlate suspicious requests with application responses, access to protected routes, authentication events, and other available telemetry.
For example, a request containing x-middleware-subrequest that reaches an administrative endpoint without an associated authenticated session should receive greater scrutiny than a request to a public informational page.
Teams should also consider the visibility limitations of their logging infrastructure. Many web servers and CDN configurations do not record every HTTP request header by default.
If the relevant header was not captured historically, the absence of matching log entries cannot establish that no exploitation attempts occurred.
This is why preventive patching and verification are more reliable than retrospective log searches alone.
How to Fix CVE-2025-29927
The recommended remediation is to upgrade Next.js to a release that includes the security fix.
The original patched versions were Next.js 12.3.5, 13.5.9, 14.2.25, and 15.2.3. Organizations should generally move to a currently supported Next.js release rather than selecting an older release merely because it fixed this individual vulnerability.
For example, a project that must remain temporarily on a compatible 15.x release could inspect and update its dependency as part of a controlled remediation:
npm install next@15.2.3This specific command installs the initial patched 15.x release and should be understood as a historical minimum for CVE-2025-29927, not a complete security-update recommendation for October 2026.
After upgrading, rebuild and redeploy the application. Confirm that the production environment is actually running the corrected dependency version.
The patch changes how Next.js handles the internal subrequest header so that externally supplied or otherwise invalid values cannot be used to bypass middleware in the same manner.
The framework maintainers described their remediation approach in the official Vercel postmortem, while the source-level fixes can be inspected through the commits referenced in the GitHub advisory.
Temporary Mitigation: Block the Internal Header
If immediate upgrading is impossible, the official advisory recommends preventing external requests containing the x-middleware-subrequest header from reaching the vulnerable Next.js application.
This can be implemented at a trusted reverse proxy, API gateway, or web application firewall.
For example, an Nginx server configured as the public ingress could use a rule like the following:
server {
listen 80;
server_name example.com;
if ($http_x_middleware_subrequest != "") {
return 403;
}
location / {
proxy_pass http://nextjs_backend;
}
}This example demonstrates the general mitigation pattern. It should be adapted to the actual deployment architecture, with appropriate TLS configuration, existing proxy rules, and validation of header handling.
The rule rejects external requests containing the relevant header before forwarding them to the Next.js backend.
The distinction between external and internal requests matters. The affected header originally served a legitimate framework purpose, so ingress controls should be applied at the correct trust boundary rather than indiscriminately interfering with internal framework communication.
Blocking the header is an interim mitigation, not a permanent substitute for upgrading. Security teams should also verify that alternate network paths cannot reach the vulnerable application while bypassing the protective proxy.
Why Middleware Should Never Be the Only Authorization Layer
Patching CVE-2025-29927 addresses the framework vulnerability, but it does not eliminate the architectural risks associated with middleware-only authorization.
The safer design is to treat middleware as an initial request-filtering mechanism while enforcing sensitive permissions within trusted server-side application logic.
For example, middleware can quickly redirect unauthenticated visitors away from administrative routes. However, the underlying endpoint should still validate the user’s session and determine whether that user has permission to access the requested data.
Consider an API endpoint that returns administrative reports.
A more defensible design would resemble the following:
import { NextResponse } from 'next/server';
import { getVerifiedSession } from '@/lib/auth';
export async function GET() {
const session = await getVerifiedSession();
if (!session) {
return NextResponse.json(
{ error: 'Unauthorized' },
{ status: 401 }
);
}
if (session.role !== 'admin') {
return NextResponse.json(
{ error: 'Forbidden' },
{ status: 403 }
);
}
return NextResponse.json({
message: 'Authorized administrative response'
});
}Here, getVerifiedSession() represents an application-specific function that securely validates the authentication session. The example assumes that session data and role information have been obtained through a trusted mechanism rather than directly trusting unsigned client-controlled values.
The important improvement is that authorization occurs inside the route handler.
Even if middleware fails to execute, the endpoint independently evaluates whether the request is allowed.
For applications serving sensitive database records, authorization should be enforced even closer to the underlying data access.
For example, a user requesting an invoice should not merely prove that they are logged in. The server should also confirm that the invoice belongs to that user or an organization the user is authorized to access.
This prevents another common weakness: insecure direct object references, where authenticated users can access resources belonging to other accounts by manipulating identifiers.
The official Next.js authentication documentation recommends centralizing authorization logic in a Data Access Layer and returning only necessary information through Data Transfer Objects. It also distinguishes optimistic authorization checks from secure checks performed using trusted server-side data.
This model provides stronger protection because authorization no longer depends on one request-processing stage.
For teams using more recent versions of Next.js, it is also worth noting that Next.js 16 renamed Middleware to Proxy. The functionality remains related, but the documentation explicitly warns against using Proxy as a complete authorization or session-management solution. The Next.js Proxy documentation explains the intended role of this layer.
What the CVE-2025-29927 Disclosure Revealed About Framework Security
The history of CVE-2025-29927 also offers an important lesson about vulnerability handling in widely used software frameworks.
According to Vercel’s published timeline, the issue was initially reported to the Next.js team on February 27, 2025. The early report focused on older Next.js versions, and subsequent communication expanded the identified impact to more recent releases.
The initial assessment and communication process took longer than expected. Vercel later acknowledged delays in triage and areas where coordination with deployment-platform partners could have been improved.
The vulnerability was confirmed in March, with fixes released for Next.js 14.2.25 on March 17 and 15.2.3 on March 18. Additional backported fixes followed for Next.js 13.5.9 and 12.3.5 on March 22 and March 23, respectively.
The advisory became public on March 21, 2025.
Vercel’s official incident timeline provides the dates, technical findings, and process changes introduced after disclosure.
The incident illustrates why vulnerabilities in frameworks require a different kind of analysis from vulnerabilities in ordinary application dependencies.
A flaw in a framework’s request-processing mechanism can affect many unrelated applications that rely on the same behavior. Yet the resulting impact may vary significantly depending on the applications’ security architecture and deployment infrastructure.
Two companies could run the same vulnerable Next.js version and experience very different outcomes.
One might have centralized all authorization decisions in middleware, allowing the bypass to expose sensitive endpoints.
Another might use middleware only for redirects while verifying every sensitive operation within server-side application logic. In that case, the same framework weakness may have a much smaller practical security impact.
Dependency vulnerability detection identifies where a weakness may exist. Authorization testing determines what the weakness means for a particular application.
Both are necessary for accurate risk assessment.
CVE-2025-29927 and the Risks of Implicit Trust
Beyond the immediate Next.js vulnerability, CVE-2025-29927 illustrates a recurring security design problem: internal system metadata becomes dangerous when an external client can influence it.
Modern applications depend on many forms of internal request metadata. Reverse proxies add forwarding headers, authentication gateways attach identity information, and application frameworks create routing and execution-state headers.
Such mechanisms work safely only when the system distinguishes trusted internal information from externally supplied inputs.
In the case of CVE-2025-29927, a header intended to describe internal middleware execution state crossed that trust boundary.
The framework used the value to make a security-relevant execution decision, even though the external requester could influence it.
A similar general design mistake can occur when applications trust client-supplied IP address headers for security decisions, accept unverified identity headers, or use user-controlled routing information to bypass access restrictions.
The individual vulnerabilities may differ, but the underlying principle is consistent: information describing trusted system state must originate from a trusted source or undergo appropriate validation.
For AI-assisted security testing and automated vulnerability assessment, this type of weakness is especially instructive.
Traditional dependency scanners can identify that an application uses an affected Next.js release. Dynamic testing can investigate whether a crafted request causes middleware behavior to change. But determining real exploitability requires understanding whether the application performs independent authorization checks after the middleware stage.
A reliable assessment therefore combines version identification, controlled request comparison, application-flow analysis, and verification of server-side access controls.
Simply observing that a response changed after adding a header is not enough to conclude that sensitive data is exposed.
Conversely, finding a vulnerable dependency without testing application behavior may underestimate or overestimate the actual business risk.
Frequently Asked Questions About CVE-2025-29927
What is CVE-2025-29927?
CVE-2025-29927 is a critical authorization bypass vulnerability in Next.js. It allows specially crafted external HTTP requests to skip middleware execution in affected versions. If an application relies exclusively on middleware to enforce authentication or authorization, an attacker may be able to access protected functionality without satisfying those checks.
What is the CVSS score of CVE-2025-29927?
The GitHub Security Advisory assigns CVE-2025-29927 a CVSS v3.1 score of 9.1, categorized as Critical. The vulnerability is remotely reachable, requires low attack complexity, and does not inherently require authentication or user interaction. Its practical consequences depend on the target application’s use of middleware and additional security controls.
What is the x-middleware-subrequest header?
Les x-middleware-subrequest header is an internal Next.js mechanism originally used to track middleware-related subrequests and prevent recursive middleware execution. Vulnerable implementations accepted manipulated values from external requests, allowing attackers to influence whether middleware executed.
Does CVE-2025-29927 affect Next.js 15?
Yes. Next.js versions from 15.0.0 through 15.2.2 are included in the affected version range. The original fix was released in Next.js 15.2.3. Developers should use an appropriately maintained release that also incorporates subsequent security updates.
Can CVE-2025-29927 bypass authentication?
It can bypass authentication or authorization checks implemented exclusively in middleware. It does not automatically bypass independent session validation, permission checks, or database-level authorization implemented inside the destination application logic.
Is CVE-2025-29927 a remote code execution vulnerability?
No. CVE-2025-29927 is classified as an authorization bypass vulnerability, not remote code execution. Its direct effect is to skip middleware execution. Depending on what an application exposes behind that middleware, successful exploitation could permit unauthorized data access or application actions.
Are all Next.js applications vulnerable?
No. Exposure depends on the affected version, hosting architecture, middleware configuration, and application-level authorization controls. Vercel reported that applications hosted on its platform were protected, while self-hosted applications running vulnerable Next.js servers required attention. Applications without security-sensitive middleware may not have the same authorization-bypass exposure.
How can CVE-2025-29927 be prevented?
The primary fix is to upgrade Next.js to a patched and supported release. Where immediate patching is impossible, organizations can block externally supplied x-middleware-subrequest headers at trusted ingress points. Sensitive application functionality should also enforce authentication and authorization independently of middleware.
Réflexions finales
CVE-2025-29927 stands out because of the simplicity of the underlying attack and the significance of the security boundary it exposed.
The vulnerability did not require attackers to discover an application’s password, compromise a session cookie, or exploit a complex memory-corruption condition. Instead, it exploited the framework’s interpretation of internal request metadata.
For applications that trusted middleware as their only authorization control, that distinction could be the difference between a protected resource and an exposed endpoint.
The patches released in March 2025 addressed the immediate framework flaw, but the incident remains relevant to how modern web applications should be designed and tested.
Middleware can provide useful early authentication checks, redirects, request transformations, and other controls. It should not be the final authority governing access to sensitive information.
Effective protection requires a combination of maintained dependencies, trusted request-processing boundaries, authorization checks at the application and data-access layers, and security testing that verifies actual behavior rather than relying exclusively on dependency versions.
The enduring lesson from CVE-2025-29927 is straightforward: a request reaching a protected route does not prove that every security check intended to protect that route has executed.
Applications should enforce authorization where sensitive data is accessed and sensitive operations are performed, even when earlier security controls appear to be functioning correctly.
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew