CVE-2026-44575: the Next.js middleware bypass through segment-prefetch URLs

What CVE-2026-44575 is, in plain words

Next.js lets you run code before a request reaches a page. The file is middleware.ts, renamed proxy.ts in Next.js 16, where the old name still works but is deprecated. Many apps use it as their login gate: no session cookie, redirect to /login. A matcher in the same file tells Next.js which paths the gate covers, for example everything under /dashboard.

The App Router does not load pages only through their normal URL. To prefetch links and navigate without a full reload, it fetches the page's React Server Components payload (the data the page renders from) through transport-specific URL variants: .rsc URLs and segment-prefetch routes. On affected versions, those variants resolved to the same page but were not matched by the middleware rule written for the page URL. The gate never ran, and the page could render for a visitor with no session.

The fix, as the advisory describes it: Next.js now includes the App Router transport variants when it generates middleware matchers, so the same protection applies to those requests as to the page URL. GitHub files the flaw under CWE-288, authentication bypass using an alternate path or channel. The advisory does not publish the exact URLs and neither do we. You do not need them to check or fix your app.

Severity and exploitation status

GitHub, the CVE numbering authority for Next.js, scores it 7.5, high, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: reachable over the network, low complexity, no account and no user interaction needed. NVD lists GitHub's 7.5 and the same score from Red Hat, and has not added a score of its own.

• Known exploitation: CVE-2026-44575 is not in CISA's Known Exploited Vulnerabilities catalog (version 2026.11.06, checked on November 7, 2026). We found no vendor statement or credible incident report of attacks using it.
• CISA's assessment: on May 13, 2026, CISA added an SSVC rating to the CVE record (Stakeholder-Specific Vulnerability Categorization, a triage scheme): exploitation "none", automatable "yes", technical impact "partial". Automatable means an attacker can run it at scale without manual work, which is the reason not to wait.
• Likelihood: FIRST's EPSS model, which estimates the probability of exploitation in the next 30 days, gave it 1.6% on November 6, 2026, higher than about 76% of scored CVEs.

Who is affected

On those versions, your app is exposed when three things are true:

1. It uses the App Router (an app/ directory). The advisory is about App Router transport variants. A sibling flaw, CVE-2026-44573, covers the Pages Router with i18n.
2. middleware.ts or proxy.ts makes an authorization decision: redirect signed-out visitors, block a role, gate paid content.
3. The page behind it trusts that decision and does not check the session on its own.

Where the app runs does not change the answer. The flaw is in how Next.js builds the middleware matcher, so it ships with your build, on Vercel as on a VPS or a container. Vercel's changelog for the release says it has not deployed new WAF rules, because these advisories cannot be reliably blocked at the WAF layer, and that patching is the only complete mitigation.

How to check your Next.js version

Look at the version that is installed and locked, not the range in package.json: ^16.2.0 can resolve to 16.2.4 or to 16.4.5 depending on when the lockfile was written.

# installed version
npm ls next
pnpm why next        # add -r in a monorepo
yarn why next

# what the lockfile pins (your host installs this)
grep -A1 '"node_modules/next"' package-lock.json
grep -E '^  /?next@' pnpm-lock.yaml
grep -A1 -E '^"?next@' yarn.lock

Then check the two details that decide whether the first fix was enough:

# which gate file do you have? middleware.* or proxy.*
ls middleware.* proxy.* src/middleware.* src/proxy.* 2>/dev/null

# does your build use Turbopack? On 16.x it does unless the script says --webpack
grep '"build"' package.json

How to check whether a page would leak

Your version tells you the flaw is there. Whether a page leaks depends on what that page checks for itself. From outside, the bypass shows as a protected page that redirects a signed-out visitor at its normal URL but returns its content through one of the App Router's transport URL forms. You do not need those URLs to find your exposed pages, because your code tells you: list the paths your matcher covers, then open each page under them and look for a server-side session check that runs before any private data loads.

# the paths your gate covers
grep -n -A10 'matcher' middleware.* proxy.* src/middleware.* src/proxy.* 2>/dev/null

