NGINX publicó las versiones 1.30.6 y 1.31.7 el 14 de octubre para solucionar cinco vulnerabilidades, una de las cuales ha estado presente en todas las versiones desde mayo de 2005. Tres de ellas son errores de memoria que, según F5, la empresa detrás de NGINX, podrían provocar la caída de un proceso trabajador o posiblemente permitir a un atacante ejecutar código; cada una requiere una configuración específica para su explotación.
Una cuarta vulnerabilidad permite a un atacante falsificar una sesión TLS que podría superar las comprobaciones de certificados de cliente, aunque F5 describe la falsificación como no determinista y fuera del control del atacante. La quinta permite a un cliente HTTP/3 introducir bytes adicionales en una solicitud que NGINX reenvía a un backend.
Ninguna de las cinco estaba en el catálogo de vulnerabilidades explotadas conocidas de CISA al 15 de octubre, y ni NGINX ni F5 informan de ataques. NGINX las califica a todas como de gravedad media. F5 puntúa los tres errores de memoria con 9.2, crítico, en CVSS v4.0, el fallo TLS con 8.3 y el de HTTP/3 con 6.9.
Qué configuraciones están expuestas
Cada una de las cinco requiere una directiva añadida: un alias con una reescritura, un mapa de expresiones regulares, AIO con SSI, una caché de sesiones TLS compartida o HTTP/3. La documentación de NGINX recomienda la caché de sesiones compartida y el almacenamiento en búfer de solicitudes; la otra condición para el fallo HTTP/3 está activada por defecto.
El fallo TLS se encuentra en la rotación automática de las claves de tickets de sesión. Los tickets de sesión permiten a un cliente reanudar una sesión TLS sin un handshake completo, y desde la versión 1.23.2, de octubre de 2022, una caché de sesiones compartida hace que NGINX genere y rote las claves de ticket por sí mismo, a menos que se carguen claves desde un archivo.
Cada proceso trabajador mantiene una copia de tres ranuras de claves. La rotación solo copiaba dos, por lo que la tercera ranura contenía lo que hubiera en memoria previamente, y un ticket que nombrara esa ranura podía verificarse y descifrarse con ese material de clave no inicializado, "permitiendo una sesión falsificada", según el commit de corrección.
F5 afirma que la falsificación funciona "de manera no determinista que está fuera del control del atacante", y que un atacante podría usarla para eludir la verificación de certificados de cliente. La configuración expuesta, ssl_session_cache shared:SSL:10m, es la que utiliza la documentación de NGINX en su configuración de ejemplo. NGINX corrigió un fallo de reutilización de sesión con la misma consecuencia, CVE-2025-23419, en febrero de 2025.
Las condiciones y soluciones alternativas a continuación son de NGINX y F5. Los rangos de versiones provienen de la página de avisos de NGINX.
Un fallo se remonta a la corrección de julio
El fallo del mapa, CVE-2026-93479, está en el código de manejo de cadenas que NGINX parcheó el 15 de julio para CVE-2026-42533, un desbordamiento de montón que F5 puntuó con 9.2 y al que se llega a través de las capturas de un mapa de expresiones regulares.
El nuevo desbordamiento se hizo posible tras un cambio en esa versión de julio, según el commit de corrección. Un parche de julio añadió protección contra el desbordamiento de un búfer, pero los datos aún podían derramarse en un área reservada, y un segundo parche de julio luego dimensionó la cadena final a partir de esa longitud derramada, por lo que la cadena podía superar su búfer.
El commit impone límites. El desbordamiento es como máximo del tamaño del área reservada en la ruta del documento raíz, y de un solo byte nulo en la ruta del registro de acceso.
El aviso de F5 y la página de avisos de NGINX enumeran 1.30.0 y 1.31.2 como las primeras versiones afectadas, que son anteriores al cambio de julio. Un servidor parcheado en julio está dentro del rango afectado de todos modos.
La solución alternativa de F5 de julio ya había sido cuestionada. El investigador Stan Shaw dijo a The Hacker News en julio que cambiar a capturas con nombre dejaba abierta una ruta más estrecha, y que actualizar era "la única solución completa".
Los commits de corrección de los fallos de alias, AIO y HTTP/3 describen los otros tres errores. El fallo de alias se abre en el momento en que una reescritura cambia la URI de una solicitud y antes de que NGINX elija la siguiente ubicación. Si algo lee $request_filename en esa ventana, y el prefijo de la ubicación es más largo que la URI reescrita, el mapeo de la URI a una ruta de archivo desborda un búfer.
El fallo de AIO es un contador. Cada operación asíncrona pendiente en una solicitud suma uno a un campo de 8 bits sin comprobación, por lo que 256 operaciones pendientes lo desbordan a cero y la solicitud puede liberarse mientras esas operaciones aún apuntan a su memoria. NGINX señala como desencadenante las páginas SSI con comandos include virtual, que pueden ejecutar sus solicitudes incluidas en paralelo.
El fallo de HTTP/3 provino de un campo del analizador que hacía dos funciones: mantener la longitud restante de un frame desconocido que se estaba omitiendo y el número de bytes DATA que se pasarían como cuerpo de la solicitud. Cuando un frame desconocido se dividía en dos lecturas, el recuento sobrante se trataba como cuerpo y se enviaba al backend, fuera de la comprobación de client_max_body_size.
Qué hacer
Actualice a 1.30.6 en la rama estable o a 1.31.7 en la principal. La versión estable solo contiene correcciones. NGINX publica correcciones solo para esas dos ramas, por lo que las ramas más antiguas como 1.28 permanecen dentro de los rangos afectados, y un paquete de distribución solo está corregido si su distribución ha aplicado los parches.
Los clientes de NGINX Plus y los usuarios de los productos Ingress Controller, Gateway Fabric, Instance Manager y WAF de F5 deben consultar los avisos de F5, que enumeran las compilaciones afectadas y, para varios productos, ninguna compilación corregida al 15 de octubre.
Si aún no puede actualizar, la tabla anterior contiene la solución alternativa de F5 para cada fallo. Para ver qué rutas tiene habilitadas su servidor, imprima la configuración en ejecución con nginx -T y búsquela para alias junto a rewrite, un mapa de expresiones regulares usado por root o log_format, aio junto con ssi, líneas listen con quic y ssl_session_cache shared sin ssl_session_ticket_key.
El desbordamiento del módulo de reescritura que NGINX parcheó en mayo, CVE-2026-42945, estaba siendo explotado a los pocos días de su divulgación, según VulnCheck. Esta es la octava versión de seguridad de NGINX en 2026.
F5 acredita a Matt Suiche de Tolmo y Mateusz Gierblinski por el fallo del mapa, a Hansol Lee de GOTROOT por el fallo HTTP/3, a PhiNode Labs por el fallo TLS y a un investigador al que nombra como Cyberlanc3r por el fallo AIO.
F5 encontró el fallo de alias por sí misma. NGINX también lanzó njs 1.0.2 el mismo día, corrigiendo dos fallos de gravedad media en el manejo de XML en su módulo JavaScript, CVE-2026-101025 y CVE-2026-101019.
Deja una respuesta