Sentry's September 2026 Next.js Flaw Explained: Why Middleware-Only Auth Fails

If middleware is your only login check, anything that stops it running makes your private pages public. That is what the @sentry/nextjs vulnerability did for some Next.js apps between 2025 and September 2026. Middleware, the code Next.js runs before a request reaches a page, was quietly skipped.

Picture a common setup. A Next.js app serves English and Hindi pages from a folder named app/[locale], so addresses look like /en/account and /hi/account. A middleware file checks the login cookie and returns 401 Unauthorised when it is missing. The setup is made up, but the code path is real, and we ran it.

The team also uses Sentry, an error-monitoring service, and turns on its tunnelRoute option with the path /monitoring. Many ad blockers drop requests to Sentry's servers. The tunnel sends browser error reports to the app's own server first, which then forwards them to Sentry.

Now someone with no cookie opens /monitoring/account. Next.js reads monitoring as the locale, finds the account page and renders it. On an affected webpack build, the middleware never runs, so the private page comes back with status 200.

You need five terms. Each one comes with the part of the running example it maps to.

• Middleware: a function in middleware.ts that Next.js runs before routing each request. Next.js 16 renames the file to proxy.ts and deprecates the old name. In our example it checks the login cookie.
• Tunnel route: a path on your own site, here /monitoring, that receives Sentry error reports from the browser. Sentry's tunnelRoute option sets it up for you.
• Rewrite: a Next.js rule that serves one address from another without changing the browser's address bar. Sentry adds a rewrite that forwards tunnel requests to its ingest servers.
• Dynamic segment: a folder name in square brackets, like [locale], that matches any one part of a path. So /monitoring/account matches app/[locale]/account.
• Bundler: the tool that packs your code for production. Next.js can use webpack, the older default, or Turbopack, the default for next build since Next.js 16.

It is a protection failure in Sentry's Next.js SDK, the library you install to send errors to Sentry. The advisory is GHSA-mchm-gjx6-7h55, and its CVE number is CVE-2026-114139. The weakness class is CWE-693, which means a protection mechanism failed.

With tunnelRoute set, the SDK told Next.js to skip your middleware for any path under the tunnel path. But Sentry's rewrite only forwards one exact request shape. Everything else under that path fell through to your normal pages, with middleware switched off.

The advisory states the limits clearly. Skipping middleware grants no extra privileges, and routes that check the session on the server stay protected. Sentry's own services and the data in your Sentry organisation are not affected.

The severity label depends on where you look. The GitHub Advisory Database and NVD show Critical, CVSS 4.0 score 9.1. Sentry's own advisory page shows Moderate and no CVE, as of 28 October 2026.

CVSS is the common 0 to 10 severity score. This vector includes AT:P, meaning attack requirements are present. In plain words, your app must match the four conditions before anyone can use the bug. Judge your risk on those conditions, not on the headline number.

Two pieces of Sentry code described the tunnel differently. The rewrite was narrow, and the middleware skip was wide. Requests that fit the wide rule but not the narrow one went to your pages without any middleware check.

The narrow rule: Sentry's rewrite

The rewrite lives in config/withSentryConfig/tunnel.js in the npm package. Its source pattern is the tunnel path with an optional trailing slash. It also needs query parameters o and p, short for organisation ID and project ID, holding digits.

So only a request like /monitoring?o=123&p=456 gets forwarded to Sentry. A request for /monitoring/account does not match, so Next.js routes it like any other address.

The wide rule: the middleware skip

On webpack builds, the SDK wraps your middleware file automatically. Before your code runs, the wrapper checks whether the address is a tunnel request. If yes, it returns an empty response with the header x-middleware-next set to 1.

That header is what Next.js's own NextResponse.next() sends. It means "carry on routing". Your middleware function is never called, so its cookie check never happens.

In 10.75.1 the test is pathname equals the tunnel path or starts with the tunnel path plus a slash. Versions 9.36.0 to 9.47.1 and 10.0.0 to 10.50.0 were wider still. They used a plain startsWith check, so even /monitoringx/account was skipped.

Think of a housing society gate. The courier desk accepts parcels only for the office in Block A, room 1. The gate guard has a note saying anyone heading to Block A may skip the ID check.

The courier desk is the rewrite, and the guard's note is the middleware skip. Room 1 is the exact tunnel request, and the rest of Block A is every page under the tunnel path. Visitors for other rooms walk past the guard unchecked.

Where the picture breaks: a real guard might notice someone odd, but code checks only the rule it was given. And here the gap needed one more piece, a page that answers under that path.

A dynamic segment at the root matches any first path segment, including your tunnel path. So /monitoring/account, /errors/account and /anything/account all reach app/[locale]/account.

The advisory names this case directly. A direct clash, like a real /monitoring/foo page, is easy to spot in code review. A root [locale] or [slug] folder is not, because no file mentions the word monitoring.

