NGINX Rift CVE-2026-42945: 18 años y ya explotado

El reverse proxy más usado del mundo arrastró durante casi dos décadas un fallo crítico en una de sus funciones más cotidianas: reescribir URLs. Se llama NGINX Rift, se rastrea como CVE-2026-42945, y no es teoría de laboratorio: hay explotación activa en internet y un exploit público circulando. Si tenés NGINX de cara a internet con reglas rewrite, esto te toca directamente.

CVE-2026-42945, apodado NGINX Rift, es un heap buffer overflow en el ngx_http_rewrite_module de NGINX —el componente que procesa las reglas rewrite que transforman las URLs entrantes. Un atacante no autenticado puede dispararlo con una sola petición HTTP para tumbar el worker (DoS) o, bajo ciertas condiciones, ejecutar código remoto. Fue introducido en NGINX 0.6.27 (2008) y F5 lo divulgó el 13 de mayo de 2026 con un CVSS v4.0 de 9.2.

¿Tu configuración de NGINX es vulnerable a CVE-2026-42945?

NGINX Rift (CVE-2026-42945): 18 años oculto y ya explotado

Solo sos vulnerable si se dan tres condiciones juntas en el mismo bloque de configuración. No alcanza con tener NGINX afectado: hace falta el patrón exacto de config. Según el aviso de F5, el fallo se dispara cuando una directiva rewrite usa una captura PCRE sin nombre ($1, $2…), la cadena de reemplazo incluye un signo de pregunta (?) y esa directiva está seguida por otra rewrite, if o set en el mismo scope.

El caso clásico —y peligrosamente común— se ve así:

location /api/ {
    rewrite ^/api/(.*)$ /internal?id=$1;   # captura sin nombre + "?"
    set $backend "upstream_a";              # directiva siguiente en el mismo scope
}

Ese ?id=$1 seguido de un set es justamente el detonante. Para revisar tu servidor en segundos, volcá la config completa y buscá el patrón:

# Versión instalada
nginx -v

# Buscar reescrituras con captura numerada y "?" en el reemplazo
nginx -T 2>/dev/null | grep -nE 'rewrite\s+.*\$[0-9].*\?'

Si ese grep devuelve líneas y abajo tenés un if/set/rewrite, estás en el grupo de riesgo alto. Si no usás capturas sin nombre o no hay ? en el reemplazo, el vector no aplica —pero igual conviene parchear, porque una config puede cambiar mañana.

¿Cómo funciona el heap buffer overflow en ngx_http_rewrite_module?

El overflow ocurre cuando el módulo procesa cadenas muy largas o caracteres repetidos de forma continua al evaluar la regla de reescritura, y desborda el buffer reservado en el heap del proceso worker. De acuerdo con el análisis de Akamai, el ataque llega en peticiones HTTP con "patrones repetitivos extensos (como caracteres + continuos) que evaden los chequeos de longitud estándar", y así corrompen la memoria del worker.

La raíz está en ngx_http_script.c, el archivo que comparten todos los downstream que heredan el motor de scripting de NGINX. Por eso el radio de impacto es enorme: no es solo el NGINX que compilaste vos.

DoS es el impacto confiable. Un atacante puede crashear el worker de forma repetida y meterlo en un restart loop, dejando el sitio caído mientras sostiene el envío de peticiones maliciosas.
RCE es posible pero más difícil. Akamai lo describe como "significativamente más difícil" por las defensas de ASLR: haría falta un info-leak más manipulación precisa de memoria. Aun así, hay reportes de un PoC con una cadena de bypass de ASLR que habilita RCE no autenticado.
Sin autenticación y sin interacción. No necesita credenciales ni que nadie haga clic: basta que el endpoint vulnerable sea alcanzable por HTTP.

¿Hay explotación activa de CVE-2026-42945 en este momento?

Sí, ya hay explotación activa confirmada. La firma VulnCheck reportó ataques reales pocos días después de la divulgación, capturados en sus honeypots. "Estamos viendo explotación activa de CVE-2026-42945 en F5 NGINX, un heap buffer overflow que afecta tanto a NGINX Plus como a NGINX Open Source, en nuestros VulnCheck Canaries apenas días después de que se publicó el CVE", informó VulnCheck. Sumado a que el PoC es público, la ventana para actuar tranquilo ya se cerró.

La combinación es la peor posible desde el lado del defensor: un bug de 18 años, en un software ubicuo, con exploit publicado y adversarios ya escaneando. No es un CVE para dejar en la cola del próximo sprint.

¿Qué versiones de NGINX están afectadas y cuáles corrigen el fallo?

Están afectadas todas las ramas modernas de NGINX Open Source hasta la 1.30.0 inclusive, y NGINX Plus de R32 a R36. Las versiones muy viejas (0.6.27–0.9.7) no reciben fix. La corrección llegó en la rama stable y en la mainline.

Producto	Afectado	Corregido en
NGINX Open Source (stable)	1.0.0 – 1.30.0	1.30.1 o superior
NGINX Open Source (mainline)	hasta 1.30.0	1.31.0 o superior
NGINX Plus	R32 – R36	R32 P6 / R36 P4
Legacy	0.6.27 – 0.9.7	sin parche previsto

