Un bug crítico presente en NGINX desde 2008. CVSS 9.2. Heap buffer overflow con camino hacia RCE. Ningún scanner lo detectó en 18 años. Una plataforma de IA lo encontró en 6 horas. En Tech86 acompañamos de cerca este descubrimiento, y lo que representa para la seguridad de infraestructura es más importante que el bug en sí.
El bug: heap overflow determinístico en el rewrite engine
El motor de rewrite de NGINX opera en dos passes. El primero calcula el tamaño del buffer necesario. El segundo copia los datos a ese buffer. El problema está en la desconexión entre esos dos passes.
Cuando una directiva rewrite contiene ? en la replacement string, la flag is_args se establece en el engine principal y nunca se limpia. Al calcular el tamaño, el sub-engine, en cero, ignora el escaping. Al copiar, el engine principal con is_args=1 llama a ngx_escape_uri. Cada byte escapable (+, %, &) se expande de 1 a 3 bytes. El buffer se asigna para raw_size. La copia escribe raw_size + 2*N bytes. Overflow determinístico, controlado por el atacante vía URI.
El detonante es un patrón de configuración documentado y recomendado: capturas PCRE sin nombre ($1, $2) combinadas con ? en la replacement y una directiva set, rewrite o if posterior. Algo como rewrite ^/users/([0-9]+)$ /profile.php?id=$1?last;, exactamente el tipo de regla que los API gateways usan a diario.
La explotación: RCE sin autenticación en un único request
Un único HTTP request. Sin autenticación. Sin sesión previa. Es todo lo que un atacante necesita.
El overflow corrompe la estructura ngx_pool_t adyacente en la heap. El puntero cleanup en el offset 64 se sobrescribe. Al destruir el pool, NGINX ejecuta lo que esté en ese puntero: un camino directo a la ejecución de código arbitrario.
El PoC demostrado usa cross-request heap feng shui: dos conexiones simultáneas para posicionar pools adyacentes, POST bodies para hacer spray de fake cleanup objects que llaman a system(), y un payload URI-safe para sobrescribir los bytes bajos del puntero. Con ASLR deshabilitado, el RCE está confirmado. Con ASLR habilitado, el DoS está garantizado, y el investigador observa: el master hace fork de workers con layout idéntico. Si el exploit tumba un worker, genera otro con el mismo layout. Se puede intentar hasta lograrlo.
Esto no es teórico. Es reproducible. Y afecta prácticamente todo NGINX del planeta: el 33% de los websites globales según W3Techs.
Quién lo encontró: IA en 6 horas, humanos en 18 años
DepthFirst AI. Plataforma LLM-powered. Un clic de onboarding. Seis horas de análisis. Cuatro bugs de memory corruption en la misma sesión:
- CVE-2026-42945 (CVSS 9.2), heap overflow en el rewrite
- CVE-2026-42946 (CVSS 8.3), asignación de ~1 TB en SCGI/UWSGI
- CVE-2026-40701 (CVSS 6.3), use-after-free en SSL/OCSP
- CVE-2026-42934 (CVSS 6.3), out-of-bounds read en el charset
Dieciocho años. Un tercio de la web. Cero detección humana. La IA no encontró por casualidad: exploró sistemáticamente code paths internos que los fuzzers tradicionales no alcanzan. El rewrite engine de NGINX es un subsistema complejo con estado compartido entre passes, y la combinación de is_args persistente con escaping condicional es exactamente el tipo de bug lógico que las pruebas de superficie nunca van a encontrar.
La asimetría que cambia el juego
El costo ofensivo para encontrar bugs como el NGINX Rift cayó de años a horas. El costo defensivo para aplicar el parche en miles de instancias sigue siendo órdenes de magnitud mayor. Esa es la asimetría que define el nuevo escenario de seguridad.
Piense en la matemática: un atacante con acceso a una herramienta de IA puede escanear decenas de proyectos de código abierto por día. Cada scan tiene el potencial de encontrar bugs críticos que existen desde hace años. Del lado defensivo, cada vulnerabilidad descubierta exige inventario de activos, priorización, ventana de mantenimiento, prueba de regresión, deploy coordinado, y eso para cada instancia, en cada ambiente, en cada cliente.
En Tech86 vimos esta dinámica repetirse en cada vulnerabilidad crítica de los últimos años. El tiempo entre disclosure y explotación masiva se redujo de meses a días. El tiempo entre disclosure y parche completo en la infraestructura real de los clientes no acompañó. Y el NGINX Rift es el ejemplo más dramático hasta ahora: 18 años de vulnerabilidad, descubierta en horas, y semanas hasta que cada instancia esté corregida.
Lo que esto significa en la práctica
Esta asimetría favorece a quien ejecute el próximo scan autónomo primero. Y el próximo objetivo no tiene que ser NGINX. Puede ser cualquier software que corra a escala global, y casi todos tienen subsistemas con lógica interna compleja que nunca fue auditada con esa profundidad.
La defensa perimetral deja de ser opcional. Cuando el tiempo entre descubrimiento y explotación colapsa, no puede depender de "vamos a parchar en la próxima ventana". Necesita capas que filtren el tráfico malicioso antes de que alcance el software vulnerable. Necesita visibilidad sobre lo que está corriendo y dónde. Necesita procesos de patching que funcionen en horas, no en semanas.
El workaround inmediato para el NGINX Rift, las capturas con nombre, es simple y eficaz. Pero es un remendo. El problema estructural es que la velocidad del descubrimiento de vulnerabilidades ahora la gobierna la IA, y la velocidad de la respuesta todavía la gobiernan procesos humanos. Hasta que esa brecha se cierre, el WAF y la defensa en profundidad no son un lujo: son lo único entre su infraestructura y el próximo CVE de 9.2.
Conclusión
El NGINX Rift no es solo otra vulnerabilidad. Es un hito: el momento en que la IA demostró que puede encontrar bugs críticos que 18 años de auditoría humana no encontraron, y lo hizo en una tarde. La pregunta no es si la próxima vulnerabilidad así será descubierta. Es cuándo. Y si su infraestructura estará protegida cuando eso suceda.
En Tech86 construimos nuestro Blindaje Perímetro WAF para ser exactamente esa capa: protección que funciona mientras el parche no llega, reglas que bloquean patrones de explotación antes de que alcancen el software vulnerable, y visibilidad sobre el tráfico que llega a sus servidores. Porque en un mundo donde bugs de 18 años se encuentran en 6 horas, no puede esperar a la próxima ventana de mantenimiento.