We checked whether renaming the tunnel helps. With 10.75.1 on a webpack build, we changed tunnelRoute to /sentry-tunnel-x9. A request for /sentry-tunnel-x9/account still returned 200 and the private page.

Setting tunnelRoute to true does not help either. The SDK then picks a random eight-character path for each build. That path has to reach the browser, and we found it in the public JavaScript files under .next/static. Our random path, /9dtlft0p, also served the private page.

Because the SDK only wraps your middleware automatically through a webpack loader, a plug-in step that rewrites files during a webpack build. The Turbopack setup in the same package has no middleware wrapping at all.

We confirmed this in the build output. In the Turbopack build, the middleware chunk held our plain cookie-checking function. All three test addresses returned 401 on 10.75.1 and on 10.75.2.

There is one exception the advisory does not mention. The SDK also exports wrapMiddlewareWithSentry, so you can wrap middleware by hand. We did that on a Turbopack build with 10.75.1, and /monitoring/account returned 200 and the private page.

With 10.75.2, the same hand-wrapped Turbopack build returned 401. So if your middleware file calls wrapMiddlewareWithSentry, treat your app as affected on any bundler until you upgrade.

Sentry's build options page points the same way. It says that on Turbopack, your middleware can block the tunnel, and you should exclude the tunnel path with a negative matcher. It adds that without Turbopack, Sentry skips the tunnel route automatically. That automatic skip is exactly the code that was too wide.

Check which bundler built your app in the first line of next build output. On Next.js 16.4.3 it prints "Next.js 16.4.3 (Turbopack)" by default, or "(webpack)" when you pass --webpack. On older Next.js versions, assume webpack unless the log says Turbopack.

The fix makes the middleware skip match only what the rewrite really forwards. The new function, isSentryTunnelRequest in common/utils/tunnelPathnameMatch.js, checks three things before skipping your middleware.

• The method is POST. The SDK's transport only ever sends POST requests.
• The path is exactly the tunnel path, with or without one trailing slash. Nothing under it counts.
• Every value of the o and p query parameters is present and made only of digits.

The third rule handles repeated parameters. A comment in the source says Next.js checks only the last value of a repeated parameter. So the fix demands that every value qualifies, not just one.

The same function shipped in 9.47.2 and 11.0.0-rc.1. The pull requests are 24499 for the main branch, 24565 for v10 and 24760 for v9. On v9 and v10, no configuration change is needed after you upgrade.

The fixed version still lets real error reports through. We pointed the tunnel at a local stand-in server instead of Sentry. A POST to /monitoring?o=1&p=2 with no cookie reached the stand-in, while GET requests and /monitoring/account got 401.

Work through five checks in order. If any one rules you out, this bug does not reach your app, though upgrading is still the simple choice.

1. 1

   Find your SDK version

   Run npm ls @sentry/nextjs in the project folder. Compare the version with the table above. Lock files can pin an old version even when package.json allows a newer one.

2. 2

   Look for tunnelRoute

   Open next.config.js or next.config.mjs and search for tunnelRoute inside withSentryConfig. A string path or the value true both count.

3. 3

   Check the bundler

   Read the first line of your production build log. It names Turbopack or webpack in brackets. Webpack builds are affected, and so is any build whose middleware calls wrapMiddlewareWithSentry.

4. 4

   Look for routes under the tunnel path

   List folders under app and pages. A folder with the tunnel name, or a root folder in square brackets, means a route resolves under the tunnel path.

5. 5

   Find where login is enforced

   If pages, route handlers and data functions check the session themselves, the skip grants nothing. If only middleware checks it, you are exposed.

Then test it on a staging copy of your own app. Request a private page under the tunnel path with no cookie, for example curl -s -o /dev/null -w '%{http_code}' https://staging.example.com/monitoring/account.

A safe build prints 401, 403 or a redirect code such as 307 from your middleware. An affected build prints 200 and returns the private page. Only run this against apps you own.

Upgrade first, then fix the habit that made the bug dangerous. Both steps are small.

1. 1

   Upgrade the SDK

   Install 9.47.2 if you are on v9 or 10.75.2 or later on v10. Moving to 11.x also fixes it, but read the next section first. Rebuild and redeploy, because the wrapper is added at build time.

2. 2

   Re-run the curl check

   Repeat the request for a private page under the tunnel path. Expect 401, 403 or your login redirect, not 200.

3. 3

   If you cannot upgrade today, pick a workaround

   Remove tunnelRoute, or switch the build to Turbopack without a hand wrap and add the exact tunnel check shown in the next section. Renaming the tunnel path helps only if no route resolves under it.

4. 4

   Add a session check next to the data

   Put a session check in each private page, route handler and server action, ideally through one shared function. This protects you from the next middleware bypass too.

Version 11.0.0 removed the middleware skip entirely. Pull request 24589 calls keeping the old skip in sync with the rewrite fragile. It also notes that Turbopack never had it, so the two bundlers behaved differently.

