F5 NGINX: dos RCE sin autenticacion parcheados de emergencia (HTTP/3 y HTTP/2)

Contexto del incidente

El 17 de junio de 2026 F5 publico el advisory de seguridad K000161614 fuera de calendario, un out-of-band que la empresa no tenia previsto y que llega despues de que el equipo de NGINX detectara, en revision interna, dos fallas de manejo de memoria que se pueden gatillar de forma remota y sin autenticacion. La divulgacion publica coordinada con medios se hizo al dia siguiente, 18 de junio, y los CVEs ya estan reservados en NVD con assessment pendiente de enriquecimiento pero con la descripcion oficial del CNA de F5. CVE-2026-42530 y CVE-2026-42055 comparten el mismo puntaje CVSS v4.0 de 9.2 (Critical), vector CVSS:4.0/AV:N/AC:L/PR:N/UI:N en ambos casos, y la misma conclusion: cualquier sistema con NGINX expuesto a internet que tenga el modulo HTTP/3 activo, o que use proxy HTTP/2 con large_client_header_buffers por encima de 2 MB, puede ser tomado con un unico request malicioso.

El CVE-2026-42530 es un use-after-free en el modulo ngx_http_v3_module. Cuando NGINX esta configurado con listen ... http3 y procesa QUIC, el encoder QPACK maneja streams internos que pueden ser reabiertos por un cliente remoto con un handshake HTTP/3 especialmente armado. Esa reapertura del stream hace que NGINX libere la estructura de encoder y despues la siga usando en una operacion posterior, lo que desemboca en escritura fuera de los limites del heap del worker. En la mayoria de los sistemas modernos eso termina en crash y restart, pero si el atacante logra bypass de ASLR (algo cada vez mas viable con las tecnicas de KASLR bypass de 2025-2026 que andan dando vueltas en repositorios publicos) el mismo primitive le permite plantar codigo y obtener RCE como el usuario que corre el worker de NGINX, tipicamente nginx o nobody. La superficie es todo NGINX Open Source 1.31.0 y 1.31.1 (parcheado en 1.31.2) mas la familia de productos F5 que embeben ese modulo: NGINX Gateway Fabric 2.0.0-2.6.3 (parche en 2.6.4), NGINX Instance Manager 2.17.0-2.22.0, y los NGINX Ingress Controller 3.5.0-3.7.2, 4.0.0-4.0.1, y 5.0.0-5.5.0.

El CVE-2026-42055, en paralelo, es un heap-based buffer overflow en ngx_http_proxy_v2_module y ngx_http_grpc_module. Se gatilla cuando NGINX hace de proxy hacia arriba con proxy_http_version 2 o grpc_pass (trafico HTTP/2), el ignore_invalid_headers esta en off (el default en Plus, no asi en Open Source clasico) y large_client_header_buffers esta dimensionado con buffers individuales de mas de 2 MB. Un atacante remoto no autenticado puede mandar headers que excedan ese tamano durante la creacion del upstream request y desbordar el buffer. Mismo escenario: crash de worker y restart en el caso facil, RCE en el caso con bypass de ASLR. Afecta a NGINX Plus 37.0.0-37.0.1 (parche en 37.0.2.1), R33-R36 (parche en R36 P6), NGINX Open Source 1.30.0-1.30.2 (parche en 1.30.3) y 1.31.1 (parche en 1.31.2), mas F5 WAF for NGINX 5.9.0-5.13.1, NGINX App Protect WAF 5.2.0-5.8.0 y 4.10.0-4.16.0, F5 DoS for NGINX 4.9.0, y los mismos Gateway Fabric e Ingress Controller.

En el mismo batch de advisories F5 tambien revelo CVE-2026-11311 y CVE-2026-50107 (severidad alta, NGINX Gateway Fabric 2.3.0-2.6.3) y CVE-2026-48142 (severidad media, ngx_http_charset_module). El patron de fondo es claro: F5 viene de un 2025-2026 duroisimo en NGINX, con CVE-2026-42945 (alias NGINX Rift, CVSS 9.2) explotado en produccion a dias de su divulgacion en mayo. Esta vez la empresa no espero al ciclo mensual y saco el OOB antes de que aparecieran PoCs publicos, pero la ventana para los atacantes es la misma de siempre: con el codigo ya en mirror publico de NGINX, los primeros exploits funcionales suelen aparecer entre 24 y 72 horas.

NGINX corre en casi todo internet: si vos administras un edge, un ingress de Kubernetes o un reverse proxy, este es el parche que no podes dejar para la proxima ventana de mantenimiento.

