Sentry Next.js Middleware Bypass (Fix It)

If your Next.js site uses @sentry/nextjs with the tunnelRoute option, update the package now: a critical bug (CVE-2026-114139) let certain requests skip your middleware entirely.

This post is for developers and site owners who run Sentry's error tracking on a Next.js app, and for anyone who got a dependency alert mentioning @sentry/nextjs or GHSA-mchm-gjx6-7h55 this week. You'll learn what the bug actually does, whether your setup is in the affected range, and the exact command to fix it today.

What the advisory actually says

The flaw is tracked as GHSA-mchm-gjx6-7h55 (CVE-2026-114139) in the GitHub Advisory Database, published October 22, 2026, and rated critical. The short name is "Middleware Bypass when using Tunnel route," and it affects the @sentry/nextjs package, the official Sentry SDK for Next.js apps.

Here's the feature that's involved. Sentry's browser SDK normally sends error and performance data straight to Sentry's servers. Ad blockers and privacy tools often block that traffic because the request goes to a third-party domain. To get around this, Sentry offers a tunnelRoute option: instead of calling Sentry directly, the browser sends the event to a path on your own domain (commonly /monitoring), and a rewrite rule in your Next.js app quietly forwards it on to Sentry. Since the request never leaves your domain, ad blockers let it through.

To make that forwarding work smoothly, the SDK also tells Next.js middleware to skip processing for requests to that tunnel path, since middleware could otherwise reject or redirect them before they reach the rewrite.

Where the bug actually is

The problem, according to the advisory, is that the middleware skip was broader than the rewrite it was meant to support. The rewrite only handles requests to the exact tunnel path with Sentry's own o and p query parameters attached. The skip, however, applied to anything under that tunnel path, parameters or not.

That mismatch creates a gap: a request that looks like it's under your tunnel path, but doesn't match the specific pattern the rewrite expects, isn't forwarded to Sentry. It's handled by your own application instead, and your middleware never ran on it to check it first.

That matters because a lot of teams put real security logic in Next.js middleware, things like:

• Checking login sessions or auth tokens
• Blocking access to admin routes
• Enforcing rate limits
• Redirecting based on geography or feature flags

The advisory is careful to note that skipping middleware doesn't hand an attacker any special privileges by itself. The risk depends entirely on what your middleware does and which routes happen to sit "under" your tunnel path in your app's routing. If your middleware is your only gate in front of an authenticated route, and that route's path overlaps with the tunnel path pattern, a request crafted to look like Sentry traffic could reach your app logic without passing that gate.

Who is affected

You're only exposed if both of these are true:

1. Your @sentry/nextjs version falls in one of the ranges above.
2. You've configured tunnelRoute in your Sentry setup. It's set as the tunnelRoute option inside the withSentryConfig(nextConfig, sentryWebpackPluginOptions) call in next.config.js, not in sentry.client.config.js/ts.

If you never set tunnelRoute, this specific bypass path doesn't apply to your app, though you should still update, since Sentry SDK releases bundle other fixes too.

How to check your own site

1. Check your installed version. Run npm ls @sentry/nextjs (or pnpm why @sentry/nextjs / yarn why @sentry/nextjs) and compare the result against the table above.
2. Search your config for tunnelRoute. Run grep -r "tunnelRoute" . from your project root. It's set as the tunnelRoute option inside the withSentryConfig(nextConfig, sentryWebpackPluginOptions) call in next.config.js, not via Sentry.init() in sentry.client.config.js/ts.
3. Check what your middleware protects. Open middleware.ts (or .js) and look at the matcher config or path logic. If it gates authentication, admin access, or rate limiting on paths that could overlap with your tunnel path (for example, if your tunnel path is /monitoring and you also have routes nested under /monitoring/*), treat this as urgent.
4. If you're unsure how your middleware and routing interact, that's exactly the kind of gap a manual review is built to catch. It's a good moment to run a free passive security check on your site, or if you want a person to actually read your middleware logic and routing, our guide to manual vs. automated penetration testing explains why automated scanners typically miss this class of logic bug entirely.

How to fix it

Update to a patched version that matches your current major version line:

# If you're on the 9.x line
npm install @sentry/nextjs@9.47.2

# If you're on the 10.x line
npm install @sentry/nextjs@10.75.2

# If you're on an 11.x prerelease
npm install @sentry/nextjs@11.0.0-rc.1

Or simply pull the latest release in your major version and verify it's at or above the patched version shown in the table:

npm install @sentry/nextjs@latest
npm ls @sentry/nextjs

After updating:

• Redeploy your app so the new middleware behavior actually ships to production.
• Re-check your tunnelRoute config still works by confirming error events still arrive in your Sentry project (send a test error).
• If your middleware handles authentication or admin gating, it's worth a quick manual pass to confirm no routes sit inside your tunnel path's namespace by accident. Renaming the tunnel path to something that doesn't overlap with any real route (for example /monitoring-tunnel instead of /monitoring) is a cheap extra layer of safety even after you patch.

If you can't update right away

Sometimes a dependency bump has to wait for a sprint, a review, or a freeze window. In the meantime:

• Move any sensitive authorization logic out of middleware and into the route handler itself, so it runs regardless of what middleware does or doesn't see.
• Double check nothing sensitive lives at a path nested under your tunnelRoute value.
• Set a firm date to apply the patch. This is rated critical for a reason, and "later" has a way of becoming "never" with dependency patches.

If you want a second set of eyes on whether your specific routing setup is actually exploitable (not just theoretically in range), that's a logic question, not something a vulnerability scanner can answer on its own. Our guide on telling whether your site is hackable walks through how to reason about that kind of question yourself, and checking your security headers is a good complementary step while you're in there.

Key takeaways

• A critical bug in @sentry/nextjs (CVE-2026-114139, GHSA-mchm-gjx6-7h55) let some requests under a Sentry tunnelRoute path skip Next.js middleware entirely.
• You're only affected if you use tunnelRoute AND run a vulnerable version: 9.36.0 up to 9.47.2, 10.0.0-alpha.0 up to 10.75.2, or 11.0.0-alpha.0 up to 11.0.0-rc.1.
• Fix it by updating @sentry/nextjs to 9.47.2, 10.75.2, or 11.0.0-rc.1 (or later) and redeploying.
• The real risk depends on what your middleware protects, so review your auth and admin logic even after you patch.
• If your middleware setup is complex or you inherited it from a previous developer, a one-time manual security audit is a straightforward way to confirm nothing else is quietly exposed.

Patching this one bug is the easy part. The harder question, "what else in my app could middleware be silently not protecting?", is exactly what a human actually reading your code is for. A Circuit audit is $49, one time, and gives you a full written report of what's actually exposed on your live site, not just this one CVE.