CVE-2026-42945 (NGINX Rift): Desbordamiento Crítico de Heap en el Módulo de Reescritura

NGINX no es un servidor web más. Es la pieza de infraestructura que aparece detrás del 34% de todos los sitios activos en internet, presente en arquitecturas de microservicios como controlador de entrada en Kubernetes, usado como gateway de APIs en plataformas de alto tráfico, y desplegado como capa de seguridad en productos comerciales de F5. El 13 de mayo de 2026, el equipo de DepthFirst Disclosures publicó los detalles técnicos de CVE-2026-42945, una vulnerabilidad crítica de desbordamiento de heap que ha estado integrada en el módulo de reescritura de NGINX desde el año 2008. Le dieron el nombre de NGINX Rift.

La puntuación CVSS v4.0 es 9.2. No requiere autenticación. Un único request HTTP malformado es suficiente para colapsar el proceso worker de NGINX. En sistemas con ASLR desactivado, la ejecución remota de código ya ha sido demostrada con un exploit público. El fallo funciona de forma determinista: no es un bug intermitente ni una condición de carrera, sino un desbordamiento reproducible dado el patrón de configuración correcto. Esta es una emergencia de seguridad, no un elemento para la próxima ventana de mantenimiento.

Qué es NGINX Rift y por qué pasó desapercibido casi dos décadas

NGINX Rift es un desbordamiento de buffer en el heap dentro del módulo ngx_http_rewrite_module, componente central de NGINX responsable de la reescritura de URLs, redirecciones y manejo condicional de requests. Este módulo no es opcional: viene compilado en el binario por defecto y está activo en prácticamente cualquier instalación de NGINX que realice algún tipo de enrutamiento de requests más allá de servir archivos estáticos.

El motivo por el que este fallo evadió 18 años de auditorías de seguridad, revisiones de código y fuzzing continuo tiene que ver con la especificidad de su condición de disparo. El overflow no ocurre durante reescrituras de URL normales. Solo se activa cuando confluyen tres elementos muy concretos en la misma configuración. La mayoría de las instalaciones de NGINX usan directivas rewrite, pero no todas las combinaciones activan la vulnerabilidad, y eso fue suficiente para que pasara inadvertida durante casi dos décadas.

La causa raíz: desincronización entre dos pasadas de procesamiento

Cuando NGINX procesa una directiva rewrite, realiza dos pasadas separadas sobre el string de reemplazo. La primera pasada calcula el tamaño del buffer de heap que va a asignar. La segunda pasada escribe el contenido real en ese buffer. El problema: ambas pasadas usan lógica de escapado diferente.

El desbordamiento ocurre cuando se dan las tres condiciones de forma simultánea:

1. La directiva rewrite usa capturas PCRE sin nombre, es decir, las referencias posicionales $1, $2, etc.
2. El string de reemplazo contiene un signo de interrogación literal (?)
3. Esa directiva rewrite va seguida de otra directiva rewrite, if o set en el mismo bloque

La primera pasada calcula el tamaño usando un método de escapado que produce una estimación más pequeña. La segunda pasada escribe con un método diferente que expande ciertos caracteres: +, % y & se convierten en secuencias de varios bytes. Como el buffer fue asignado para el tamaño más pequeño, la escritura se extiende más allá del límite del buffer, corrompiendo la memoria del heap adyacente.

Un ejemplo de configuración vulnerable:

rewrite ^/buscar/(.+)$ /index.php?q=$1 last;
rewrite ^/index.php$ /app/handler break;

La captura sin nombre $1, el signo de interrogación en el reemplazo y la segunda directiva encadenada forman exactamente la combinación que activa el overflow. Un atacante que envíe un request a esta ruta con caracteres que se expandan durante el re-escapado puede reproducir el desbordamiento de forma fiable.

Perspectiva técnica: La diferencia entre un bug que se descubre en meses y uno que permanece 18 años suele estar en la profundidad del contexto necesario para activarlo. Los scanners y fuzzers genéricos que prueban entradas HTTP anómalas no tienen contexto sobre la semántica interna de las directivas de NGINX. Este bug requería conocer la lógica del módulo de reescritura para saber exactamente qué condición buscar.

Versiones afectadas y superficie de ataque real

El rango de versiones afectadas es extraordinariamente amplio, convirtiéndose en uno de los CVEs de mayor alcance en la historia del software de servidores web.

NGINX Open Source

Todas las versiones de NGINX Open Source desde 0.6.27 hasta la 1.30.0 son vulnerables. Eso equivale a 18 años de versiones y cubre la gran mayoría de instalaciones de NGINX en producción a nivel global. Las versiones corregidas son 1.30.1 (rama estable) y 1.31.0 (rama mainline), publicadas específicamente para remediar esta vulnerabilidad.

