Omisión del middleware en el SDK de Sentry para Next.js (CVE-2026-114139)

Resumen

• @sentry/nextjs envuelve el middleware de Next.js para poder omitirlo en las solicitudes del «túnel» de Sentry. La comprobación de omisión era más amplia que el propio túnel: se omitían todas las rutas bajo la ruta del túnel, no solo su endpoint.
• Las rutas que se resuelven bajo la ruta del túnel, por ejemplo una colisión directa como /monitoring/foo con tunnelRoute: '/monitoring', o un segmento dinámico raíz como app/[locale]/..., reciben esas solicitudes sin que se ejecute el middleware. Si el middleware es el único lugar donde se autoriza el acceso a esas rutas, se elude la autorización.
• Sentry califica el fallo como crítico, CVSS v4.0 9.1, clasificado como CWE-693, fallo de un mecanismo de protección. No se conoce explotación en ataques reales a fecha del 24 de octubre de 2026 y el problema no figura en el catálogo CISA KEV. El paquete npm @sentry/nextjs registró 7.848.686 descargas en la semana del 16-22 de octubre de 2026.
• Actualice a 9.47.2, 10.75.2 o 11.0.0-rc.1. No necesita cambiar la configuración. Si aún no puede actualizar, cambie tunnelRoute a una ruta bajo la que ninguna ruta de su aplicación pueda resolverse, compile con Turbopack o aplique autorización en la propia ruta además de en el middleware.

¿Estoy afectado?

Está afectado si se cumplen todas estas condiciones:

• Su aplicación utiliza @sentry/nextjs en un intervalo afectado, con la opción tunnelRoute configurada (una ruta en forma de cadena o true).
• Su aplicación se compila con webpack. Las compilaciones con Turbopack, predeterminado para next build desde Next.js 16, no están afectadas.
• Alguna ruta de su aplicación se resuelve bajo la ruta del túnel. Puede ser una colisión directa, /monitoring/foo con tunnelRoute: '/monitoring', o un segmento dinámico en la raíz, app/[locale]/..., que coincide con cualquier primer segmento de ruta.
• El middleware es el único lugar que aplica autorización para esas rutas.

El aviso de Sentry también explica claramente lo que no hace la omisión: saltarse el middleware no concede privilegios a la solicitud, y las rutas que comprueban la sesión en el servidor siguen protegidas. Los servicios de Sentry y los datos de su organización de Sentry no están afectados.

Compruebe lo que está instalado y qué condiciones se cumplen:

# Installed SDK version
npm ls @sentry/nextjs
node -e "console.log(require('@sentry/nextjs/package.json').version)"

# Lock file check (package-lock.json v2/v3 records the package under "node_modules/@sentry/nextjs")
grep -A1 '"node_modules/@sentry/nextjs"' package-lock.json

# Is the tunnel route configured?
grep -rn "tunnelRoute" next.config.* sentry.* .sentryclirc 2>/dev/null

# Container image check
docker run --rm <your-image> node -e "console.log(require('@sentry/nextjs/package.json').version)"

Después compruebe qué rutas pueden resolverse bajo la ruta del túnel: contraste los segmentos de su directorio app/ (o pages/) con el primer segmento de la ruta del túnel. Un segmento dinámico en la raíz como [locale] coincide con cualquier primer segmento.

¿Cómo lo corrijo?

Actualice el SDK. La omisión ahora coincide únicamente con las solicitudes que la reescritura del túnel atiende realmente, y no necesita cambios de configuración:

npm install @sentry/nextjs@10.75.2
# 9.x line: npm install @sentry/nextjs@9.47.2
# 11 prerelease line: npm install @sentry/nextjs@11.0.0-rc.1
# or: pnpm add @sentry/nextjs@10.75.2   |   yarn add @sentry/nextjs@10.75.2

Si no puede actualizar inmediatamente, el aviso de Sentry enumera tres medidas provisionales:

• Establezca tunnelRoute en una ruta bajo la que ninguna ruta de su aplicación pueda resolverse, o elimine la opción.
• Compile con Turbopack, predeterminado para next build desde Next.js 16.
• Aplique autorización en la ruta, el layout o la ruta de acceso a datos, además de en el middleware.

