NGINX corrige cinco fallos, entre ellos una omisión de TLS y una inyección en HTTP/3
NGINX lanzó las versiones 1.30.6 y 1.31.7 para corregir cinco vulnerabilidades, incluyendo un error de falsificación de sesión TLS y una falla de inyección de solicitudes HTTP/3.
Traducido automáticamente del original en inglés.
NGINX lanzó las versiones 1.30.6 y 1.31.7 el 14 de octubre para abordar cinco vulnerabilidades de seguridad que afectan a su software de servidor web. La actualización, emitida por F5, la empresa detrás de NGINX, incluye correcciones para errores de corrupción de memoria, un problema de falsificación de sesiones TLS y una falla de inyección de datos en HTTP/3. Aunque no se ha reportado explotación activa, los parches son críticos para los administradores que gestionan infraestructuras autoalojadas.
Qué ocurrió
El lanzamiento aborda tres errores de seguridad de memoria que podrían bloquear procesos de trabajo o permitir potencialmente la ejecución remota de código. Estos problemas dependen de la presencia de directivas de configuración específicas, como el uso de alias con reglas de reescritura, mapas de expresiones regulares o E/S asíncrona con Includes del lado del servidor (SSI). F5 calificó estos errores de memoria como críticos con una puntuación CVSS v4.0 de 9.2, señalando que requieren condiciones precisas para ser explotados, pero representan un riesgo significativo si se activan.
Una cuarta vulnerabilidad involucra la rotación automática de claves de tickets de sesión TLS. En configuraciones que utilizan una caché de sesiones compartida sin archivos de claves explícitos, NGINX no inicializaba correctamente todas las ranuras de clave durante la rotación. Este error podría permitir que un atacante falsifique una sesión TLS, evitando potencialmente la verificación del certificado del cliente. F5 describió esta falsificación como no determinista y fuera del control directo del atacante, pero sigue siendo un grave riesgo de omisión de autenticación. La quinta falla afecta a las implementaciones de HTTP/3, permitiendo la inyección de bytes adicionales en solicitudes proxy, lo que podría exceder los límites de tamaño del cuerpo o corromper datos del backend.
Detalles clave
- CVE-2026-15176 es un desbordamiento de pila (heap overflow) provocado por las directivas alias y rewrite, que afecta a las versiones desde la 0.1.29 hasta la 1.31.6.
- CVE-2026-93479 es un desbordamiento de pila en el manejo de mapas de expresiones regulares, presente en las versiones 1.30.0 a 1.30.5 y 1.31.2 a 1.31.6.
- CVE-2026-97205 es un error de uso tras liberación (use-after-free) que involucra E/S asíncrona y páginas SSI, afectando a las versiones desde la 0.8.11 hasta la 1.31.6.
- CVE-2026-95101 permite a los clientes HTTP/3 inyectar bytes adicionales en solicitudes proxy, afectando a las versiones desde la 1.25.0 hasta la 1.31.6.
- CVE-2026-97629 habilita sesiones TLS falsificadas que pueden evitar las comprobaciones de certificados de cliente, afectando a las versiones desde la 1.23.2 hasta la 1.31.6.
- Ninguna de las cinco vulnerabilidades figuraba en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA a fecha del 15 de octubre.
Contexto
NGINX es un servidor web y proxy inverso de alto rendimiento ampliamente utilizado para aplicaciones autoalojadas e infraestructura empresarial. Gestiona la terminación TLS, el balanceo de carga y el servicio de archivos estáticos. Muchos administradores confían en configuraciones predeterminadas o recomendadas, como las cachés de sesiones SSL compartidas, para mejorar el rendimiento permitiendo que los clientes reanuden sesiones sin realizar handshakes completos. Sin embargo, estas optimizaciones pueden introducir complejos problemas de gestión de estado, como se observa en el reciente bug de rotación de claves TLS.
HTTP/3 es la última versión del protocolo HTTP, construida sobre QUIC en lugar de TCP. Ofrece un establecimiento de conexiones más rápido y un mejor rendimiento en redes con pérdida de paquetes. Dado que HTTP/3 es relativamente nuevo en despliegues masivos, su implementación en NGINX aún está madurando. La reciente falla destaca cómo los errores de lógica del analizador sintáctico (parser) en nuevos protocolos pueden conducir a comportamientos inesperados en el manejo de datos, como pasar bytes no intencionados a servicios backend.
Por qué importa
Para los equipos que ejecutan su propio software, estas vulnerabilidades resaltan los riesgos de confiar en configuraciones predeterminadas. La falla de omisión de TLS, por ejemplo, existe exactamente en la configuración de caché de sesiones compartida recomendada en la documentación de NGINX. Los administradores que copiaron estos ejemplos sin comprender el mecanismo subyacente de rotación de claves pueden haber expuesto inadvertidamente sus sistemas a omisiones de autenticación. Esto subraya la necesidad de auditorías regulares de configuración, no solo actualizaciones de software.
Los errores de corrupción de memoria también plantean un riesgo de estabilidad. Un proceso de trabajo bloqueado puede provocar interrupciones del servicio, mientras que la ejecución remota de código podría comprometer todo el host. Dado que NGINX a menudo se sitúa en el borde de la red, exponiéndose a tráfico no confiable, cualquier vulnerabilidad que permita la ejecución de código es particularmente peligrosa. Los equipos deben asegurarse de ejecutar ramas compatibles, ya que versiones antiguas como la 1.28 no reciben estas correcciones a menos que sean portadas hacia atrás (backported) por su distribución.
Qué puedes hacer
- Actualiza inmediatamente a NGINX 1.30.6 en la rama estable o 1.31.7 en la rama principal (mainline).
- Si no puedes actualizar, deshabilita las funciones específicas que provocan cada falla, como apagar aio o eliminar las cachés de sesiones SSL compartidas.
- Ejecuta
nginx -Tpara inspeccionar tu configuración en ejecución buscando directivas arriesgadas como alias con rewrite o ssl_session_cache compartido. - Verifica si tu distribución Linux ha portado hacia atrás los parches si dependes de actualizaciones del gestor de paquetes en lugar de binarios upstream.
- Revisa la configuración de HTTP/3 y considera deshabilitar
proxy_request_bufferingsi no puedes actualizar para mitigar la inyección.



