Sentry's Next.js SDK Tunnel Route Could Let Requests Skip Middleware Auth Checks

What happened

Sentry disclosed a vulnerability (CVE-2026-114139, GHSA-mchm-gjx6-7h55) in the @sentry/nextjs SDK affecting its tunnelRoute feature. tunnelRoute routes browser-sent Sentry events through a path on the developer's own Next.js server (e.g. /monitoring) so ad blockers don't block them, and the SDK skips middleware execution for those requests so they aren't rejected before reaching the rewrite.

According to Sentry's advisory, the skip logic was broader than the rewrite it was meant to support. The rewrite only forwards requests to the exact tunnel path with specific o/p parameters, but the middleware skip applied to anything under that path. Requests falling in that gap — for example a route like /monitoring/foo, or any app using a dynamic root segment such as app/[locale]/… that happens to match the tunnel path — would reach the application with middleware never having run.

Why it matters for defenders

Per the advisory, this does not grant requests any special privileges on its own — routes that enforce authorization server-side (in the route, layout, or data layer) remain protected. The risk is specifically for applications that rely on middleware as the sole place authorization is enforced for routes that collide with the tunnel path. Sentry states all of the following must be true to be affected: tunnelRoute is configured, the app is built with webpack (Turbopack builds are not affected), some route resolves under the tunnel path, and middleware is the only authorization check for those routes. Exploit proof-of-concept status is listed as public, so organizations meeting this profile should treat it as actionable now. Sentry's own backend and organization data are explicitly not affected.

What defenders should do now

• Check whether your Next.js app sets tunnelRoute and, if so, whether it's built with webpack rather than Turbopack.
• Review whether any application route — especially dynamic root segments like app/[locale]/… — could resolve under your configured tunnel path.
• Confirm authorization isn't enforced exclusively in middleware for sensitive routes; add checks at the route/layout/data-access level as defense in depth.
• As an immediate mitigation, set tunnelRoute to a path no application route can resolve under, or remove the option entirely if ad-blocker evasion isn't required.
• Upgrade to the patched releases: 9.47.2, 10.75.2, or 11.0.0-rc.1, which narrow the middleware skip to only the requests the tunnel rewrite actually serves — no config change needed after upgrading.

Developing intel

This is net-new vulnerability intel published today and based solely on Sentry's own advisory; no CVSS score has been assigned yet and exploitation reports are limited to proof-of-concept availability. Check back for updates as more detail emerges, and see the original advisory for full technical detail: GHSA-mchm-gjx6-7h55.