Qué corrigen nginx 1.30.6 y 1.31.7
Ambas versiones salieron el mismo día, el 14 de octubre de 2026, en la página de noticias de nginx.org. Corrigen cinco fallos del proceso worker: tres corrupciones de memoria, una inyección de datos en el cuerpo de las peticiones HTTP/3 y una falsificación de sesión TLS. Una versión mainline 1.31.8 salió el 21 de octubre de 2026; su anuncio no menciona ninguna vulnerabilidad, pero sucede a la 1.31.7 y, por tanto, contiene sus correcciones.
Sobre la gravedad conviven dos lecturas, y hay que citarlas tal cual. La página de avisos de seguridad de nginx.org clasifica los cinco fallos con severidad «medium». Las fichas CVE publicadas por F5, el editor de nginx, asignan una puntuación CVSS 3.1 de 8,1 a tres de ellos. Precisan el escenario: el worker se cae y se reinicia, y sigue siendo posible una ejecución de código si ASLR está desactivado o se elude. Todos exigen una configuración concreta para ser explotables. Eso es lo que hace rentable el inventario: en un parque, parte de los servidores simplemente no está afectada.
Los cinco fallos y lo que le expone
- CVE-2026-15176, alias y rewrite — desbordamiento de heap en el worker cuando una
locationcombinaalias,rewritey una directivasetoreturnque lee$request_filename, o cuando$request_filenameaparece en unlog_format. Rango vulnerable: de 0.1.29 a 1.31.6. - CVE-2026-93479, cadenas con variables — desbordamiento al calcular la raíz de documentos o al registrar, típicamente un
mapcon regex cuyas capturas$1,$2leerooto unlog_formatantes de la variable de salida. Rango vulnerable: 1.30.0 a 1.30.5 y 1.31.2 a 1.31.6. - CVE-2026-95101, cuerpo de petición HTTP/3 — parte de una trama desconocida puede leerse como cuerpo de la petición: elusión de
client_max_body_sizeo inyección en la petición reenviada, conproxy_request_buffering on, el valor por defecto. Rango vulnerable: de 1.25.0 a 1.31.6. - CVE-2026-97629, tickets de sesión TLS — con
ssl_session_cache shared:…y sinssl_session_ticket_key, nginx rota sus claves por sí mismo; una de ellas quedaba sin inicializar, lo que permite falsificar una sesión y, según F5, eludir la verificación de un certificado de cliente. Rango vulnerable: de 1.23.2 a 1.31.6. - CVE-2026-97205, SSI con AIO — use-after-free cuando
aioestá activo y una página SSI contiene comandosinclude virtual. Rango vulnerable: de 0.8.11 a 1.31.6. - Severidad publicada — «medium» para los cinco en nginx.org. Según las fichas CVE de F5, la puntuación CVSS 3.1 es 8,1 para CVE-2026-15176, CVE-2026-93479 y CVE-2026-97205, 6,5 para CVE-2026-97629 y 5,3 para CVE-2026-95101.
Versiones afectadas y versiones corregidas
Desplace la tabla
| Fallo o paquete | Versiones vulnerables | Corregido en |
|---|---|---|
| CVE-2026-15176 — alias y rewrite | 0.1.29 a 1.31.6 | 1.30.6 y 1.31.7 |
| CVE-2026-93479 — cadenas con variables | 1.30.0 a 1.30.5, 1.31.2 a 1.31.6 | 1.30.6 y 1.31.7 |
| CVE-2026-95101 — HTTP/3 | 1.25.0 a 1.31.6 | 1.30.6 y 1.31.7 |
| CVE-2026-97629 — tickets TLS | 1.23.2 a 1.31.6 | 1.30.6 y 1.31.7 |
| CVE-2026-97205 — SSI con AIO | 0.8.11 a 1.31.6 | 1.30.6 y 1.31.7 |
| Paquete Debian 13 (trixie) | Paquetes anteriores a `1.26.3-3+deb13u10` | `1.26.3-3+deb13u10` (DSA-6575-1) |
| Paquete Debian 12 (bookworm) | Marcado vulnerable a 22 de octubre de 2026 | Aún no publicado |
| Paquetes Ubuntu | «Needs evaluation» a 22 de octubre de 2026 | Aún no publicado |
Paquete de distribución o Docker: el número no basta
Es la objeción más frecuente en un parque heterogéneo: nginx -v muestra 1.26.3 o 1.22.1, muy por debajo de 1.30.6, y sin embargo la máquina puede estar corregida. Las distribuciones retroportan las correcciones de seguridad a su propia rama sin cambiar el número upstream: solo cambia el sufijo del paquete. Debian lo hizo para trixie con el aviso DSA-6575-1, que cubre los cinco CVE. En cambio, a 22 de octubre de 2026, el seguimiento de seguridad de Debian aún marcaba bookworm como vulnerable, y Ubuntu mostraba «Needs evaluation» para todas sus versiones seguidas.
La única comprobación fiable es, por tanto, el changelog del paquete instalado: zgrep -l CVE-2026-15176 /usr/share/doc/nginx*/changelog.Debian.gz en Debian o Ubuntu, rpm -q --changelog nginx | grep CVE-2026-15176 en RHEL, AlmaLinux o Rocky. Una línea encontrada significa que la corrección está retroportada; nada en absoluto significa que todavía no lo está. Para Docker, lo que cuenta es la etiqueta: las imágenes oficiales nginx:1.30.6 y nginx:1.31.7 están disponibles en Docker Hub, y una imagen fijada en una etiqueta anterior sigue siendo vulnerable mientras no se sustituya.
Inventariar la exposición de un servidor en diez minutos
Anotar la versión y la procedencia
nginx -vda la versión del binario. La procedencia del paquete decide el procedimiento de actualización:apt-cache policy nginxen Debian o Ubuntu (repositorio nginx.org o distribución)rpm -qi nginx | grep -E 'Version|Release|Vendor'en RHEL y derivadas
Si nginx corre en un contenedor:docker ps | grep -i nginx.Listar los módulos compilados
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|ssi|threads|file-aio'
Sin--with-http_v3_module, CVE-2026-95101 no le afecta. El módulo SSI se compila por defecto: solo la opción--without-http_ssi_modulelo excluye.Exportar la configuración efectiva
sudo nginx -T > /root/nginx-conf.txt 2>&1nginx -Tprueba la configuración y la imprime entera, incluidos los archivos incluidos. Consulte este archivo en lugar de recorrer/etc/nginxa mano: basta unincludeolvidado para pasar por alto una directiva.Buscar alias y $request_filename (CVE-2026-15176)
grep -nE '^\s*(alias|rewrite)\s' /root/nginx-conf.txtgrep -n 'request_filename' /root/nginx-conf.txt
Está expuesto si una mismalocationcombinaalias,rewritey unsetoreturnque lee$request_filename, o si unlog_formatcontiene esa variable.Buscar los map con regex (CVE-2026-93479)
grep -nA8 '^\s*map ' /root/nginx-conf.txt
Localice las entradas que empiezan por~y busque$1,$2en las directivasrootylog_format. Este fallo solo afecta a las ramas 1.30 y 1.31: un servidor en 1.28 o inferior no está afectado.Comprobar HTTP/3 (CVE-2026-95101)
grep -nE 'listen\s.*quic|http3' /root/nginx-conf.txtgrep -n 'proxy_request_buffering' /root/nginx-conf.txt
HTTP/3 activo delante de unproxy_pass, sinproxy_request_buffering off: expuesto.Comprobar los tickets TLS (CVE-2026-97629)
grep -nE 'ssl_session_cache\s.*shared|ssl_session_ticket_key|ssl_session_tickets' /root/nginx-conf.txt
Expuesto sishared:está presente sinssl_session_ticket_keynissl_session_tickets off. El impacto descrito por F5 afecta sobre todo a los sitios que autentican a sus clientes por certificado (ssl_verify_client).Comprobar SSI y AIO (CVE-2026-97205)
grep -nE '^\s*(ssi|aio)\s' /root/nginx-conf.txt
Expuesto sissi onyaio(valoronothreads) se aplican a las mismas páginas y esas páginas contienen comandosinclude virtual.
En qué orden tratar un parque de servidores
Con estas ocho comprobaciones, cada servidor cae en una de tres casillas. Primera casilla: hay una condición de exposición y el servidor recibe tráfico público. Se parchea hoy, o recibe una mitigación en la hora. Los reverse proxies que sirven HTTP/3 y los sitios que autentican por certificado de cliente van primero, porque el impacto descrito afecta a la petición reenviada o a la propia autenticación.
Segunda casilla: no hay ninguna condición, pero la versión está en el rango vulnerable. El riesgo inmediato es bajo y la actualización se planifica en la semana. Las configuraciones cambian, y basta un alias añadido mañana por un desarrollador para reabrir CVE-2026-15176.
Tercera casilla: versión ya corregida, o paquete de distribución cuyo changelog cita los CVE. Nada que hacer, salvo anotar la fecha de la comprobación. Conserve esta tabla por cliente: también es la respuesta que dar cuando un cliente le pregunta si estaba afectado.
Actualizar entorno por entorno
Repositorio nginx.org en Debian o Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
Después,nginx -vdebe mostrar 1.30.6 en la rama stable, 1.31.7 o superior en mainline.Repositorio nginx.org en RHEL, AlmaLinux o Rocky
sudo dnf upgrade nginx
Misma comprobación connginx -v. Para ambas familias, la instalación del repositorio se describe en la página Linux packages de nginx.org.Paquete de la distribución
En Debian 13,
sudo apt update && sudo apt install --only-upgrade nginxdebe traer1.26.3-3+deb13u10o una versión más reciente. En otros sistemas, aplique las actualizaciones de seguridad en cuanto se publiquen y compruebe el changelog como se indica más arriba. Si su distribución se retrasa, puede pasar al repositorio nginx.org; compruebe antes que los módulos dinámicos de los que depende existen allí.Contenedores Docker
En el archivo compose, fije
image: nginx:1.30.6(onginx:stable) y luego:docker compose pull && docker compose up -d
Una imagen construida conFROM nginx:…se reconstruye:docker compose build --pull && docker compose up -d.Servidor gestionado por un panel o un proveedor
Si nginx lo instaló un panel de administración o su proveedor de hosting, es su canal de actualización el que entrega la corrección. Compruebe
nginx -vy el changelog del paquete tras su actualización y, ante la duda, pregunte al proveedor en qué fecha se aplicó la corrección.Probar la configuración
sudo nginx -t
La respuesta esperada contienesyntax is okytest is successful. No reinicie nunca sin esta prueba: una configuración inválida deja el servicio detenido.Sustituir el binario en memoria
Actualizar el paquete no sustituye el proceso maestro ya en marcha.
sudo ls -l /proc/$(cat /run/nginx.pid)/exemuestra(deleted)mientras el binario antiguo siga en ejecución (adapte la ruta del archivo PID).sudo systemctl restart nginxcorta unos segundos; la sustitución en caliente con la señalUSR2, documentada por nginx, evita ese corte, pero exige conocer bien su configuración de systemd.Comprobar y después vigilar
Vuelva a lanzar
nginx -vy el comando de/proc: ya no aparece(deleted). Pruebe un sitio concurl -sI https://your-domain.com. Después añada una alerta sobre los reinicios de workers, como en nuestra guía monitorización y alertas proactivas en VPS.
Imposible parchear hoy: las mitigaciones publicadas por F5
Las fichas CVE de F5 describen una mitigación para cada uno de los cinco fallos. Eliminan la condición de exposición sin corregir el código: son medidas provisionales.
CVE-2026-15176: no usar alias en la location afectada, o no usar $request_filename.
CVE-2026-93479: sustituir las capturas sin nombre por capturas con nombre, del tipo (?<site>…), y limitar su uso al bloque donde se aplica la regex.
CVE-2026-95101: proxy_request_buffering off;. El cuerpo de las subidas se envía entonces en flujo a la aplicación, lo que cambia su comportamiento con archivos grandes.
CVE-2026-97629: retirar ssl_session_cache shared:…, o cargar claves estáticas con ssl_session_ticket_key (archivo creado con openssl rand 80 > /etc/nginx/ticket.key). Los servidores con ssl_session_tickets off; no están afectados.
CVE-2026-97205: desactivar aio, o dejar de servir páginas SSI.
Cada mitigación se valida con nginx -t y luego systemctl reload nginx. Aquí basta una recarga, ya que el binario no cambia.
Detección: indicios, no pruebas
Un worker que se cae deja una línea del tipo worker process 12345 exited on signal 11 en el registro de errores. Cuéntelas con grep -c 'exited on signal' /var/log/nginx/error.log y compare con las semanas anteriores. Caídas repetidas en un servidor expuesto son un indicio que investigar, no una prueba de compromiso; su ausencia tampoco prueba que no haya riesgo. Medida general, ajena al aviso del editor: restrinja en el cortafuegos los vhosts que no necesitan ser públicos, como detalla nuestra checklist de bastionado de un VPS Linux.
Solución de problemas: errores tras la actualización
nginx -v muestra 1.30.6, pero nada ha cambiado. El binario en disco es nuevo, el proceso maestro es el antiguo. El comando ls -l /proc/<pid>/exe lo muestra con la marca (deleted). Solución: reiniciar el servicio, o sustituirlo en caliente con USR2.
nginx: [emerg] "/etc/nginx/ticket.key" must be 48 or 80 bytes. El archivo de clave de tickets no tiene el tamaño correcto, a menudo porque se creó en base64 o con un salto de línea. Solución: openssl rand 80 > /etc/nginx/ticket.key, sin opción de codificación, y luego nginx -t.
nginx is already the newest version. El repositorio de su distribución aún no ofrece un paquete corregido. Solución: aplicar las mitigaciones anteriores y seguir el tracker de seguridad de la distribución, o pasar al repositorio nginx.org.
El contenedor sigue respondiendo con la versión antigua. La imagen se descargó, pero el contenedor no se recreó, o el servicio apunta a una etiqueta fijada. Solución: docker compose up -d --force-recreate y luego docker compose exec <service> nginx -v.
Cinco fallos en veinte servidores: la carga de una agencia
Para una agencia, esta corrección no es un comando: es una vuelta completa al parque. Un servidor por cliente, procedencias distintas (paquete Debian aquí, repositorio nginx.org allá, imagen Docker en otro sitio), configuraciones escritas por varias personas. Cada máquina exige el inventario, la actualización, el reinicio, la comprobación y luego la respuesta al cliente preocupado.
La forma más duradera de reducir esta carga es reducir el número de servidores web que administra usted mismo. Con el hosting de revendedor de ServOrbit.com, los sitios de sus clientes funcionan en cuentas cPanel que gestiona desde WHM, en marca blanca: usted conserva la relación con el cliente y sus precios, nosotros mantenemos la infraestructura. Para las máquinas que deben seguir con acceso root, la opción de administración está disponible en nuestros VPS Cloud. Y si aún duda sobre el reverse proxy de esas máquinas, nuestra comparativa de Caddy, Traefik y nginx plantea los criterios.
