@sentry/nextjs tunnelRoute lets requests skip Next.js middleware (CVE-2026-114139, 9.1, webpack builds) and DOMPurify 3.4.4 to 3.4.16 sanitizer bypass (GHSA-cg2g-xh64-v4q7, 9.2)

View raw markdownEdit on GitHub ↗

TL;DR

Two Critical records on 2026-10-22 and 10-23 hit packages that sit in most vibe-coded Next.js apps. @sentry/nextjs with tunnelRoute set rewrote matching requests before Next.js middleware ran, so a request shaped like a tunnel path reached the rest of the app without auth middleware; webpack builds only (the Turbopack path was not affected); fixed 9.47.2, 10.75.2 and 11.0.0-rc.1 (CVE-2026-114139 / GHSA-mchm-gjx6-7h55, CVSS 4.0 9.1). DOMPurify 3.4.4 through 3.4.16 let crafted markup through the sanitizer and into the DOM as script-capable content; fixed 3.4.17 (GHSA-cg2g-xh64-v4q7, 9.2). Upgrade both; if the Sentry tunnel was on in a webpack build, review access logs for tunnel-prefixed paths that reached protected routes.

What happened

@sentry/nextjs. GitHub Advisory Database published 2026-10-22, reviewed 10-23, CWE-863. The SDK's tunnelRoute option proxies browser-side Sentry events through the app to avoid ad blockers; the SDK implemented it as a rewrite rule that ran before middleware. A request matching the tunnel pattern was therefore rewritten and never evaluated by middleware.ts, which is where Clerk, NextAuth and Supabase guards live in a typical app. Three fixed lines: 9.47.2, 10.75.2, 11.0.0-rc.1; the record scopes the bug to webpack builds and says Turbopack users are not affected. Registry 2026-10-26: @sentry/nextjs latest 11.9.0. Companion entry for the same class, auth enforced only in middleware that a request can skip: Clerk SDK middleware bypass batch.

DOMPurify. Published 2026-10-23, Critical 9.2, affected >= 3.4.4, <= 3.4.16, patched 3.4.17. The advisory text is internally inconsistent: one paragraph says the bypass needs a non-default configuration and another says default settings are affected; this file carries both statements rather than resolving them. Registry 2026-10-26: dompurify latest 3.4.17. DOMPurify sits under isomorphic-dompurify, most Markdown renderers and several rich-text editors, so npm ls dompurify matters more than a direct dependency check.

Why it is here: an AI-generated Next.js app almost always has Sentry's wizard output in next.config.js with tunnelRoute set, and the middleware file is the whole auth layer.

Am I affected?

  • npm ls @sentry/nextjs dompurify; grep -rn tunnelRoute next.config.*; next build output says webpack or Turbopack.
  • A webpack build with tunnelRoute on any affected version and any middleware-enforced route: review request logs for paths carrying the tunnel prefix that returned 200 from protected handlers.

If you are affected

  1. Upgrade @sentry/nextjs to 9.47.2 / 10.75.2 / 11.0.0-rc.1 or later and dompurify to 3.4.17; rebuild and redeploy.
  2. Until the upgrade, remove tunnelRoute from the Sentry config (events go direct to Sentry).
  3. If logs show the bypass used, follow if your web app was compromised.

Prevention

Sources