NGINX Plus y el ecosistema afectado

NGINX Plus desde R32 hasta R36 también es vulnerable. Las versiones parcheadas son R32 P6 y R36 P4. Pero la superficie de exposición va mucho más allá del binario de NGINX. Los siguientes productos embeben el mismo módulo vulnerable y heredan la vulnerabilidad:

• NGINX Ingress Controller: El controlador de entrada más utilizado en Kubernetes
• NGINX Gateway Fabric: Implementación de Kubernetes Gateway API con NGINX como plano de datos
• NGINX App Protect WAF: Firewall de aplicaciones web construido directamente sobre NGINX
• F5 WAF para NGINX: Oferta comercial de WAF de F5
• Productos de protección DDoS de F5: Donde NGINX actúa como capa de procesamiento de requests

Este es el error más frecuente en la respuesta a este CVE: los equipos auditan sus instancias de NGINX standalone y cierran el incidente, sin revisar que el NGINX Ingress Controller de su cluster de Kubernetes sigue corriendo sobre una imagen sin parchar. Cada producto tiene su propio ciclo de release y su propio proceso de actualización de imagen.

Escenario real: Un equipo de seguridad dedica horas a confirmar que todos los servidores NGINX de su flota están actualizados. Al día siguiente, se detecta tráfico anómalo hacia el endpoint de ingress de Kubernetes. El controlador de entrada todavía corre nginx:1.30.0. El equipo de plataformas no estaba incluido en el alcance del incidente inicial.

Cómo funciona la explotación

La ruta de explotación es directa. Un atacante no autenticado envía un único request HTTP crafteado a cualquier endpoint de NGINX que procese la configuración de rewrite vulnerable. No necesita credenciales, tokens de sesión, ni conocimiento previo de la aplicación. Solo necesita acceso de red al endpoint.

El request contiene una ruta URL que coincide con la directiva rewrite vulnerable y parámetros de query con caracteres que se expanden durante el re-escapado. NGINX procesa el request, ejecuta las dos pasadas del cálculo de buffer y escribe más allá del límite de la región asignada en el heap. El resultado depende de qué memoria quede adyacente al desbordamiento:

• Caída del proceso worker (DoS): Ocurre de forma fiable independientemente del estado de ASLR. La corrupción del heap genera una condición anormal que termina el proceso worker. El proceso master de NGINX reinicia el worker automáticamente, pero todos los requests en vuelo en ese worker se pierden.
• Ejecución Remota de Código: Demostrada por DepthFirst Disclosures en sistemas con ASLR desactivado. El atacante usa el overflow para sobreescribir punteros de función, redirigiendo la ejecución hacia código controlado por el atacante dentro del proceso worker.

El repositorio público del PoC en github.com/depthfirstdisclosures/nginx-rift incluye código de exploit funcional que demuestra la ruta de DoS y documenta la ruta de RCE para entornos con ASLR desactivado.

Escenario arquitectónico: ataque a un gateway de APIs en Kubernetes

Un cluster de Kubernetes usa NGINX Ingress Controller para enrutar tráfico externo. La configuración del ingress incluye la siguiente anotación para una regla de enrutamiento basada en paths:

nginx.ingress.kubernetes.io/rewrite-target: /api/$1?fuente=ingress
nginx.ingress.kubernetes.io/use-regex: "true"

Esta anotación genera internamente una directiva rewrite con una captura sin nombre y un signo de interrogación en el reemplazo: exactamente la combinación vulnerable. Un atacante identifica la versión de NGINX a través de la cabecera de respuesta del servidor. Envía un request crafteado al endpoint de ingress. El pod del controlador colapsa. Kubernetes lo reinicia, pero el atacante envía otro request tan pronto como el nuevo pod supera su readiness probe. Con tres réplicas de ingress, puede mantener un DoS persistente sobre la capa de entrada del cluster.

Mini-resumen: Un solo request HTTP sin autenticación activa el overflow. El DoS es reproducible en todos los sistemas afectados. El RCE está demostrado en sistemas sin ASLR. El PoC es público. No se necesita conocimiento previo de la aplicación objetivo.

Evaluación de riesgo y puntuación CVSS

La puntuación CVSS v4.0 de 9.2 (Crítico) refleja una complejidad de ataque baja, sin privilegios requeridos, y un impacto alto sobre disponibilidad junto con impacto condicional sobre integridad y confidencialidad a través de RCE. Leer el score correctamente requiere más contexto que el número solo.

La fila más importante de esta tabla es la última. No todo servidor que corra una versión afectada es explotable en la práctica. Solo los que tienen la combinación específica de directivas. Dicho esto, dado lo prevalente que es la lógica de reescritura compleja en entornos de producción, asumir que la instalación está protegida sin verificarlo no es una postura de seguridad válida.