Los límites de estas medidas: la primera depende de que su estructura de rutas siga sin colisiones a medida que evolucione la aplicación; la segunda cambia el pipeline de compilación; y la tercera implica duplicar la lógica de autorización que se pretendía centralizar en el middleware. La actualización elimina la discrepancia dentro del SDK para todos sus usuarios.

¿Cuál es la causa raíz?

El middleware de Next.js se ejecuta antes de las rutas y es un lugar habitual para aplicar autorización. Cuando @sentry/nextjs instrumenta el middleware en compilaciones webpack, envuelve su función en wrapMiddlewareWithSentry, que primero comprueba si la solicitud entrante es del túnel de Sentry y, de ser así, retorna inmediatamente sin llamar a su código.

El túnel existe para eludir los bloqueadores de anuncios. Los eventos del navegador se envían a una ruta de su propio servidor, por ejemplo /monitoring, y una reescritura de Next.js los reenvía a Sentry. La reescritura solo atiende la ruta exacta del túnel con los parámetros de consulta o y p establecidos, que contienen los identificadores de organización y proyecto de Sentry.

La omisión utilizaba una prueba más amplia. Antes de la corrección, el envoltorio solo comprobaba si la ruta solicitada estaba bajo la ruta del túnel:

// packages/nextjs/src/common/utils/tunnelPathnameMatch.ts (before the fix)
export function isPathnameUnderSentryTunnelRoute(pathname: string, tunnelPath: string): boolean {
  return pathname === tunnelPath || pathname.startsWith(`${tunnelPath}/`);
}

Y el envoltorio omitía el middleware para cualquier coincidencia:

// packages/nextjs/src/common/wrapMiddlewareWithSentry.ts (before the fix)
if (tunnelRoute && typeof tunnelRoute === 'string') {
  const req: unknown = args[0];
  if (req instanceof Request) {
    const url = new URL(req.url);
    const isTunnelRequest = isPathnameUnderSentryTunnelRoute(url.pathname, tunnelRoute);
    if (isTunnelRequest) {
      // returns a response that lets the request continue, without calling
      // the wrapped middleware
      return new Response(null, { status: 200, headers: { 'x-middleware-next': '1' } });
    }
  }
}

La brecha está en la diferencia entre las dos comprobaciones. La reescritura atiende /monitoring con parámetros o y p válidos. La omisión cubría /monitoring y cualquier ruta que empezara por /monitoring/, con o sin parámetros. Una solicitud a /monitoring/foo no se reescribe hacia Sentry: Next.js la dirige a su aplicación. Pero el envoltorio ya ha retornado, de modo que el middleware nunca se ejecuta para ella.

En una frase: la omisión del middleware respondía «¿está esta ruta bajo la ruta del túnel?» cuando debía responder «¿es una solicitud que la reescritura del túnel atenderá realmente?». La diferencia entre esos conjuntos es exactamente el conjunto de solicitudes que llegan a sus rutas sin los controles de autenticación del middleware.

¿Cómo se explota?

No existe ninguna prueba de concepto pública ni se conoce explotación en ataques reales a fecha del 24 de octubre de 2026. La ruta de ataque que describen el aviso y el parche es la siguiente:

1. La aplicación objetivo establece tunnelRoute en una ruta, habitualmente /monitoring, y se compila con webpack.
2. La aplicación tiene una ruta que se resuelve bajo la ruta del túnel: una colisión directa o un segmento dinámico raíz como app/[locale]/page.tsx, que acepta /monitoring como valor de configuración regional.
3. El atacante envía una solicitud no autenticada a esa ruta.
4. El envoltorio de middleware del SDK detecta una ruta bajo la del túnel y devuelve la respuesta de continuación. El cuerpo del middleware de la aplicación, incluida su lógica de autorización, nunca se ejecuta.
5. Next.js entrega la solicitud al manejador de la ruta. Si nada entre el manejador y los datos vuelve a comprobar la sesión, la solicitud se atiende como si hubiera pasado por el middleware.

El exploit es una solicitud HTTP normal. Lo que consigue depende por completo de aquello que solo protegía el middleware de la aplicación: redirecciones de autenticación, comprobaciones de inquilino, restricciones de funcionalidades o autorización a nivel de ruta.

Flujo del ataque

La comprobación fallida está en B: la decisión de omitir es más amplia que la reescritura a la que debe servir.

¿Qué puede hacer un atacante?

