Alerta crítica: dos fallos de alta severidad en NGINX Open Source permiten ejecución remota de código sin autenticación (CVSS 9.2) y requieren parcheo inmediato

F5 ha publicado parches críticos para dos fallos de seguridad en NGINX Open Source que, en determinadas condiciones, permiten la ejecución remota de código sin necesidad de autenticación. Se trata de vulnerabilidades de gravedad alta (CVSS 9.2) que afectan a módulos usados para HTTP/3/QUIC y para el proxy de HTTP/2/gRPC, y deben considerarse urgentes por los equipos de operaciones y seguridad que gestionan puertas de enlace, balanceadores o controladores Ingress basados en NGINX.

La primera vulnerabilidad (CVE-2026-42530) es un use-after-free en el módulo ngx_http_v3_module que puede activarse mediante sesiones HTTP/3 especialmente construidas para forzar la reapertura de un flujo QPACK. La segunda (CVE-2026-42055) es un desbordamiento de búfer en heap que afecta a ngx_http_proxy_v2_module y ngx_http_grpc_module cuando se proxifica tráfico HTTP/2 bajo ciertas directivas y tamaños de buffer de cabeceras muy grandes. En ambos casos los escenarios de explotación permiten ejecución remota de código en sistemas donde la protección ASLR está desactivada o puede ser sorteada por el atacante, lo que amplifica el riesgo en appliances o imágenes preconfiguradas que no siguen las hardening modernos.

F5 publicó correcciones que deben aplicarse cuanto antes: NGINX Open Source recibió fixes en las ramas 1.30.x y 1.31.x (la 1.31.2 y la 1.30.3 contienen los parches), mientras que NGINX Plus y las ediciones gestionadas por F5 tienen versiones con remediaciones equivalentes. También se han actualizado componentes relacionados como NGINX Gateway Fabric, Instance Manager, App Protect y controladores Ingress en los rangos afectados. Revisa las notas de seguridad oficiales de NGINX y las comunicaciones de F5 para confirmar la versión concreta que aplica a tu despliegue: NGINX security advisories y F5 Product Security.

Que no haya menciones públicas de explotación activa no debe llevar a la complacencia. La historia reciente muestra que fallos críticos en el ecosistema NGINX y F5 han sido aprovechados en poco tiempo tras su divulgación pública, por lo que las organizaciones deben asumir una ventana de riesgo realista entre publicación y parcheo masivo. Si tu instancia NGINX es accesible desde Internet o se encarga de tráfico de API/gRPC, trátala como de máxima prioridad.

En cuanto a medidas prácticas, comienza por identificar todos los puntos donde se ejecuta NGINX: appliances físicos, máquinas virtuales, contenedores (especialmente controladores Ingress en Kubernetes) y servicios gestionados. Comprueba las versiones con los mecanismos habituales (por ejemplo, nginx -v en sistemas donde sea posible) y organiza un plan de despliegue de parches que incluya pruebas en entorno de staging para evitar regresiones. Si el parche no puede aplicarse de inmediato, existen mitigaciones temporales: deshabilitar HTTP/3 para mitigar el fallo en el módulo QPACK y retirar la configuración ignore_invalid_headers off o reducir el tamaño de large_client_header_buffers por debajo de 2 MB para reducir la exposición del desbordamiento en el proxy/gRPC. Estas mitigaciones deben implementarse con cuidado y probadas, porque pueden afectar compatibilidad o rendimiento.

Más allá del parcheo y mitigación de configuración, monitoriza señales de explotación como reinicios inesperados, procesos nginx que mueren tras tráfico anómalo, y patrones de cabeceras o sesiones QUIC/HTTP/3 inusuales. Actualiza las reglas del WAF y las firmas IDS/IPS para captar intentos de abuso, y mantén políticas de red que minimicen la exposición pública de instancias administradas si no es necesario. Si administras clusters Kubernetes, prioriza la actualización de Ingress Controllers y revisa imágenes base para asegurarte de que el ASLR y otras protecciones del kernel estén habilitadas en los nodos.

Si detectas indicios de compromiso, aísla la instancia afectada, captura memoria y volcado de procesos para análisis forense, rota credenciales vinculadas y considera restaurar desde imágenes previas limpias después de la investigación. Además, comunica internamente el riesgo a propietarios de aplicaciones y planifica una lección aprendida para evitar dependencias no parcheadas en el futuro. Para contexto general sobre gestión de vulnerabilidades y catálogos CVE puedes consultar recursos de referencia como MITRE: CVE - MITRE.

En resumen, actúa con rapidez: identifica activos, valida versiones, parchea a la mayor brevedad posible o aplica mitigaciones probadas, y refuerza la detección y respuesta. La combinación de fallos de ejecución remota y la precedente explotación rápida en el ecosistema hacen de estas vulnerabilidades un riesgo operativo real que requiere atención coordinada entre equipos de redes, plataformas y seguridad.