CVE-2025-29927: the Next.js middleware bypass, who is affected and how to fix it

What CVE-2025-29927 is, in plain words

Next.js middleware is a file, middleware.ts (renamed proxy.ts in Next.js 16), that runs on the server before a page is rendered. Many apps put their login check there: no session cookie, redirect to /login. The Next.js authentication guide shows exactly that pattern, as a quick first filter.

To stop middleware from calling itself in an endless loop, Next.js marked its own internal requests with a header, x-middleware-subrequest. The flaw: Next.js also trusted that header when it came from the internet. A request carrying the right value made Next.js skip middleware and render the page as if the check had passed. No account, no special tool: one HTTP header. Allam Rachid and Allam Yasser reported it on February 27, 2025, and the advisory went public on March 21, 2025.

What a stranger can do with it

The limit matters as much as the risk. The bypass skips middleware and nothing else. If the page, the route handler or your data layer checks the session again, the stranger hits that second check, and database rules such as Supabase row level security still apply. It does not run code on your server either: it is an authorization bypass, not remote code execution like React2Shell.

Severity and exploitation status

The CVSS 3.1 base score is 9.1, critical, with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N: reachable over the network, low complexity, no privileges, no user interaction, high impact on confidentiality and integrity. The score comes from GitHub, the CVE numbering authority (CNA) that published the record. NVD has analyzed the CVE and shows that same score without publishing one of its own. The weakness is improper authorization: CWE-285 for the CNA, CWE-863 for NVD.

Who is affected

Three conditions together: a vulnerable version, a server that runs Next.js itself, and middleware that does the access control.

One detail differs between sources. The CVE record and NVD start the range at 11.1.4, the last 11.x release; GitHub's npm advisory starts at 12.0.0, the release that introduced middleware, and sends 11.x users to the workaround. Either way, an app on 11.1.4 or 12.x needs 12.3.5 or later.

Apps built with AI tools

v0 generates Next.js apps and publishes them on Vercel, which was not exposed; the same code run with next start on your own server is, on a vulnerable version. A project created with create-next-app today starts on Next.js 16, so this CVE mostly concerns older projects and templates pinned to old versions. The v0 security guide covers the rest of a generated Next.js app.

Behind Cloudflare is not the same as on Cloudflare

If your server runs next start and Cloudflare only sits in front of it, requests still reach your vulnerable server. Cloudflare's managed WAF rule for this CVE is opt-in: you turn it on yourself, on the Pro plan and above. Cloudflare switched it off by default on March 22, 2025, after it made requests fail on sites that use auth middleware with third-party auth vendors. On the Free plan, Cloudflare suggests a custom rule, shown below. Akamai's rule also defaults to alert, not block.

How to check your Next.js version

Check the version that is installed, not the range in package.json: "next": "^14.1.0" can still be pinned to 14.1.0 by your lockfile. At the root of the project:

# npm
npm ls next

# pnpm (add -r in a monorepo)
pnpm why next

# yarn
yarn why next

# what the Next.js CLI reports
npx next --version

# package-lock.json
grep -A1 '"node_modules/next"' package-lock.json

# pnpm-lock.yaml
grep -E '^  /?next@' pnpm-lock.yaml

# yarn.lock (Yarn 1 and Yarn Berry)
grep -A1 -E '^"?next@' yarn.lock

Then check what production runs. Open your live site, open the browser console and type next.version. It catches the case where the repository is patched but an old container still serves the traffic.

How to check your live app

A version tells you whether the flaw is present. It does not tell you whether a page depends on middleware alone, which is what turns the flaw into a leak. Two checks answer that.

1. Read each protected page as if middleware did not exist. In app/dashboard/page.tsx, the admin pages, every route handler and every Server Action: is there a session check of its own, such as verifySession(), auth() or getUser(), before data is loaded? If the only check is in middleware.ts, that page is open to this CVE on a vulnerable version, and to the 2026 bypasses on newer ones.
2. Search your access logs for requests carrying x-middleware-subrequest. The default nginx log format only records the referer and user agent headers, so add $http_x_middleware_subrequest to your log_format. On a self-hosted app, that header arriving from the internet is a probe.

