NGINX arrastra un fallo serio en su soporte de HTTP/3. El identificador es CVE-2026-42530 y vive en ngx_http_v3_module, el módulo que implementa QUIC. Se trata de un use-after-free: el código vuelve a usar memoria que ya había liberado. Cuando eso ocurre dentro de un proceso worker que atiende conexiones de cualquiera en internet, el problema deja de ser teórico.
El detonante está en la capa QPACK, el mecanismo de compresión de cabeceras de HTTP/3. Un cliente remoto, sin autenticarse, puede construir una sesión HTTP/3 manipulada que reabre un stream del codificador QPACK que ya estaba cerrado. Ese segundo uso toca memoria liberada y el worker se cae. En el peor de los casos, sobre un sistema sin ASLR o con ASLR sorteable, el atacante puede aprovechar la corrupción de memoria para ejecutar código con los privilegios del worker.
A quién afecta
Solo están expuestas las versiones de NGINX Open Source 1.31.0 y 1.31.1 que tengan HTTP/3 (QUIC) activado. La rama 1.31 introdujo cambios en esa parte del código y ahí es donde se coló el fallo. Si tu servidor no escucha en HTTP/3 (es decir, no tienes directivas listen ... quic; ni http3 on;), el módulo vulnerable no entra en juego y este CVE no te afecta. Las ramas estables anteriores tampoco están señaladas en este aviso.
Gravedad
F5, que mantiene NGINX, lo clasifica como crítico. La puntuación CVSS 4.0 es de 9.2, mientras que el cálculo en CVSS 3.1 queda en 8.1 (alta). La diferencia tiene que ver con cómo cada versión del baremo pondera un fallo de red, sin autenticación y con potencial de ejecución de código. El vector de ataque es la red y no requiere credenciales ni interacción de un usuario, aunque la explotación para conseguir RCE depende de condiciones del sistema (sobre todo de que ASLR no esté disponible). El escenario más probable en la práctica es la caída repetida de workers, es decir, denegación de servicio.
Mitigación
La corrección está en NGINX 1.31.2. Actualiza a esa versión o a una posterior y reinicia el servicio. Si por lo que sea no puedes parchear de inmediato, la vía más directa es desactivar HTTP/3 quitando los listeners QUIC de tu configuración y dejando el tráfico sobre HTTP/2 y HTTP/1.1, que no usan el código afectado. Mantener ASLR habilitado en el sistema (lo normal en cualquier distribución reciente) reduce el riesgo de que un fallo así pase de caída a ejecución de código, pero no es un sustituto del parche.
Si gestionas NGINX a través de los paquetes de tu distribución, revisa los avisos de seguridad de tu proveedor: las versiones empaquetadas suelen llevar el número de la rama upstream más un sufijo propio, así que conviene confirmar que el cambio de 1.31.2 está retroportado.
Si quieres contexto sobre otros fallos recientes de NGINX, puedes leer nuestro artículo sobre la inyección man-in-the-middle al hacer proxy a servidores TLS (DSA-6131-1).