14 September, 2026
The Next.js security story changed significantly between 2025 and 2026.
CVE-2025-29927 was a critical authorization bypass that demonstrated how applications relying on Middleware for authorization could be exposed to crafted requests. The vulnerability carried a CVSS score of 9.1 and affected multiple Next.js release lines before patched versions were released.
But CVE-2025-29927 was not the end of the story.
In May 2026, Next.js disclosed additional Middleware/Proxy authorization bypasses involving App Router segment-prefetch routes, Pages Router i18n routes, and dynamic route parameters.
In July 2026, another HIGH-severity Middleware/Proxy bypass affected certain App Router applications using Turbopack and a single configured i18n locale.
This guide explains:
Your engineering team tells you that a Next.js vulnerability has been identified. The team upgrades the framework, CI passes, production is redeployed, and the incident is considered closed. From an operational perspective, that may be the correct first response.
From a CTO's perspective, there is another question: Did the vulnerability expose an architectural dependency that persists after the patch?
That distinction became particularly important after CVE-2025-29927, which demonstrated that authorization checks implemented in Next.js Middleware could be bypassed in affected versions. The issue was fixed in patched releases, but the broader architectural question remained: what happens if the request reaches protected application logic without passing through that particular control?
The subsequent 2026 Middleware/Proxy disclosures made that question even more relevant.
Next.js security in 2026 should therefore be viewed through two connected lenses:
For CTOs, the second question is where security architecture becomes business risk management.
CVE-2025-29927 was a critical authorization bypass in Next.js Middleware.
Affected applications could have authorization checks bypassed when those checks were implemented in Middleware. The vulnerability affected several Next.js release lines and was fixed in versions including 12.3.5, 13.5.9, 14.2.25, and 15.2.3.
The important architectural condition was simple: If Middleware was responsible for deciding whether a user could access protected resources, bypassing Middleware could undermine that authorization decision.
The rendering architecture decisions that determine how Next.js handles server-side execution are covered in our Next.js Partial Prerendering guide.
That does not mean every Next.js application became a data breach. The actual exposure depended on how the application implemented authentication, authorization, data access, and protected operations. That distinction matters.
The business impact of an authorization bypass depends on what the protected application exposes. A SaaS platform may have protected routes for:
If an attacker can reach a protected operation without satisfying the intended authorization controls, the resulting exposure can range from limited information disclosure to unauthorized business actions.
That is why the right post-vulnerability question is not simply: "Did we upgrade Next.js?"
It is: "Was our application exposed while the vulnerable version was deployed, what resources were reachable, and where is authorization enforced today?"
CVE-2025-29927 should be understood as the beginning of a broader security lesson rather than an isolated incident.
In May 2026, Next.js disclosed multiple Middleware/Proxy-related vulnerabilities. One HIGH-severity issue affected App Router applications using Middleware/Proxy with segment-prefetch routes. Another affected Pages Router applications using i18n, where specially constructed data requests could bypass expected authorization checks. A separate issue involved the dynamic injection of route parameters.
The recommended workaround for affected configurations was consistent: Enforce authorization in the server-side page or route logic instead of relying solely on Middleware.
In July 2026, Next.js disclosed another HIGH-severity Middleware/Proxy bypass affecting certain App Router applications using Turbopack and a single entry in config.i18n.locales. The issue affected versions in the Next.js 16.0.x–16.2.x range before the relevant patched release.
The important takeaway is not the specific configuration. It is the pattern: A request-level security mechanism can contain framework-level vulnerabilities, so sensitive operations should not depend exclusively on that mechanism.
Next.js itself has changed the terminology and direction around Middleware.
Starting with Next.js 16, the middleware.ts convention was renamed to proxy.ts. Next.js describes Proxy as a network boundary that can modify requests and responses before routing continues. The framework also recommends avoiding Middleware unless there is a clear reason to use it and says Proxy should not be treated as a complete session-management or authorization solution.
This distinction is important. Proxy can be useful for:
But protected operations still need independent controls.
Defense-in-depth request flow:
Client → Authentication → Proxy → Server Component / Route Handler / Server Action → Authorization → Data Access Layer → Database
If Proxy fails, the protected server-side operation should still determine whether the user is allowed to perform the requested action. That is defense in depth.
The most important security decisions in a Next.js application are not limited to the framework version.
This is one of the most consequential questions a CTO can ask.
The CTO test: Ask your engineering team: "If we disabled Proxy/Middleware today, could an unauthenticated or unauthorized user still access protected data or perform protected operations?" If the answer is yes, the application deserves an architectural security review.
Server Components execute on the server, but application data can still cross the server/client boundary through the React Server Components architecture. The security problem is not that Server Components are inherently insecure. The problem is over-fetching and over-sharing data that the user is not authorized to receive.
The core principle: Retrieve and transmit the minimum data required for the authorized operation. This is particularly important for applications handling financial, healthcare, customer, or other sensitive information.
Security cannot depend on developers noticing vulnerabilities through news articles or social media. Next.js has moved toward a more formal security-release process in 2026, with scheduled security releases and advance notice. The July 2026 release addressed four HIGH and five MEDIUM severity vulnerabilities, while the August 2026 release addressed two CRITICAL vulnerabilities.
A mature Next.js engineering organization should have:
Lower-risk signal: A critical Next.js vulnerability can move from disclosure to assessment, patching and deployment without waiting for the next normal feature sprint.
Higher-risk signal: Security upgrades compete with normal product work and are deployed only when engineering capacity becomes available.
Production is not necessarily the only deployment surface that matters. Preview and branch deployments can introduce additional exposure when they contain the same application code or vulnerable dependencies as production.
A mature deployment process should answer:
The goal is to make sure every reachable deployment is accounted for in the security model.
Use the following framework during an architecture review, security review, or vendor evaluation:
| Risk Dimension | Lower-Risk Signals | Higher-Risk Signals |
|---|---|---|
| Authorization Architecture | Authorization enforced at protected server-side operations | Authorization depends primarily on Middleware/Proxy |
| Data Exposure | Explicit field selection and controlled data shaping | Broad database objects passed toward client-visible boundaries |
| Dependency Governance | Automated scanning, named owner and defined security SLA | Reactive updates and normal sprint scheduling |
| Deployment Control | Production and reachable environments tracked and patched | Unmanaged previews or unknown deployment versions |
A single weakness in authorization architecture does not automatically mean a breach exists. It does mean the architecture deserves closer examination.
1. Where does authorization enforcement actually happen?
Look for a clear answer involving the protected server-side operation, not simply: "Middleware checks whether the user is logged in." Authentication and authorization are related but different controls.
2. If Proxy/Middleware fails, what protects the data?
A mature answer should describe an independent authorization mechanism inside the server-side application/data-access path.
3. What happens when a critical Next.js advisory is published?
Look for automated alerts, named ownership, severity classification, impact assessment, emergency deployment process, and verification after deployment.
4. How do you verify all deployed environments are patched?
The answer should cover production, staging, and relevant preview/branch deployments rather than production alone.
5. How do you prevent unauthorized data from crossing the server/client boundary?
Look for explicit data selection, authorization before retrieval, DTO/data-shaping patterns, controlled data-access functions, and regular review of Server Components and Client Components.
If a team cannot answer these questions with architectural specificity, the issue may be deeper than framework patch management.
Next.js 16 renamed the Middleware convention to Proxy. The change is more than a naming adjustment. The framework documentation explains that the new proxy.ts terminology is intended to clarify that this functionality operates at a network boundary rather than functioning like conventional application middleware.
For teams maintaining existing applications, there are two separate considerations:
Next.js provides a codemod for migrating from the deprecated Middleware convention to Proxy.
CVE-2025-29927 was a critical reminder that Middleware-based authorization could become a significant application risk when a framework vulnerability bypassed the mechanism enforcing it.
The 2026 security disclosures reinforced the lesson. Next.js applications need two complementary defenses: rapid framework patching and independent application-level authorization.
A patched framework reduces exposure to known vulnerabilities. A defense-in-depth architecture reduces the potential impact when an individual security control fails.
For CTOs, the most useful question is therefore not: "Are we running the latest version of Next.js?"
It is: "If our request-level security control fails, does authorization still protect our data and business operations?"
If the answer is yes, your architecture has meaningful defense in depth. If the answer is no, upgrading the framework is necessary, but it may not be the end of the security work.
If you need to evaluate, secure, or modernize a production Next.js application, choose to hire Next.js developers who understand defense-in-depth architecture, security compliance, and your modern development roadmap.
Attackers added an x-middleware-subrequest header to their HTTP requests, which tricked Next.js into skipping the middleware logic entirely and granting unauthorized access to protected routes.
It should live at the data-access layer (inside Server Components, Data Access Objects, or API route handlers) so that access checks execute regardless of how a request enters the server.
Yes. Platforms like Vercel often apply edge-level mitigations automatically, whereas self-hosted setups (Docker, Node servers) require manual framework patches or WAF rules to strip internal headers.
By treating every Server Action like a public API endpoint, manually validating the session, checking user permissions, and sanitizing inputs at the start of the action handler.
By combining automated dependency auditing (npm audit / Snyk), writing integration tests that target route handlers directly, and enforcing defense-in-depth instead of single-point middleware checks.
Nikhil Shah is the CTO and Co-Founder of iSyncEvolution, an engineering leader who aligns modern technology best practices with long-term commercial success. A veteran of cloud infrastructure and scalable web/mobile solutions, he specializes in building high-performance software environments. Nikhil helps global brands master their technical roadmaps, optimizing both code performance and development economics to fuel growth.
© 2026 iSyncEvolution Pvt Ltd. All Rights Reserved.
