NGINX Rift CVE-2026-42945: el full-chain que anula ASLR

Cuando NGINX Rift (CVE-2026-42945) se hizo público en mayo de 2026, había una frase que tranquilizaba a más de un sysadmin: la ejecución remota de código solo funcionaba si el servidor tenía el ASLR apagado. Con ASLR activo —o sea, en cualquier Linux moderno con la config por defecto— el bug se quedaba en un denial of service molesto pero no catastrófico. Esa excusa se terminó. El 5 de julio, el equipo de DepthFirst publicó un PoC full-chain que encadena Rift con un segundo bug de fuga de memoria y logra RCE sin autenticación con el ASLR encendido. Esto es lo que cambió y qué hacer al respecto.

NGINX Rift (CVE-2026-42945) es un desbordamiento de heap (CWE-122) en el módulo ngx_http_rewrite_module de NGINX, presente desde 2008 y divulgado el 13 de mayo de 2026 por F5 junto a la plataforma DepthFirst. Permite a un atacante no autenticado, con una sola petición HTTP diseñada, colgar los procesos worker o ejecutar código remoto. Puntúa 9.2 en CVSS v4.0. Afecta a todas las builds de NGINX desde la 0.6.27 hasta la 1.30.0.

¿Por qué el "ASLR apagado" dejó de ser tu red de contención?

NGINX Rift (CVE-2026-42945): el full-chain que anula el ASLR

Porque el full-chain de julio no necesita adivinar direcciones: las lee del propio servidor y después escribe solo los bytes que ASLR no aleatoriza. La cadena une dos bugs de la misma familia. Primero PoolSlip (CVE-2026-9256), un over-read de heap que, cuando NGINX refleja $args en una página degradada, filtra direcciones vivas de libc y del heap. Con esas bases ya no hay que "acertar" nada.

El golpe fino está en cómo se usa el overflow de Rift. En vez de reescribir una dirección completa de 48 bits (algo poco confiable bajo ASLR), el exploit sobrescribe solo los 2 bytes bajos de un puntero de cleanup limit_conn que ya es válido. ASLR aleatoriza los bytes altos, pero los bajos son predecibles: al tocar únicamente esos, la técnica queda independiente del ASLR. Ese es el corazón de por qué "el ASLR ya no te salva".

¿Cómo se ejecuta el código paso a paso?

La cadena convierte una lectura de memoria y una escritura de 2 bytes en una llamada a system() con tu comando adentro. El flujo, según el análisis del PoC de DepthFirst, es este:

Fuga de direcciones con PoolSlip. Un patrón de rewrite malformado (por ejemplo ^/search/((.*))$ /lookup?$1$2) hace que el motor calcule mal la longitud de $args y termine reflejando memoria adyacente, revelando bases de libc y heap.
Heap spray de estructuras falsas. El atacante rocía cuerpos de peticiones HTTP con registros ngx_pool_cleanup_t falsos que apuntan a system() y llevan el comando como argumento.
Overflow quirúrgico con Rift. Se corrompen los 2 bytes bajos de un puntero de cleanup válido para redirigirlo a la estructura falsa recién spreada.
Disparo en el teardown. Al cerrarse la conexión, NGINX recorre su lista de cleanups del pool e invoca el handler secuestrado, ejecutando el comando.

El resultado, según el PoC publicado el 5 de julio de 2026, es una única llamada a system() sobre una imagen Docker nginx:1.30.0 de fábrica, sin direcciones hardcodeadas y sin reiniciar NGINX, con una confiabilidad reportada de ~90% por cada worker nuevo.

¿A quién afecta NGINX Rift y su full-chain?

Afecta a prácticamente cualquier NGINX que use directivas de rewrite y que no esté parcheado. Los rangos, según el aviso de F5/DepthFirst y el análisis del chain, son:

Rift (CVE-2026-42945): NGINX de la 0.6.27 a la 1.30.0, y NGINX Plus R32 a R36. Cualquier downstream que compile el mismo ngx_http_script.c hereda el bug.
PoolSlip (CVE-2026-9256): de la 0.1.17 a la 1.30.1, más la 1.31.0. Es la pata que habilita el bypass de ASLR.
ingress-nginx en Kubernetes: embebe el módulo vulnerable, así que un Ingress Controller sin parchear queda expuesto en el borde del clúster. Si ya seguiste nuestras notas sobre ingress-nginx y los CVE de path/inyección, esto es una capa más del mismo problema.
Productos que reempaquetan NGINX: F5 WAF for NGINX, appliances y contenedores de terceros que shippean el binario también entran en el radar.

¿Ya lo están explotando en la práctica?

Sí. Según Help Net Security, la explotación activa de CVE-2026-42945 arrancó a los pocos días de la divulgación del 13 de mayo, apuntando a servidores con configuraciones de rewrite pesadas expuestas a internet. Al principio los ataques eran mayormente crashes de worker (DoS); el salto cualitativo es que ahora existe un exploit público de RCE que no depende de que el objetivo tenga ASLR desactivado, lo que amplía muchísimo la superficie realmente explotable.