Keybrum runs this check against the live app. It finds the pages that send a signed-out visitor to sign-in, or answer 401 or 403, then requests each one again the way CVE-2025-29927 allows, and as a router prefetch. If the page comes back, the finding shows both requests side by side. It sends only GET requests, keeps a redacted excerpt as proof rather than the page, and runs only on apps whose owner proved ownership.

How to fix CVE-2025-29927

Upgrade. The first fixed versions are 15.2.3, 14.2.25, 13.5.9 and 12.3.5, released between March 17 and March 23, 2025. With the fix, Next.js validates the header against a random id it generates itself and strips it when validation fails. A low-severity follow-up, CVE-2025-30218, let that id leak to third-party hosts that middleware fetched; 15.2.4, 14.2.26, 13.5.10 and 12.3.6 close it, and Cloudflare told its customers to install those.

In November 2026, those versions are a floor. Next.js 14 and older are no longer supported, and the middleware bypasses disclosed in 2026 are fixed only on the 15.5 and 16 lines. Move to the current patch of a supported line:

# Next.js 16 (Active LTS), current patch on November 6, 2026
npm install [email protected]

# Next.js 15 (Maintenance LTS, security releases until January 31, 2027)
npm install [email protected]

# the same with pnpm or yarn
pnpm add [email protected]
yarn add [email protected]

Next.js 16 renamed middleware to proxy. npx @next/codemod@canary middleware-to-proxy . renames the file and the function. The lesson of this CVE carries over: proxy is a first filter, not the lock.

If you cannot upgrade today: block the header

The advisory's workaround is to stop external requests carrying x-middleware-subrequest from reaching your Next.js server. You cannot do it in middleware, since middleware is what gets skipped. Do it in the reverse proxy or the firewall in front.

location / {
    # drop the header before the request reaches Next.js
    proxy_set_header x-middleware-subrequest "";

    # repeat the proxy_set_header lines of your server block here
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_pass http://127.0.0.1:3000;
}

example.com {
    reverse_proxy 127.0.0.1:3000 {
        header_up -x-middleware-subrequest
    }
}

On Cloudflare, create a custom WAF rule with the expression (len(http.request.headers["x-middleware-subrequest"]) > 0) and the action Block, or Log first to see what it would catch. On the Pro plan and above, you can turn on the managed rule for this CVE instead.

What to do after upgrading

1. 1

   Confirm production runs the fix

   Redeploy, then type next.version in the console of your live site. On a self-hosted app, make sure the container that serves traffic was rebuilt: an old image keeps the old version running.

2. 2

   Put the real check next to the data

   Keep middleware for the redirect if you like, and add a session check in every page, route handler and Server Action that loads private data. The Next.js authentication guide says Proxy "should not be your only line of defense in protecting your data".

3. 3

   Look back at your logs

   If your app was self-hosted on a vulnerable version, search your logs for the header, as far back as they go. If a page with personal data was reached that way, handle it as a data exposure: find out what was shown, and to whom.

4. 4

   Watch for the next bypass

   Every new kind of request Next.js accepts, such as prefetch URLs and data routes, is one more path a middleware rule can miss. That is how the 2026 advisories below happened. Keep next on the current patch.

// app/dashboard/page.tsx
import { redirect } from 'next/navigation'
import { verifySession } from '@/lib/dal' // reads and verifies the session cookie

export default async function DashboardPage() {
  const session = await verifySession()
  if (!session) redirect('/login')

  // load only this user's rows
  const projects = await getProjects(session.userId)
  return <Dashboard projects={projects} />
}

A session check is half of it. Loading only the rows that belong to that session is the other half, or one signed-in user reads another's data: see IDOR and broken access control.

Related CVEs: the middleware bypass family

CVE-2025-29927 is the best known of a series. Each one finds a request that reaches a page without matching the middleware rule meant to guard it.

Other Next.js CVEs work differently: CVE-2024-34351 is a server-side request forgery in Server Actions, and React2Shell runs code on the server. The Next.js security guide covers the framework as a whole, and vibe coding security risks covers what AI-built apps leak most often.

Timeline