Leer o actuar sobre lo que las rutas afectadas expongan sin las comprobaciones de su middleware. El aviso limita el impacto a la confidencialidad e integridad del sistema vulnerable, y el vector CVSS v4.0 es AV:N/AC:L/AT:P/PR:N/UI:N, sin privilegios ni interacción del usuario. Existen requisitos de ataque porque deben coincidir las condiciones de configuración: tunnelRoute establecido, compilación webpack, una ruta que se resuelva bajo la del túnel y autorización únicamente en el middleware.

Según el aviso, la omisión no concede privilegios y las rutas que comprueban la sesión en el servidor permanecen protegidas. Los servicios de Sentry y los datos de su organización de Sentry no están afectados.

¿Por qué funciona la corrección?

La corrección, pull request #24499 con adaptaciones a versiones anteriores #24565 y #24760, sustituye la prueba de prefijo de ruta por una función que coincide exactamente con lo que atiende la reescritura:

// packages/nextjs/src/common/utils/tunnelPathnameMatch.ts (after the fix)
/**
 * Returns true only for requests the tunnel rewrite (see `setUpTunnelRewriteRules`) would serve.
 *
 * This decides whether the user's middleware is skipped, so it must never be broader than the rewrite:
 * anything it matches that Next.js does not rewrite to Sentry reaches the app without middleware.
 */
export function isSentryTunnelRequest(request: Request, tunnelPath: string): boolean {
  // The SDK transport only ever sends POST requests
  if (request.method !== 'POST') {
    return false;
  }

  const url = new URL(request.url);

  if (url.pathname !== tunnelPath && url.pathname !== `${tunnelPath}/`) {
    return false;
  }

  // Next.js evaluates `has` conditions against the last value of a repeated query param, so every value has to qualify
  return ['o', 'p'].every(key => {
    const values = url.searchParams.getAll(key);
    return values.length > 0 && values.every(value => /^\d+$/.test(value));
  });
}

El envoltorio ahora llama a isSentryTunnelRequest(req, tunnelRoute) en lugar de comprobar el prefijo. Tres propiedades hacen coherentes ambos lados: solo solicitudes POST (el transporte del SDK nunca envía otra cosa), solo la ruta exacta del túnel con o sin barra final, y solo con parámetros o y p presentes y compuestos exclusivamente por dígitos, reflejando cómo Next.js evalúa las condiciones has de la reescritura. Toda solicitud que falle alguna comprobación pasa ahora por su middleware como cualquier otra.

La corrección resuelve completamente la brecha descrita: la omisión y la reescritura comparten ahora una definición de solicitud de túnel, expresada como invariante en el comentario del código. El envoltorio sigue existiendo solo en compilaciones webpack; en las de Turbopack nunca estuvo activo, de ahí que nunca estuvieran afectadas.

¿Cómo compruebo si he sufrido una intrusión?

No se han publicado indicadores de compromiso para este aviso ni se conoce explotación. Si utiliza una configuración afectada y quiere auditar este patrón:

• En los registros de acceso del servidor web o de Next.js, busque solicitudes no autenticadas que hayan alcanzado rutas bajo la del túnel y compárelas con lo que su middleware debería haber rechazado o redirigido: solicitudes a rutas del estilo /monitoring/... sin parámetros o y p, y solicitudes a segmentos dinámicos raíz como /en/... procedentes de orígenes que el middleware habría bloqueado.
• Revise la gestión del lado del servidor de las propias rutas afectadas en busca de código que supusiera que el middleware ya había autenticado al solicitante.

Si encuentra solicitudes que el middleware debería haber detenido y no detuvo, considere que esas sesiones alcanzaron la ruta sin autenticación y evalúe lo que la ruta devolvió.

Cronología

• 18 de septiembre de 2026: la corrección se incorpora a la rama principal (commit 878b685, «Alinear la identificación de solicitudes del túnel en el middleware con la reescritura del túnel»).
• 21 de septiembre de 2026: se incorpora la adaptación a v10 (commit d525a2f); Sentry publica 11.0.0-rc.1 y 10.75.2 el 22 de septiembre de 2026.
• 24 de septiembre de 2026: Sentry publica el aviso GHSA-mchm-gjx6-7h55.
• 28 de septiembre de 2026: se incorpora la adaptación a v9 (commit c122aac); Sentry publica 9.47.2 el 29 de septiembre de 2026.
• 21 de octubre de 2026: NVD publica CVE-2026-114139.
• 22 de octubre de 2026: el aviso se publica y revisa en GitHub Advisory Database.
• 24 de octubre de 2026: este artículo. No se conoce explotación en ataques reales y el problema no figura en el catálogo CISA KEV.