¿Cómo sé si mi configuración de NGINX es explotable?

El riesgo depende de tus reglas de rewrite, no solo de la versión. El patrón peligroso combina una captura PCRE sin nombre con un signo de pregunta en el reemplazo. Concretamente, mirá tu config si tenés una directiva rewrite que:

Usa una captura PCRE sin nombre como $1 o $2 en el reemplazo.
Incluye un signo ? en la cadena de reemplazo (arma un query string).
Va seguida de otra directiva rewrite, if o set en el mismo scope.

Un ejemplo del tipo de regla que dispara el problema:

location /old/ {
    rewrite ^/old/(.*)$ /new?$1 last;   # captura sin nombre + '?'
    set $flag 1;                        # otra directiva en el mismo scope
}

Para ver qué versión corrés, lo más rápido:

nginx -v
# nginx version: nginx/1.30.0   -> vulnerable
docker exec <container> nginx -v   # si corre en contenedor

¿Qué podés hacer hoy para blindarte?

La respuesta corta es parchear a una versión que cierre las dos patas del chain, no solo Rift. En orden de prioridad:

Actualizá al menos a NGINX 1.30.2 o 1.31.1. El parche de Rift llegó en 1.30.1 (stable) y 1.31.0 (mainline), pero PoolSlip (CVE-2026-9256) se corrigió recién en 1.30.2 y 1.31.1. Quedarte en 1.30.1 tapa el overflow pero deja viva la fuga que anula el ASLR.
Si usás paquetes de la distro, tomá el backport. Los mantenedores de AlmaLinux, Ubuntu y Debian ya publicaron paquetes parcheados; un apt update && apt upgrade o dnf update suele alcanzar, pero verificá con nginx -v que el fix realmente entró.
Parcheá el Ingress Controller, no solo tus workloads. En Kubernetes, actualizá la imagen de ingress-nginx a la release que incorpore el NGINX corregido; es el punto más expuesto del clúster.
Revisá y simplificá tus rewrites como mitigación temporal. Si no podés parchear ya, evitá el patrón "captura sin nombre + ? + directiva siguiente" reescribiendo esas reglas. Es paliativo, no una solución.
No cuentes con ASLR ni con un WAF como defensa principal. El full-chain fue diseñado justamente para sortear el ASLR, y las firmas WAF se evaden con variantes del payload. El parche es la única barrera confiable.

Preguntas frecuentes

¿Qué versión de NGINX corrige el full-chain completo?

NGINX 1.30.2 y posteriores en la rama stable, y 1.31.1 y posteriores en mainline. Esas versiones cierran tanto Rift (CVE-2026-42945) como PoolSlip (CVE-2026-9256). Las versiones 1.30.1 y 1.31.0 solo parchean Rift y dejan viva la fuga que habilita el bypass de ASLR.

¿El ASLR sigue sirviendo de algo contra este exploit?

No como defensa contra el full-chain. La cadena de DepthFirst filtra las direcciones con PoolSlip y sobrescribe únicamente los 2 bytes bajos de un puntero válido, que ASLR no aleatoriza. Por eso funciona con ASLR activo. El ASLR sigue siendo útil como capa general, pero no te cubre acá.

¿Estoy en riesgo si no uso directivas rewrite?

El vector concreto conocido pasa por reglas de rewrite con capturas sin nombre y un ? en el reemplazo. Si tu config no usa ese patrón, la explotabilidad práctica baja, pero igual conviene parchear: los bugs viven en el binario y auditar toda regla presente y futura es más frágil que actualizar.

¿Cuán confiable es el exploit público?

El PoC full-chain publicado por DepthFirst el 5 de julio de 2026 reporta ~90% de confiabilidad por cada worker nuevo sobre una imagen nginx:1.30.0 de fábrica, sin direcciones hardcodeadas ni reinicio del servicio. Es un exploit maduro, no una prueba de laboratorio frágil.

¿ingress-nginx en Kubernetes está afectado?

Sí. ingress-nginx embebe el mismo ngx_http_rewrite_module, así que un controlador sin parchear expone el bug en el borde del clúster. Actualizá la imagen del Ingress Controller a una release que incorpore NGINX 1.30.2/1.31.1 o superior.

Conclusión

NGINX Rift dejó de ser "un DoS que solo es RCE si sos descuidado con el ASLR". El full-chain de julio demostró que una fuga de memoria bien elegida más una escritura de 2 bytes alcanzan para RCE sin autenticación en un NGINX de fábrica. La lección técnica es vieja pero se renueva: las mitigaciones de exploitation (ASLR, y en menor medida los WAF) compran tiempo, no seguridad. Lo único que cierra este chain es actualizar a 1.30.2 / 1.31.1 o superior —incluido tu Ingress Controller— y revisar tus reglas de rewrite mientras tanto.

Fuentes: The Hacker News — 18-Year-Old NGINX Rewrite Module Flaw Enables Unauthenticated RCE · Help Net Security — Attackers are exploiting critical NGINX vulnerability · IntelSecLab PoC Archive — nginx PoolSlip × Rift Chained ASLR-Independent RCE · F5 — NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945