CVE-2026-45109 - Next.js segment-prefetch middleware bypass

Next.js published a High severity follow-up advisory for App Router applications where the earlier segment-prefetch middleware/proxy bypass fix did not cover middleware.ts when built with Turbopack. The affected path can let requests reach App Router resources without the middleware/proxy enforcement that developers expect.

For production systems, the dangerous pattern is middleware as the only guard for authenticated pages, admin routes, tenant workspaces, billing-gated features, connector setup, or agent-control surfaces. The patch is necessary, but the prompt also asks the agent to add route-level regression tests so a future framework or build-mode drift does not reopen the boundary.

When to use it

Use this recipe when a Next.js App Router application relies on middleware or proxy code to protect authenticated pages, admin paths, tenant workspaces, billing features, connector setup, or agent-control surfaces. It supports source-code remediation, middleware coverage review, Turbopack build audit, and evidence that segment-prefetch paths cannot bypass authorization.

Inputs

  • Next.js version, build mode, App Router route tree, middleware.ts/proxy code, auth library configuration, and deployment platform.
  • Source paths for protected routes, middleware matchers, redirects, server components, route handlers, and authorization helpers.
  • Regression fixtures for direct requests, segment-prefetch requests, unauthenticated users, wrong-tenant users, allowed users, and Turbopack builds.
  • Boundary evidence: sensitive routes, cookies/session model, edge/runtime placement, logs, and deployment artifact versions.

Affected versions

Package Vulnerable versions Fixed versions
next >=15.2.0, <15.5.18; >=16.0.0, <16.2.6 15.5.18, 16.2.6

Indicator-of-exposure

  • The repository builds a Next.js App Router application on an affected next version.
  • The application uses middleware.ts or proxy.ts to enforce authentication, authorization, tenant routing, billing, feature gates, or bot/security controls.
  • Turbopack is enabled for development, build, preview, deployment, or CI.
  • Sensitive routes depend on middleware without defense-in-depth checks inside route handlers, server actions, layouts, or data access code.

Quick checks:

rg -n "\"next\"|middleware\\.ts|proxy\\.ts|turbopack|next dev --turbo|next build --turbo|auth\\(|withAuth|matcher|authorized|middleware" .
npm ls next
pnpm why next
yarn why next

Remediation strategy

  • Upgrade next to 15.5.18+ or 16.2.6+ on the application’s current major line.
  • Regenerate lockfiles, package-manager metadata, SBOMs, image metadata, and deployment artifacts.
  • Add regression tests or route probes that prove protected App Router paths deny unauthenticated and lower-privileged callers when segment-prefetch-style requests are used.
  • Move critical authorization checks into server-side handlers or data access boundaries where middleware is currently the only control.
  • If the upgrade cannot deploy immediately, block suspicious segment-prefetch routes for sensitive paths at the gateway or WAF until patched.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-45109 (Next.js App Router segment-prefetch
middleware/proxy bypass follow-up). Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Next.js, proves sensitive
  middleware-gated routes still deny bypass traffic, adds defense-in-depth
  checks where needed, and refreshes generated artifacts, or
- TRIAGE.md if this repository does not own an affected Next.js application or
  cannot make a safe patch.

## Rules

- Scope only CVE-2026-45109, the related CVE-2026-44575 bypass class, and
  directly related route-authorization tests.
- Do not remove middleware, proxy, auth, tenant, billing, or feature-gate
  checks to make tests pass.
- Do not expose cookies, session tokens, JWTs, refresh tokens, tenant IDs,
  provider secrets, or customer data in logs or fixtures.
- Do not depend solely on visual browser tests for authorization.
- Do not auto-merge.

## Steps

1. Inventory every Next.js app, package workspace, Docker image, generated
   deployment artifact, SBOM, and hosting config controlled by this repository.
2. Determine every resolved `next` version. A target is vulnerable if it
   resolves to `>=15.2.0, <15.5.18` or `>=16.0.0, <16.2.6`.
3. Search for `middleware.ts`, `proxy.ts`, `matcher`, auth wrappers, App Router
   route groups, server actions, API routes, and Turbopack usage.
4. Identify sensitive paths that rely on middleware/proxy enforcement:
   authenticated dashboards, admin routes, tenant settings, billing or feature
   gates, connector approval, MCP or agent controls, secrets, data export, and
   workflow promotion.
5. Upgrade `next` to the fixed release for the current major line. Regenerate
   lockfiles, package-manager metadata, SBOMs, container layers, deployment
   render output, and dependency reports.
6. Add regression coverage for each sensitive route class:
   - ordinary unauthenticated request is denied;
   - lower-privileged request is denied;
   - segment-prefetch-style request is denied;
   - Turbopack build or preview path uses the same authorization expectation;
   - route handler, server action, or data access layer still rejects missing
     auth even if middleware is skipped.
7. If a route is protected only by middleware and controls high-impact data or
   agent actions, add defense-in-depth authorization in the server-side handler
   or shared data-access helper.
8. Add a PR body section named `CVE-2026-45109 operator actions` that states:
   - Next.js versions before and after;
   - whether Turbopack is used;
   - which middleware/proxy matchers protect sensitive paths;
   - which regression tests cover bypass-shaped requests;
   - whether any gateway or WAF containment should remain until deployment.
9. Run the relevant validation: package install, lint, typecheck, unit tests,
   route/auth tests, build with the repo's configured bundler, E2E tests,
   container build, SBOM refresh, and dependency/security scans.
10. Use PR title:
    `fix(sec): remediate CVE-2026-45109 in Next.js middleware`.

## Stop conditions

- No controlled Next.js App Router application resolves an affected `next`
  version.
- The project does not use middleware/proxy for security decisions and all
  sensitive server paths already enforce authorization independently.
- The upgrade requires a broader framework migration outside the repository's
  ownership; document the owner, fixed target version, and temporary gateway
  containment.
- Meaningful tests require production sessions, customer data, or live tenant
  tokens.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Next.js, tests segment-prefetch route protection, moves critical authorization into route/server-side checks where needed, and documents rollout.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, protected routes, middleware-only gates, required fix, and residual risk.
  • The output must include exact validation commands and must not probe production tenant/admin routes or expose cookies, tokens, or user data.

Verification - what the reviewer looks for

  • No manifest, lockfile, image, SBOM, or generated deployment artifact resolves a vulnerable next version.
  • Sensitive App Router paths have negative tests for ordinary and bypass-shaped requests.
  • Critical authorization is not enforced only in middleware when a server-side check is practical.
  • Turbopack usage is explicitly covered or ruled out.
  • Generated artifacts and dependency reports were refreshed.

Watch for

  • Updating package.json without updating package-lock.json, pnpm-lock.yaml, yarn.lock, Docker layers, or SBOMs.
  • Middleware matchers that exclude route groups, locale prefixes, trailing slash variants, or internal prefetch paths.
  • Tests that hit the browser UI but never assert HTTP denial for protected server resources.
  • Agent-control or connector routes that rely on middleware while server actions trust caller-provided tenant or role data.

References