Next.js middleware bypass: CVE-2026-44575 explained

The flaw

Next.js middleware (renamed proxy in recent versions) runs before the page renders. Many teams put access control there:

```typescript

// middleware.ts

export function middleware(request: NextRequest) {

const token = request.cookies.get('session')

if (!token) {

return NextResponse.redirect(new URL('/login', request.url))

}

}

export const config = { matcher: ['/dashboard/:path*'] }

`

This protects /dashboard. But the App Router does not serve a page through a single URL. For client-side navigation and prefetching it uses transport variants: requests to .rsc-suffixed URLs or segment-prefetch URLs that return serialized Server Component output. According to the GitHub advisory, specially crafted .rsc and segment-prefetch URLs resolve to the same page without matching the middleware rule. The check never runs and the protected content comes back.

• Identifiers: CVE-2026-44575, GHSA-267c-6grr-h53f, classified CWE-288 (authentication bypass using an alternate path).
• Severity: high, CVSS 7.5, confidentiality impact.
• Affected versions: 15.2.0 to 15.5.15, 16.0.0 to 16.2.4.
• Fixed versions: 15.5.16 and 16.2.5. The fix extends middleware matchers to App Router transport variants.
• Incomplete fix: a follow-up advisory (GHSA-26hh-7cqf-hhc6) handles a residual bypass. The reference versions for the May batch are 15.5.18 and 16.2.6, and Next.js 13.x and 14.x must move to one of them.

The other three bypasses in the same batch

The same May 2026 release lists three more high-severity advisories targeting apps that use middleware.js or proxy.js for authorization:

1. the segment-prefetch bypass follow-up to the incomplete fix;
2. in the Pages Router with i18n, the default-locale path bypasses proxy authorization: the unprefixed data route returns the SSR JSON of a protected page;
3. a bypass through dynamic route parameter injection.

Vercel states that no WAF rule blocks these reliably: only the upgrade fixes them.

Why this pattern keeps coming back

This is not the first middleware bypass. In 2025, CVE-2025-29927 already let attackers skip middleware with a single header. The root problem is unchanged: middleware reasons about a URL, while the framework can serve the same resource through several paths (locale prefixes, JSON data routes, RSC payloads, prefetch). Every new path is another chance to miss the rule.

How to test it

On your own application, ideally in staging:

1. Version: npm ls next shows the version actually installed. Anything below 15.5.18 or 16.2.6 needs an upgrade.
2. Inventory: list the routes whose protection relies only on middleware.ts or proxy.ts. Those are the ones that matter.
3. Baseline request: without a session cookie, curl -i https://app.example.com/dashboard should return a redirect to /login.
4. Transport variants: replay the request without a session, adding the RSC: 1 header, then against the page's .rsc variant, then in prefetch mode (Next-Router-Prefetch: 1). If you get a 200 with data from the protected page instead of a redirect or a 401, the page is reachable without a check.
5. Pages Router and i18n: if you use i18n, test the data route /_next/data/<buildId>/<page>.json with and without a locale prefix.
6. Server-side check: for each sensitive page, confirm that a request without a session still fails when middleware is disabled locally. If it succeeds, middleware is your only barrier.

How to fix it

Right now

Upgrade to 15.5.18 or 16.2.6 (or later) and redeploy. Older 15.x and 16.x minors do not get backports.

For good

Keep middleware for redirects and convenience, but enforce authorization close to the data:

• in every Server Component or layout that reads sensitive data (read the session server-side);
• in every Route Handler and Server Action, as covered in our article on Server Components security mistakes;
• in the database itself, with RLS policies if you use Supabase or PostgreSQL.

That way, the next published middleware bypass will only open an empty page.

How does the Next.js middleware bypass CVE-2026-44575 change the picture for an AI agent?

Many internal agents call the company's application over HTTP: a fetch_page tool or an MCP server that reads the dashboard, invoices or customer records. If the agent's access is filtered by the same middleware, two risks appear. First, an agent that builds its own URLs can, under a prompt injection, request an .rsc variant that slips past the filter and pull data outside its scope. Second, the serialized RSC response often carries more fields than the rendered page, and the agent will read them and may copy them elsewhere. Protection must apply server-side and check the agent's identity on every route.

If you expose a Next.js application to an agent, our Agent Red Team Express tests in five days what that agent can reach beyond what you intended.