CVE-2025-29927 in Next.js: why middleware should not be your only access barrier

Published on 2026-10-27 by frfrand

Middleware bypass in Next.js explained with real-world scenarios, hosting scope, patches, and authorization recommendations.

CVE-2025-29927 in Next.js: why middleware should not be your only access barrier

The scenario: hiding a page does not mean protecting its data

Suppose you created a private panel with Next.js. The middleware checks if there is a session and, if it does not find one, redirects to login. It seems sufficient, but CVE-2025-29927 left an important lesson: a flaw in the handling of a certain internal framework signal could cause middleware execution to be skipped. If all security depended on that single step, some routes could end up being accessed improperly.

What is middleware in Next.js?

It is code that can intervene before routing to modify, redirect, or block requests. It serves for many tasks, including an initial session check. But a sensitive access validation must also run where the data is delivered or the operation is performed, not only before reaching the page.

Who discovered the vulnerability and how was it reported?

Next.js credits researchers Rachid Allam (zhero) and Yassir Alam (inzo_). The initial private report arrived on February 27, 2025. In their subsequent analysis, the project detailed delays and coordination improvements before publishing the patches and the CVE in March. It is a useful case to understand responsible disclosure and why the response process is also part of security.

How could it be exploited?

Next.js used an internal header to identify requests that should not pass through certain parts of the middleware again. In vulnerable implementations, a manipulated external request could leverage that mechanism and influence control execution. This does not mean that all Next.js applications exposed data: the practical effect depended on whether the middleware was the only authorization barrier.

Which installations were exposed?

The official analysis confirmed risk in certain self-hosted applications with next start and output: 'standalone'. It ruled out static exports without middleware. It also indicated that the deployment architecture of Vercel, Netlify, and Cloudflare Workers evaluated at the time did not suffer from that bypass. Therefore, when studying a Next.js CVE, the deployment mode is as important as the version.

Which versions received the patch?

The project published fixes for 14.2.25, 15.2.3, and later backported versions 13.5.9 and 12.3.5 in March 2025. These are the first historical fixes: for a new project or an update in 2026, look for a current maintenance version.

What do I do to protect an app?

Update Next.js and verify the deployed artifact; check which endpoints rely exclusively on middleware; verify authorization also in handlers, server actions, and data access; block untrusted internal headers at the edge when the advisory recommends it and the update is not immediate. Controls must decide on the identity and permissions of each sensitive operation.

How do I know if someone exploited the issue?

Compare access to protected routes, unusual patterns in proxy logs, operations performed by users, and absence of authorization checks. Access to a resource does not necessarily mean data leakage, but it may justify an incident review. If there was exposure, rotate credentials and notify according to applicable obligations.

Frequently asked questions

Is the app saved if it uses JWT? A token does not fix a flow that allows bypassing the only authorization control.

Can the VPS provider fix it for me? The framework patch and authorization decisions remain the responsibility of the code and its deployment, according to the contracted service.

Should I stop using middleware? No: use it as an additional layer, not as the sole boundary.

Sources: Next.js official postmortem · CVE Record.

Where to follow CVE alerts and receive guidance?

On ArduMaker CVE and support we publish updates and centralize inquiries about vulnerabilities, starting with WordPress and its related technologies. If your case involves another runtime or a database, specify component, version, operating system, and service exposure to contextualize it. The notice of a CVE does not prove that your server is compromised: evaluation requires inventory, configuration, and evidence.

Editorial note — October 2026: these patched versions are the milestones of the original notice. When updating today, choose a branch with active support and verify the manufacturer's current announcement.

Practical example: two barriers for an administration route

Situation: a Next.js app hides /admin via middleware, but the handler that returns invoices does not check user permissions. CVE-2025-29927 showed why relying on a single barrier is a risk.

In a Route Handler, implement another independent validation:

// Ejemplo ilustrativo: getCurrentUser debe implementarse
// con tu sistema real de sesiones.
export async function GET(request) {
  const user = await getCurrentUser(request);
  if (!user || !user.isAdmin) {
    return new Response("Acceso denegado", { status: 403 });
  }
  return Response.json(await cargarFacturasAutorizadas(user));
}

Before: «if it passed through middleware, then it can see everything». After: middleware for redirection or first check, plus authorization in the route, server action, and data layer as appropriate.

Safe functional test: log in with an account without administrator permissions and request the endpoint normally. The server must return 403 and not deliver the data. Also, update Next.js to the corresponding patch and verify the deployment mode.

CVE-2025-29927 in Next.js: why middleware should not be your only access barrier
  • Next.js
  • CVE-2025-29927
  • Middleware
  • Autorización
  • React

Keep reading

All articles · VPS plans