# pages under a protected folder that never mention a session check
# (change app/dashboard and the names to match your app and auth library)
find app/dashboard -name 'page.*' -exec grep -L -E 'getSession|getServerSession|auth\(|currentUser|verifySession' {} +

Keybrum's live attacks cover the neighbours of this CVE on pages behind a sign-in, on apps whose owner proved ownership. web.nextjs-middleware-bypass finds the pages that send a signed-out visitor to sign-in or answer 401 or 403, from common paths and from paths named in your JavaScript, then requests each one again with the internal header of CVE-2025-29927 and as an App Router prefetch request. Only a 200 that carries the page and is not a login form counts as proof, and the finding shows both requests side by side. web.middleware-path-bypass tries the path variants a matcher can miss, such as a double slash, an encoded letter or a case change. Both send GET requests only and keep a redacted text excerpt, never the page. Neither sends the .rsc and segment-prefetch URL forms named in this advisory, so for CVE-2026-44575 itself, rely on the version and the code check above.

How to fix CVE-2026-44575

1. 1

   Upgrade past both advisories

   The floor is 16.2.6 or 15.5.18. Go to the current patch instead: 16.4.5 on Next.js 16 (Active LTS) or 15.5.29 on Next.js 15, published on November 3, 2026. Releases since May fixed more middleware bypasses, such as CVE-2026-64642 in 16.2.11, along with other flaws. Next.js publishes security releases for 15 until January 31, 2027.

2. 2

   Rebuild and redeploy

   The fix changes how matchers are generated, which happens when Next.js builds your app. Commit the new lockfile, let your host build from it, and confirm that production runs the new version.

3. 3

   On 13.x or 14.x, plan the major upgrade

   This CVE does not reach those lines, but Vercel lists every 13.x and 14.x version as affected by other advisories in the same release and points to 15.5.18 or 16.2.6. Read the Next.js upgrade guides before you jump a major version.

# Next.js 16
npm install [email protected]
pnpm add [email protected]
yarn add [email protected]

# Next.js 15
npm install [email protected]

If you cannot upgrade today

The advisory's workaround is to enforce authorization in the underlying route or page logic instead of relying on middleware alone. In practice, every page that renders private data reads and verifies the session on the server before it loads anything:

// app/billing/page.tsx
import { redirect } from 'next/navigation'
import { getSession } from '@/lib/session' // verifies the session cookie on the server
import { listInvoices } from '@/lib/invoices'
import { InvoiceTable } from './invoice-table'

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

  // fetch only the rows of the signed-in user
  const invoices = await listInvoices(session.userId)
  return <InvoiceTable invoices={invoices} />
}

Put the check in the page, not only in layout.tsx. The Next.js authentication guide warns that a layout does not control whether the rest of the route renders: route segments are rendered by the router, so a layout that hides them does not stop them from running or from appearing in the RSC payload. Segment prefetches request parts of a route on their own, so the check belongs in the page and in the code that loads the data.

What to check after upgrading

• Production runs 16.2.6, 15.5.18 or later, in every app of the monorepo, and the lockfile in the repository says the same.
• Every page that shows private data checks the session itself. A check in a layout or in middleware does not count.
• Every route handler and Server Action checks the session and that the record belongs to the caller. A missing owner check is an IDOR vulnerability, and no Next.js upgrade fixes it.
• Static pages gated only by middleware, such as paid articles, are either rendered per request with a check or moved behind an API that checks.
• After the deploy, the code check above lists no protected page that relies on middleware alone, and a signed-out visit to each protected page still ends at the sign-in page.

Middleware still has a job. The Next.js guide calls checks in Proxy "optimistic": read the cookie, redirect early, keep database calls out because Proxy runs on every route, prefetches included. The real decision belongs next to the data. Our Next.js security guide covers that pattern and the other settings that matter, and the vibe coding security risks guide explains why generated apps so often put the only check in middleware.

Related CVEs: the 2026 middleware and proxy bypasses

Six advisories since March 2025 point the same way: a pattern match on the URL is a weak place for the only lock. For the bigger risk on the same Next.js lines, read React2Shell, CVE-2025-55182, which let a stranger run code on App Router servers and has been in CISA's catalog of exploited vulnerabilities since December 5, 2025.

Timeline