CVE-2026-114139: critical middleware bypass in Sentry for Next.js

CVE-2026-114139: critical middleware bypass in Sentry for Next.js

In short

A critical vulnerability, identified as CVE-2026-114139, with a CVSS score of 9.1 out of 10 [1], was disclosed on October 21, 2026 [1]. It affects Sentry-Javascript, the official set of Sentry SDKs, specifically the @sentry/nextjs integration when a Next.js application uses the "tunnel" feature to report errors and is built with webpack [1]. In that scenario, an unauthenticated request can bypass the application's middleware and access routes it should protect [1]. If your company has Next.js applications with Sentry configured, the priority today is to check the installed version of @sentry/nextjs and update to a fixed version as soon as possible.

What it is and why it matters

Many Next.js applications integrate Sentry to monitor errors in production. To prevent ad blockers or browser extensions from cutting off that traffic, Sentry offers a feature called "tunnel," which redirects error reports through the application's own domain via a configurable route (tunnelRoute) [1].

The problem lies in how the webpack integration of @sentry/nextjs implements this mechanism in the affected versions: the tunnel rewriter should only serve the exact tunnel route when valid "o" and "p" parameters arrive, but the application's middleware is skipped for any route located under the configured tunnelRoute [1]. If one of the application's own routes matches that tunnel route, or if a dynamic segment at the site root resolves below it, an unauthenticated request can reach that route without going through the middleware's authorization check [1]. Exploitation therefore requires having tunnelRoute configured, a build using webpack, a route that collides with the tunnel, and middleware being the only authorization control for that route [1].

OCIRIA's intelligence radar summarizes the risk directly: this vulnerability "allows bypassing the security middleware in @sentry/nextjs when the Tunnel route is used" and, as a result, "affects Next.js applications that use Sentry for monitoring, allowing critical security controls to be bypassed" [2]. OCIRIA classifies it within the privilege escalation category [2], in line with the critical severity also assigned by NVD [1].

Who is affected

It affects Next.js applications that use the @sentry/nextjs package in versions ranging between 9.36.0 and, respectively, 9.47.2, 10.75.2 and 11.0.0-rc.1 (versions prior to the fixes) [1]. Not every Sentry installation in Next.js is exposed: according to the official description, it is necessary to have the tunnelRoute option configured, build with webpack (not other bundlers), and have an application route that collides with that tunnel route, relying solely on middleware for its protection [1]. Product, development, and security teams at companies that use Next.js with Sentry for observability should review their configuration, regardless of the organization's size.

How to know if you are vulnerable

1. Check the project's package.json or lockfile and confirm the installed version of @sentry/nextjs; compare it against the affected ranges indicated above [1].

2. Check whether your Sentry configuration has a tunnelRoute defined and whether the project is built with webpack.

3. Identify whether any route in your application (including dynamic segments at the root) could match the route configured as the tunnel.

4. Verify whether authorization for those routes depends exclusively on Next.js middleware, without an additional check in the handler itself or on the server.

5. In addition to this internal review, it's worth checking what surface of your application is visible from the outside, to detect routes or endpoints exposed that you did not expect.

How to protect yourself

• Update @sentry/nextjs to one of the fixed versions: 9.47.2, 10.75.2 or 11.0.0-rc.1, depending on the branch you use [1]. OCIRIA's own radar recommends "updating @sentry/nextjs to the patched version immediately" [2].
• Don't leave authorization of sensitive routes solely in the hands of middleware: also add access checks within the handler or server component itself, as defense in depth.
• Review whether you really need the tunnel feature active in production; if you don't use it, disabling it reduces the attack surface of this issue.
• Audit access logs for unusual requests to routes matching your configured tunnelRoute.
• Include this check in your regular dependency update cycle, not just as a one-off task.

Frequently asked questions

What exactly is "tunnelRoute"? It's a Sentry configuration option for Next.js that redirects error reports through a route of your own domain, instead of sending them directly to Sentry's servers [1].

Am I affected if I use Sentry in Next.js but haven't configured tunnelRoute? According to the official description, exploitation requires having tunnelRoute configured and building with webpack, in addition to a route that collides with it [1]. If you don't meet those conditions, the scenario described doesn't directly apply, although it is still advisable to update.

Is updating urgent? The flaw has a CVSS score of 9.1, classified as critical by NVD [1], and allows an unauthenticated attacker to access protected routes. Given that combination, it should be treated as a priority.

What does OCIRIA's radar add about this case? Our radar places this vulnerability in the privilege escalation category and agrees that the main risk is the bypass of critical security controls in Next.js applications that use Sentry for monitoring [2].

Sources

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-114139
• [2] https://github.com/advisories/GHSA-mchm-gjx6-7h55