Remediación inmediata: qué hacer y cuándo

Solución definitiva: actualización de versión

La única solución completa y permanente es actualizar a una versión parcheada. Las versiones corregidas son:

• NGINX Open Source: Actualizar a 1.30.1 (estable) o 1.31.0 (mainline)
• NGINX Plus: Actualizar a R32 P6 o R36 P4
• NGINX Ingress Controller, Gateway Fabric, App Protect WAF: Actualizar las imágenes de contenedor desde el registro oficial de F5/NGINX

La actualización del binario de NGINX es operativamente de bajo riesgo. Para despliegues standalone, reemplazar el binario y ejecutar nginx -s reload realiza una recarga graceful: las conexiones en vuelo son atendidas por los workers antiguos hasta que terminan, mientras las nuevas conexiones van a los workers actualizados. Sin desconexiones forzadas. Para despliegues en Kubernetes, un rolling update reemplaza los pods de uno en uno con comprobaciones de salud continuas.

Mitigación temporal: capturas con nombre

Si una actualización inmediata no es operativamente viable, la condición de disparo se puede eliminar reemplazando las capturas sin nombre por capturas con nombre en todas las directivas rewrite:

# Vulnerable
rewrite ^/api/(.+)/datos$ /backend/index.php?ruta=$1&formato=json last;
rewrite ^/backend$ /app/handler break;

# Seguro: captura con nombre elimina la condicion de disparo
rewrite ^/api/(?P<seg>.+)/datos$ /backend/index.php?ruta=${seg}&formato=json last;
rewrite ^/backend$ /app/handler break;

Este cambio elimina la referencia posicional que genera la desincronización de tamaño. El comportamiento funcional de la regla de reescritura es idéntico desde la perspectiva de la aplicación. La mitigación requiere auditar todas las directivas rewrite en todos los archivos de configuración incluidos, incluyendo los archivos generados dinámicamente por Helm charts, operadores o sistemas de CMS.

Perspectiva técnica: No intentes bloquear este CVE a nivel de WAF o CDN. Los requests de explotación son estructuralmente indistinguibles del tráfico HTTP legítimo. El exploit activa un problema de seguridad de memoria en la lógica interna de procesamiento de NGINX, no en el contenido HTTP observable.

Errores frecuentes que cuestan caro en la respuesta a CVEs

El error más costoso es limitar el alcance del parcheo a la infraestructura orientada al cliente. Las instancias de NGINX que sirven herramientas internas de desarrollo, dashboards de monitoreo, APIs internas o webhooks de CI/CD son igualmente vulnerables. En un escenario de movimiento lateral post-compromiso inicial, una instancia de NGINX interna sin parchar puede convertirse en punto de escalación para el atacante.

El segundo error frecuente es asumir que las imágenes de contenedor se actualizan automáticamente. Un deployment en Kubernetes usa la imagen de contenedor especificada en el momento del despliegue. Ejecutar docker pull nginx:latest solo actualiza el caché de imagen local, no los pods en ejecución. Parchear NGINX en Kubernetes significa actualizar la referencia de imagen en el manifiesto de deployment y disparar un rollout explícito.

El tercer error es auditar solo el archivo principal nginx.conf e ignorar los archivos de configuración incluidos. Una instalación de NGINX de producción típicamente incluye docenas de archivos de virtual host en sites-enabled/ o fragmentos en conf.d/. Una auditoría completa requiere examinar cada archivo en el árbol de configuración.

El cuarto error ocurre cuando la mitigación de capturas con nombre se aplica en la configuración de producción en ejecución en vez de en las plantillas de origen. El próximo despliegue automatizado puede sobreescribir la configuración mitigada con la plantilla original vulnerable. La mitigación debe aplicarse en el Helm chart, el template de Ansible o donde sea que se genere la configuración.

Consideraciones de rendimiento durante el parcheo

La actualización de 1.30.0 a 1.30.1 es un release exclusivo de seguridad. Sin cambios de comportamiento, sin nuevas funcionalidades, sin modificaciones en la semántica de configuración. El rendimiento post-actualización es idéntico al pre-actualización. No existe ningún argumento técnico válido basado en rendimiento para retrasar este parche.

Para despliegues a gran escala gestionados mediante herramientas como Ansible, Chef o Puppet, la actualización puede automatizarse con rollouts por fases: actualizar un porcentaje de instancias, monitorizar tasas de error y tiempos de respuesta durante un período definido, y continuar. Este enfoque balancea la urgencia del parche con la cautela operacional para sistemas de alto tráfico.