Tunnel requests now pass through your middleware on both bundlers. So if your middleware blocks every visitor without a session, it now blocks Sentry error reports too. On 11.9.0 with our original middleware, a real tunnel POST got 401.

The pull request tells you to exclude the tunnel route from your middleware matcher, using a fixed string path. It adds that tunnelRoute set to true cannot be used for this, because the path is random. Sentry's build options page suggests a negative matcher such as (?!error-monitoring).

In our test app, it left the same gap, now in your own config rather than in Sentry's code. With the matcher skipping paths that start with monitoring, /monitoring/account and /monitoringx/account both returned 200 and the private page.

This is not specific to version 11. The same matcher on 10.75.2 with a Turbopack build gave the same result. It only matters when a page resolves under the excluded prefix and middleware is its only login check.

Anchoring the pattern to the exact path is not enough either. With (?!monitoring$), GET /monitoring still skipped the middleware and returned app/[locale]/page.tsx, our private locale home page. Test any matcher change on your own staging app with the curl check above.

A safer pattern keeps the matcher broad and lets through only the exact tunnel request inside the middleware. It copies the three checks of the 10.75.2 fix. This is the file we ran on 11.9.0, with both a webpack and a Turbopack build:

import { NextResponse, type NextRequest } from "next/server";

const TUNNEL = "/monitoring";

// Let through only what Sentry's tunnel rewrite forwards:
// POST to the exact tunnel path, with numeric o and p query values.
function isTunnelRequest(req: NextRequest) {
  const { pathname, searchParams } = req.nextUrl;
  if (req.method !== "POST") return false;
  if (pathname !== TUNNEL && pathname !== TUNNEL + "/") return false;
  return ["o", "p"].every((key) => {
    const values = searchParams.getAll(key);
    return values.length > 0 && values.every((v) => /^\d+$/.test(v));
  });
}

export function middleware(req: NextRequest) {
  if (isTunnelRequest(req)) return NextResponse.next();
  if (req.cookies.get("session")?.value !== "ok") {
    return new NextResponse("blocked by middleware", { status: 401 });
  }
  return NextResponse.next();
}

export const config = { matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"] };

With this file, a POST to /monitoring?o=1&p=2 reached our local stand-in for Sentry. A POST to /monitoring with no o and p, and GET /monitoring/account, returned 401. The o and p check matters: without it, that bare POST rendered our private locale home page.

The 11.0.0 release notes also move withSentryConfig to the import path @sentry/nextjs/config.

Because middleware is a filter in front of your pages, and filters can be bypassed by rules you do not control. A library, a matcher pattern or a framework bug can stop it running.

This has happened before. In March 2025, CVE-2025-29927 let attackers skip Next.js middleware itself, with a CVSS 3.1 score of 9.1. Fixes shipped in Next.js 12.3.5, 13.5.9, 14.2.25 and 15.2.3.

The Next.js authentication guide, last updated 16 September 2026, gives the same advice. It says Proxy should not be your only line of defense. It recommends doing most security checks as close as possible to your data source.

The guide also warns against relying on layouts for auth checks. Layouts do not re-render on every navigation, and they do not stop nested segments from running. So prefer the page, the route handler or a data access layer, a small module that every data read goes through.

Here is the page-level check from our test app. It is a toy: it compares a cookie to a fixed value. A real app would verify a signed session instead.

import { cookies } from "next/headers";
export const dynamic = "force-dynamic";

// Same page, but the page itself checks the session (auth next to the data).
export default async function Page() {
  const session = (await cookies()).get("session")?.value;
  if (session !== "ok") return <p>PAGE-CHECK-REFUSED</p>;
  return <p>PRIVATE-BILLING-PAGE</p>;
}

We placed this file at app/[locale]/billing/page.tsx on the affected 10.75.1 webpack build. GET /monitoring/billing skipped the middleware and still returned PAGE-CHECK-REFUSED. With the cookie set, /en/billing showed the private text.

Keep middleware for fast redirects and for static pages that cannot check per request. Just do not let it be the only thing between a visitor and private data.

Use it as a story about defence in depth, meaning several independent checks, each able to stop an attack alone. Interviewers care less about the CVE number than about the design lesson.

1. 1

   State the setup

   A Next.js app guarded private pages with middleware only. Sentry's tunnelRoute relayed error reports through the app's own server to avoid ad blockers.

2. 2

   Name the gap

   The SDK skipped middleware for every path under the tunnel, but its rewrite forwarded only one exact request. The difference reached normal pages unguarded.

3. 3

   Explain the trigger

   A root dynamic segment like [locale] matched the tunnel name as a locale. So /monitoring/account rendered the account page without a login check.

4. 4

   Give the fix

   Versions 9.47.2 and 10.75.2 skip only POST requests to the exact tunnel path with numeric o and p values. Version 11 drops the skip, so the app must allow that exact request itself.

5. 5

   Draw the lesson

   Keep allow-lists exactly as narrow as the thing they allow, and test both. Put authorisation next to the data so one skipped layer does not expose it.