Como proteger tu infraestructura?

1. Aplica los parches a la familia 1.30.x / 1.31.x / R36 hoy mismo

La ruta feliz es actualizar. Para NGINX Open Source, sali de 1.30.0-1.30.2 o 1.31.0-1.31.1 y anda a 1.30.3 o 1.31.2 respectivamente. Para NGINX Plus, 37.0.0-37.0.1 hacia 37.0.2.1, o R33-R36 hacia R36 P6. Si usas NGINX Gateway Fabric, tu target es 2.6.4 sobre Kubernetes; para los Ingress Controller, K8s rolling update a las versiones con parche. Antes de hacer el upgrade, sacate una foto de nginx -V, la config activa, y un backup de /etc/nginx/ y /var/cache/nginx/. La compilacion en el caso de Open Source conviene hacerla con la misma toolchain que usaste originalmente (Alpine con musl, Debian con glibc, etc.) porque cambiar la libc en un upgrade de seguridad es receta para symbol mismatches en modulos dinamicos de terceros.

2. Si no podes parchear ya, mitiga la superficie de ataque

Para CVE-2026-42530, lo mas efectivo es desactivar HTTP/3. Si tu listen tiene http3 en algun bloque server, comenta esa linea, recarga con nginx -s reload y HTTP/3 deja de existir como vector. Tu sitio sigue sirviendo HTTP/1.1 y HTTP/2 sobre TCP, que es como se usa la enorme mayoria del trafico web. Para CVE-2026-42055, ajusta dos directivas: pone large_client_header_buffers 4 8k; (o lo mas bajo posible, idealmente debajo de 1 MB) y ignore_invalid_headers on; en todos los bloques donde usas proxy_http_version 2 o grpc_pass. Con esos dos cambios, el overflow deja de ser reproducible aunque la version siga siendo vulnerable. Si tu cadena upstream depende si o si de large_client_header_buffers por encima de 2 MB (caso tipico: APIs que reciben JWTs grandes o SOAP con headers verbosos), aisla esa ruta en un bloque server dedicado y ponele un if ($http_x_large_request) { return 413; } para bloquear el patron malicioso antes de que llegue al buffer.

3. Segmenta y detecta: aunque el RCE parezca lejano, los IoCs son cazables

El vector HTTP/3 de CVE-2026-42530 requiere que el atacante complete un handshake QUIC y dispare la reapertura del stream QPACK, lo que en logs se ve como un SSL_do_handshake exitoso seguido por un stream reset o un stop_sending sobre el stream encoder. Si tenes NGINX detras de un reverse proxy tipo HAProxy o Envoy, mira los logs de QUIC: picos de handshake_failed con transport_error_code=APPLICATION_ERROR o NO_ERROR accompanied de errores de memoria en /var/log/nginx/error.log (SIGSEGV, SIGABRT, malloc debug logs) son la huella del intento. Para CVE-2026-42055, la senal esta en error.log: cualquier upstream sent too big header combinado con un worker process exited on signal en la misma ventana de 100 ms es la firma del overflow gatillandose. Suma un WAF delante (Cloudflare, AWS WAF, F5 ASM/AWAF, Coraza) con una regla que limite request line > 16 KB o header > 8 KB: el 99% del trafico legitimo cabe ahi, y el overflow queda bloqueado antes de tocar NGINX.

4. Audita la cadena de supply chain de tu NGINX

El parche de F5 cubre los modulos upstream, pero la mayoria de las instalaciones reales cargan modulos dinamicos de terceros (ngx_brotli, nginx-module-vts, set-misc-nginx-module, headers-more-nginx-module, etc.) que compilan contra headers internos de NGINX. Si los binarios no se recompilaron contra 1.31.2, vas a ver errores unknown directive o version mismatch al hacer nginx -t. La forma prolija es rebuild full: bajar el source de nginx-release-1.31.2, aplicar el parche de los modulos de terceros, recompilar con el mismo configure arguments que tu instalacion actual, y reinstalar. En Kubernetes con Ingress Controller, lo mas rapido es bumpear la chart de ingress-nginx a una release que ya traiga NGINX 1.31.2 o NGINX Plus R36 P6 en la imagen base. Si tu CI/CD tarda mas de 48 h en propagar la nueva imagen a todos los clusters, asume que tenes una ventana de exposicion del tamano de tu pipeline y pone un WAF con rate limit agresivo mientras tanto.

Indicadores de compromiso (IoCs)