Ojo: algunos reportes posteriores mencionan builds 1.30.2 / 1.31.1 (asociados a un CVE compañero, CVE-2026-9256). La regla práctica es simple: instalá la última versión disponible de tu rama y confirmá el número de fix exacto en el aviso oficial de F5, no te quedes en la "primera versión parcheada" si tu repo ya ofrece una más nueva.

¿Qué implica esto si corrés NGINX en Kubernetes?

El fallo no vive solo en el NGINX que instalás a mano: se propaga a los downstream que comparten ngx_http_script.c. Según los avisos, entre los productos afectados están el NGINX Ingress Controller, NGINX Gateway Fabric y NGINX Instance Manager, además de las líneas de F5 WAF/App Protect para NGINX.

El Ingress Controller es la superficie más expuesta. Es literalmente el borde de tu cluster: si tus Ingress generan reglas rewrite con captura y ? (por ejemplo con nginx.ingress.kubernetes.io/rewrite-target), revisá la config renderizada, no solo el manifiesto.
Actualizá la imagen del controller, no el paquete del host. En Kubernetes el NGINX vulnerable viaja dentro del contenedor del Ingress; parchear el nodo no alcanza. Subí la versión del chart/imagen del controller a una que empaquete el NGINX corregido.
Auditá los downstream de a uno. Un cluster puede tener NGINX en el Ingress, en un service mesh y en sidecars: cada instancia cuenta como superficie propia.

¿Qué podés hacer HOY para protegerte?

La prioridad es parchear; todo lo demás es mitigación temporal. Un plan concreto de menor a mayor esfuerzo:

Actualizá NGINX ya. Subí a 1.30.1+ (stable) / 1.31.0+ (mainline) o al patch level correspondiente de NGINX Plus. Reiniciá el servicio y confirmá con nginx -v.
Si no podés parchear en el acto, neutralizá el patrón. Reescribí las reglas para no combinar captura sin nombre + ? + directiva siguiente en el mismo scope: usá capturas con nombre ((?<id>...)) o movés el ? fuera del reemplazo. Probá siempre en staging.
Sumá una regla de WAF como cinturón. Akamai, por ejemplo, publicó la Rapid Rule 3000983 de su Adaptive Security Engine para este CVE. Si tenés WAF adelante, buscá si ya trae firma para NGINX Rift y activala.
Verificá exposición externa. Restringí a redes de confianza los endpoints con rewrite que no necesiten estar públicos, y revisá logs por picos de reinicios de worker o peticiones con cadenas anómalamente largas.

¿Por qué una IA encontró un bug que estuvo 18 años escondido?

Porque el hallazgo salió de análisis automatizado de código a gran escala, no de un pentester leyendo línea por línea. La firma depthfirst aplicó en abril de 2026 su sistema autónomo de análisis sobre el repositorio de NGINX y desenterró un fallo que había sobrevivido a 18 años de revisiones humanas. Ese es el dato que importa más allá de este CVE puntual.

Es la misma tendencia que ya vimos en esta casa con CVE-2026-42533 (15 años de RCE oculto en el map de NGINX) —una lectura complementaria si querés dimensionar el patrón. Los bugs "de época" en infraestructura madura están saliendo a la luz más rápido porque hay herramientas capaces de barrer código legacy a una escala imposible para un equipo humano. La contracara es que los atacantes tienen acceso a las mismas técnicas. Conclusión práctica: que un componente sea viejo y estable ya no equivale a "seguro", y tu ventana de parcheo se achica cada vez más.

Preguntas frecuentes

¿Estoy afectado si no uso reglas rewrite en NGINX?

El vector requiere el patrón específico de rewrite con captura sin nombre y ?, así que sin esas reglas no sos explotable por esta vía. Pero tu binario sigue siendo vulnerable a nivel código: si mañana agregás una regla que cumpla las condiciones, quedás expuesto. Actualizá igual.

¿CVE-2026-42945 permite RCE o solo DoS?

El DoS es confiable en todos los sistemas afectados; el RCE es posible pero más difícil por ASLR. Aun así hay reportes de un PoC con bypass de ASLR que habilita ejecución remota no autenticada, así que tratalo como potencial RCE, no como "solo un crash".

¿Alcanza con reiniciar NGINX para mitigar?

No. Reiniciar recupera un worker caído pero no elimina la vulnerabilidad: el atacante vuelve a crashearlo con la siguiente petición. La única solución real es actualizar a una versión corregida o eliminar el patrón de config vulnerable.

¿Qué versión de NGINX tengo que instalar?

Como mínimo 1.30.1 (stable) o 1.31.0 (mainline), o el patch level indicado para tu release de NGINX Plus. Instalá la última disponible en tu rama y confirmá el número exacto de fix en el aviso oficial de F5, ya que hay builds posteriores asociados al CVE compañero CVE-2026-9256.

¿Cómo verifico si me están atacando?

Buscá en los logs reinicios repetidos del proceso worker (restart loops) y peticiones con URIs anormalmente largas o con secuencias de caracteres repetidos como +. Un pico de esos patrones contra endpoints con rewrite es señal de intento de explotación.

Fuentes: Aviso oficial de F5 (K000161019) · The Hacker News · Akamai Security Research · Security Affairs (explotación activa)