Preguntas frecuentes

¿Está afectada la configuración predeterminada?

La ruta del túnel es opcional, de modo que la configuración predeterminada de withSentryConfig sin tunnelRoute no está afectada. Las condiciones del aviso constituyen la lista completa: tunnelRoute establecido, compilación webpack, una ruta que se resuelva bajo la del túnel y autorización únicamente en el middleware.

¿Están afectadas las compilaciones con Turbopack?

No. El envoltorio de middleware con la omisión solo existe en la integración webpack. Turbopack, predeterminado para next build desde Next.js 16, nunca tuvo esa omisión, algo que los comentarios del código del SDK señalan como un problema de coherencia entre compilaciones que la corrección hereda.

¿Permite esto a los atacantes entrar en mi organización de Sentry?

No. El aviso de Sentry afirma que sus propios servicios y los datos de su organización de Sentry no están afectados. La omisión afecta a las rutas de su aplicación, no a las de Sentry.

¿Por qué se califica como crítico un SDK de supervisión?

Porque el impacto depende de su middleware, no del SDK. Cuando el middleware es el único límite de autorización para una ruta que colisiona, una solicitud de red no autenticada llega a ella; el vector CVSS v4.0 lo puntúa con 9.1 y un impacto alto en confidencialidad e integridad. Sentry también lo clasifica como CWE-693, fallo de un mecanismo de protección.

Utilizo middleware para redirecciones, no para autorización. ¿Debo actualizar igualmente?

Sí. Actualice cuando le resulte conveniente: las redirecciones y los demás usos del middleware ajenos a la autorización no tienen impacto de seguridad, pero las estructuras de rutas cambian y la actualización no introduce cambios incompatibles.

Escanee sus aplicaciones Next.js con Ostorlab para identificar la versión de @sentry/nextjs y el uso de tunnelRoute en sus repositorios.

Referencias

• Aviso de Sentry GHSA-mchm-gjx6-7h55: https://github.com/getsentry/sentry-javascript/security/advisories/GHSA-mchm-gjx6-7h55 (consultado el 24 de octubre de 2026)
• Entrada de GitHub Advisory Database: https://github.com/advisories/GHSA-mchm-gjx6-7h55 (consultado el 24 de octubre de 2026)
• Registro CVE-2026-114139 (CVSS v4.0 9.1, CWE-693, intervalos afectados): https://cveawg.mitre.org/api/cve/CVE-2026-114139 (consultado el 24 de octubre de 2026)
• Pull request de corrección #24499: https://github.com/getsentry/sentry-javascript/pull/24499 (consultado el 24 de octubre de 2026)
• Commit de corrección 878b685 (rama principal): https://github.com/getsentry/sentry-javascript/commit/878b685c85dc12045e47e1932c96f5381d7ac532 (consultado el 24 de octubre de 2026)
• Commit d525a2f de adaptación a v10: https://github.com/getsentry/sentry-javascript/commit/d525a2f6015b47384bc139c30d58e0d5435d52e5 (consultado el 24 de octubre de 2026)
• Commit c122aac de adaptación a v9: https://github.com/getsentry/sentry-javascript/commit/c122aac4f29541eb6da494296822c91eab3cf5ae (consultado el 24 de octubre de 2026)
• Versión 10.75.2 (publicada el 22 de septiembre de 2026): https://github.com/getsentry/sentry-javascript/releases/tag/10.75.2
• Versión 9.47.2 (publicada el 29 de septiembre de 2026): https://github.com/getsentry/sentry-javascript/releases/tag/9.47.2
• Versión 11.0.0-rc.1 (publicada el 22 de septiembre de 2026): https://github.com/getsentry/sentry-javascript/releases/tag/11.0.0-rc.1
• Recuento de descargas npm de @sentry/nextjs (7.848.686 descargas, semana del 16-22 de octubre de 2026): https://api.npmjs.org/downloads/point/last-week/@sentry/nextjs (consultado el 24 de octubre de 2026)