• Logs de error con SIGSEGV o SIGABRT en el mismo segundo que SSL_do_handshake() exitoso: huella del use-after-free de CVE-2026-42530 disparandose desde un handshake HTTP/3 malformado.
• Patron upstream sent too big header seguido de worker process exited on signal 11 en menos de 100 ms: firma del heap overflow de CVE-2026-42055, casi siempre con un unico request.
• Picos de QUIC handshake_failed con transport_error_code=APPLICATION_ERROR o NO_ERROR en HAProxy/Envoy logs: intento de exploit HTTP/3 que no llego a NGINX pero que muestra reconocimiento y probing.
• Restarts de NGINX worker en bucle (cada 5-30 s) sin aumento de carga: crash loop inducido por overflow repetido. F5 reporto este patron en su PoC interno.
• Procesos hijos inesperados spawneados por el usuario nginx o nobody (/bin/sh -c, curl, wget a IPs externas): etapa de post-explotacion si el RCE concreto fue exitoso.
• Conexiones salientes al puerto 53 o 443 desde el host NGINX hacia IPs en ASN conocidos de bulletproof hosting (AS9009, AS208091, AS204957): callback del payload una vez que el heap fue re-escrito.
• Archivos nuevos en /var/lib/nginx/ o /tmp/ con nombres random de 8-12 chars (ej: a8f3d9c1.so, xk4m2.sh): shared objects maliciosos cargados via LD_PRELOAD durante el RCE.

Deteccion rapida: queries y reglas

Para Suricata o Snort 3, una firma de capa aplicacion que mira patrones HTTP/3 sobre UDP 443 puede detectar el probing pre-exploit:

alert udp any any -> $HOME_NET 443 (msg:"IPSN F5 NGINX CVE-2026-42530 HTTP/3 QPACK stream reset probing";
  flow:to_server; dsize:>1200; content:"|06|"; offset:0; content:"Q"; offset:8;
  pcre:"/stream_reset_after_handshake/i";
  classtype:attempted-admin; sid:2026425301; rev:1;)

Para Splunk / Elastic, una query de hunting que corre contra /var/log/nginx/error.log y correlaciona los dos senales de heap overflow en una ventana de un segundo:

index=nginx error_type=crash (worker_signal=11 OR worker_signal=6)
| join type=inner _time
    [ search index=nginx "upstream sent too big header" ]
| stats count by src_ip, host, _time
| where count > 1
| eval alert_name="CVE-2026-42055 probable RCE attempt"
| table _time, host, src_ip, count, alert_name

Y para un WAF delante de NGINX, la regla mas efectiva es limitar el tamano total de headers a 8 KB. Eso solo bloquea el vector de CVE-2026-42055 sin afectar trafico legitimo:

# nginx (modsecurity o similar) - bloquear request con headers > 8 KB
SecRequestBodyNoFilesLimit 8192
SecRule REQUEST_HEADERS:@size "> 8192" "id:2026420551, phase:1, deny, status:413,
  log, msg:'CVE-2026-42055 large_client_header_buffers overflow attempt blocked'"

Por que este OOB importa mas que otros

El patron que se repite en F5 desde mayo de 2026 (NGINX Rift, ahora este batch) es que cada OOB que sacan cubre fallas con un denominador comun muy alto: el modulo HTTP/3 QPACK y el proxy HTTP/2. Eso es sintoma de que la superficie de testing de F5 sobre esos modulos no esta al nivel de la superficie de ataque real, y los parches siguen llegando tarde (NGINX Rift se exploto en produccion a dias de divulgacion). Para equipos que corren NGINX en produccion, esto justifica un cambio de postura: tratar el modulo HTTP/3 como opt-in y no como default, y forzar large_client_header_buffers debajo de 1 MB salvo justificacion documentada. Si tu negocio depende de HTTP/3 (live streaming, gaming, IoT) y no podes apagarlo, asume que vas a estar en el primer lote de targets apenas salga el proximo PoC.

Mirada IPSN

Desde la trinchera de operaciones, los dos CVEs de F5 NGINX del 17/06 nos pegan de lleno en el tipo de riesgo que vemos todos los dias: software ubiquitous con una falla de memoria gatillable pre-auth, vendor que responde rapido pero tarde para el atacante, y una ventana de 24-72 horas hasta el primer PoC. En IPSN tenemos a varios clientes con NGINX expuesto a internet (e-commerce, APIs publicas, gateways de Kubernetes) y el playbook es el mismo: parchar hoy si se puede, mitigacion con listen y large_client_header_buffers si no, y WAF delante como red de seguridad. Si tenes NGINX en produccion y queres que te auditemos la config o te apliquemos las mitigaciones, escribinos por la pagina de contacto y lo coordinamos en el dia.