Un elemento operacional a considerar en entornos de alto tráfico: en configuraciones con pools de upstream muy grandes o árboles de configuración complejos, la operación nginx -s reload implica releer y validar toda la configuración. En casos extremos esto puede tomar varios segundos, durante los cuales la aceptación de nuevas conexiones puede hacer cola. Este es comportamiento existente de NGINX, no introducido por el parche. Inclúyelo en los runbooks de despliegue para entornos de alto tráfico donde se haya observado este comportamiento previamente.

Preguntas frecuentes

¿CVE-2026-42945 es explotable en sistemas con ASLR activado?

Sí, pero el impacto se limita a denegación de servicio. El desbordamiento de heap colapsa el proceso worker de NGINX de forma determinista independientemente del estado de ASLR. Todos los requests HTTP en procesamiento en ese worker en el momento del crash se pierden y el worker debe reiniciarse. La ejecución remota de código ha sido demostrada específicamente contra sistemas con ASLR desactivado. Los sistemas modernos de Linux con ASLR activado enfrentan un riesgo DoS real pero un riesgo de RCE significativamente menor.

¿Cómo verifico si mi configuración específica de NGINX es explotable?

Audita cada directiva rewrite en todos los archivos de configuración incluidos. Busca esta combinación específica: (1) una referencia de captura PCRE sin nombre ($1, $2, etc.) en el string de reemplazo, (2) un signo de interrogación literal (?) también presente en ese string de reemplazo, y (3) al menos una directiva rewrite, if o set adicional siguiendo a la directiva afectada en el mismo bloque. Las tres condiciones deben estar presentes para que exista el trigger. Si ninguna de tus directivas rewrite cumple este patrón, la vulnerabilidad no puede ser explotada contra tu instalación aunque la versión esté dentro del rango afectado.

¿Afecta esta vulnerabilidad a NGINX usado exclusivamente como servidor de archivos estáticos?

Si la configuración no contiene directivas rewrite, if o set que procesen input controlado por el usuario, la condición de trigger explotable no existe. Una configuración minimalista de servidor de archivos estáticos no es explotable. Sin embargo, las configuraciones evolucionan con el tiempo, y actualizar a la versión parcheada sigue siendo la acción recomendada independientemente del estado actual de la configuración.

¿Mi proveedor de cloud gestiona el parche del NGINX Ingress Controller automáticamente?

Depende del modelo de despliegue. Los proveedores cloud como AWS, GCP y Azure gestionan sus planos de control de Kubernetes, pero los workloads que corren en esos clusters, incluyendo los deployments autogestionados de NGINX Ingress Controller, son responsabilidad del operador. Si desplegaste el controlador de ingress de NGINX a través de Helm o un operador de Kubernetes, eres responsable de actualizarlo. Si utilizas una clase de ingress nativa del proveedor totalmente gestionada, verifica el boletín de seguridad de tu proveedor para confirmar si el parche ya ha sido aplicado.

Conclusión

CVE-2026-42945 es un ejemplo claro de por qué la deuda de seguridad en infraestructura crítica puede acumularse silenciosamente durante décadas. Dieciocho años de exposición no detectada, un score CVSS de 9.2, y un exploit público que demuestra crashes de worker sin autenticación convierten esto en una respuesta inmediata, no en un elemento de backlog.

Realiza hoy mismo un inventario de cada instancia de NGINX en tu infraestructura, incluyendo servicios internos, controladores de ingress de Kubernetes, appliances WAF y proxies de borde. Audita cada configuración en busca del patrón de rewrite vulnerable. Aplica la mitigación de capturas con nombre de forma inmediata en cualquier instancia que no puedas actualizar a corto plazo. Completa la actualización de versión antes de que esta vulnerabilidad pase de ser un CVE crítico recién publicado a una vulnerabilidad activamente explotada en campañas reales.

Sigue a Nippysoft para cobertura técnica continua de CVEs de alto impacto y vulnerabilidades de seguridad en infraestructura de software.

Referencias

• CVE-2026-42945 — Detalle en NVD: nvd.nist.gov/vuln/detail/CVE-2026-42945
• NGINX — Avisos de seguridad oficiales: nginx.org/en/security_advisories.html
• DepthFirstDisclosures — PoC Nginx-Rift (GitHub): github.com/depthfirstdisclosures/nginx-rift
• AlmaLinux — NGINX Rift (CVE-2026-42945): Parche disponible en testing: almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/
• Security Online — RCE crítico de 18 años en NGINX y PoC en GitHub: securityonline.info/nginx-rce-vulnerability-cve-2026-42945-poc-disclosure/
• Orca Security — Fallo en el módulo Rewrite de NGINX (CVE-2026-42945): orca.security/resources/blog/nginx-rewrite-module-vulnerability-cve-2026-42945/
• SC World — Vulnerabilidad crítica NGINX Rift presente durante 18 años: scworld.com/brief/critical-nginx-rift-vulnerability-discovered-present-for-18-years