Actualizaciones de seguridad de F5 ante CVE críticas en NGINX

La empresa F5 ha publicado actualizaciones de seguridad que corrigen dos vulnerabilidades críticas en NGINX Open Source y productos relacionados. Ambas vulnerabilidades — CVE-2026-42530 y CVE-2026-42055 — han recibido una puntuación CVSS v4 9.2 y permiten que un atacante remoto no autenticado logre la ejecución de código arbitrario bajo determinadas configuraciones. Se ve afectado un amplio abanico de productos: desde NGINX Open Source y NGINX Plus hasta NGINX Ingress Controller, Gateway Fabric, Instance Manager y componentes WAF/DoS. Se recomienda a los administradores actualizar de inmediato las instalaciones afectadas a las versiones corregidas o aplicar las medidas de mitigación propuestas.

Análisis técnico de las vulnerabilidades

CVE-2026-42530: use-after-free en el módulo HTTP/3

Se ha descubierto una vulnerabilidad de tipo use-after-free en el módulo ngx_http_v3_module. Según el boletín de seguridad de F5, la explotación es posible cuando NGINX está configurado para utilizar el módulo HTTP/3 QUIC. Un atacante puede volver a abrir el flujo QPACK encoder mediante una sesión HTTP/3 especialmente diseñada, lo que provoca el acceso a una región de memoria ya liberada. La ejecución de código arbitrario es posible en sistemas con el mecanismo ASLR (Address Space Layout Randomization) desactivado o si el atacante dispone de un método para eludir ASLR.

Productos afectados:

• NGINX Open Source 1.31.0 – 1.31.1 (corregido en 1.31.2)
• NGINX Gateway Fabric 2.0.0 – 2.6.3 (corregido en 2.6.4)
• NGINX Gateway Fabric 1.3.0 – 1.6.2 (la versión corregida no se indica)
• NGINX Instance Manager 2.17.0 – 2.22.0 (la versión corregida no se indica)
• NGINX Ingress Controller 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0 (las versiones corregidas no se indican)

CVE-2026-42055: desbordamiento de búfer en heap en módulos HTTP/2

La segunda vulnerabilidad representa un desbordamiento de búfer en heap (heap-based buffer overflow) en los módulos ngx_http_proxy_v2_module y ngx_http_grpc_module. Tal y como se indica en el boletín correspondiente de F5, para su explotación deben cumplirse simultáneamente varias condiciones: uso de la directiva proxy_http_version 2 o grpc_pass para el proxy de tráfico HTTP/2, establecimiento de la directiva ignore_invalid_headers en el valor off, así como un tamaño del búfer large_client_header_buffers superior a 2 MB. Al igual que en la primera vulnerabilidad, la ejecución de código es posible cuando el mecanismo ASLR está desactivado o se consigue sortear ASLR.

Esta vulnerabilidad afecta a una lista de productos significativamente más amplia:

• NGINX Open Source 1.31.1 (corregido en 1.31.2)
• NGINX Open Source 1.30.0 – 1.30.2 (corregido en 1.30.3)
• NGINX Plus 37.0.0 – 37.0.1 (corregido en 37.0.2.1)
• NGINX Plus R33 – R36 (corregido en R36 P6)
• NGINX Gateway Fabric 2.0.0 – 2.6.3 (corregido en 2.6.4)
• NGINX Gateway Fabric 1.3.0 – 1.6.2
• NGINX Instance Manager 2.17.0 – 2.22.0
• F5 WAF for NGINX 5.9.0 – 5.13.1
• NGINX App Protect WAF 4.10.0 – 4.16.0, 5.2.0 – 5.8.0
• F5 DoS for NGINX 4.9.0
• NGINX App Protect DoS 4.3.0 – 4.7.0
• NGINX Ingress Controller 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0

Las entradas en el registro CVE están disponibles en los siguientes enlaces: CVE-2026-42530 y CVE-2026-42055.

Evaluación del riesgo real

A pesar de las altas puntuaciones CVSS 9.2, la explotación práctica de ambas vulnerabilidades está limitada por varios factores. Para CVE-2026-42530 es necesario que el módulo HTTP/3 QUIC esté activado en la configuración, una funcionalidad que sigue sin ser estándar en la mayoría de los despliegues de NGINX. Para CVE-2026-42055 se requiere una combinación aún más específica: proxy de HTTP/2, desactivación explícita de la validación de cabeceras y un tamaño de búfer inusualmente grande. Además, en ambos casos la ejecución de código depende de que ASLR esté desactivado o de la posibilidad de sortearlo; en los sistemas Linux modernos, ASLR está activado por defecto.

F5 no informa de casos de explotación de estas vulnerabilidades en ataques reales. Ninguna de las CVE se ha incluido en el catálogo CISA KEV. No obstante, los productos F5 y NGINX han sido históricamente un objetivo atractivo para los atacantes debido a su amplia implantación como servidores proxy inversos, balanceadores de carga y puntos de entrada a redes corporativas y clústeres de Kubernetes.

Las organizaciones que utilizan NGINX en entornos Kubernetes a través de NGINX Ingress Controller o NGINX Gateway Fabric deben prestar especial atención: la compromisión de estos componentes puede otorgar al atacante acceso a todo el tráfico que atraviesa el clúster.

Recomendaciones para la remediación

La acción prioritaria es actualizar a las versiones corregidas:

• NGINX Open Source: actualizar a 1.31.2 (mainline) o 1.30.3 (stable)
• NGINX Plus: actualizar a 37.0.2.1 o instalar R36 P6
• NGINX Gateway Fabric: actualizar a 2.6.4

Si no es posible actualizar de inmediato, F5 propone las siguientes medidas de mitigación:

• Para CVE-2026-42530: desactivar HTTP/3 en la configuración de NGINX
• Para CVE-2026-42055: eliminar la directiva ignore_invalid_headers off de la configuración (por defecto la validación de cabeceras está activada) o reducir el tamaño de large_client_header_buffers a un valor inferior a 2 MB

Para una serie de productos afectados — NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS y algunas ramas de Ingress Controller — las versiones corregidas aún no se indican en los boletines. Los administradores de estos productos deben seguir las actualizaciones de los boletines K000161616 y K000161584 y, como medida temporal, aplicar los cambios de configuración descritos anteriormente.

Teniendo en cuenta el nivel crítico de las vulnerabilidades y la amplia lista de productos afectados, las organizaciones deberían, en primer lugar, realizar una auditoría de las configuraciones de NGINX para detectar el uso de HTTP/3 QUIC y ajustes no estándar de proxy de HTTP/2, y después planificar la actualización dentro de la próxima ventana de mantenimiento. En los despliegues sobre Kubernetes, debe priorizarse la actualización de Ingress Controller y Gateway Fabric, dado que estos componentes procesan todo el tráfico entrante del clúster.