nginx 1.30.6 tapa cinco fallos y mi Plesk sigue en 1.30.5

El miércoles 14 nginx publicó la 1.30.6 y la 1.31.7, con cinco CVE dentro. Esta mañana le he preguntado a mi servidor por su versión y me ha contestado 1.30.5. No es dejadez mía: ese nginx lo empaqueta Plesk, y el paquete que hoy ofrece su repositorio se compiló el día 12.

Dos días antes del aviso. Así que la pregunta no era cuándo actualizo, sino cuáles de los cinco llegan a esta configuración. Lo he mirado fallo por fallo contra la configuración que nginx tiene cargada, y el que más me interesaba lo he montado en una maqueta aparte.

Qué he probado y en qué máquina

Lo Probado es del 19 de octubre de 2026, entre las 16:32 y las 17:10 UTC: lecturas de la configuración del servidor web (Ubuntu 24.04.5, nginx 1.30.5 de Plesk), peticiones a mi propio sitio siempre a un hilo y una maqueta en 127.0.0.1 con las dos versiones compiladas aparte.

Lo que sale de los avisos, de los registros CVE o del código fuente va como Revisado, igual que siempre (lo explico en cómo pruebo y reviso las guías). De producción no he tocado nada: ni un fichero, ni una recarga, ni un paquete.

Los cinco, y lo que hace falta para que te toquen

Esta es la parte que no sale en los titulares. Ninguno de los cinco se dispara por tener nginx instalado: cada uno pide una forma concreta de configuración. Las precondiciones son las que describe F5 en cada registro, no un resumen mío.

• CVE-2026-15176. Un location con alias más un rewrite y un set o un return que usen $request_filename. También vale esa variable dentro de un formato de registro. Desbordamiento de montón en el proceso trabajador.
• CVE-2026-93479. Un map con expresiones regulares cuyas capturas se usen en root o en el formato de registro antes que la variable de salida del propio map. Mismo final: desbordamiento.
• CVE-2026-97205. Entrada y salida asíncrona de ficheros activada y una página con include virtual de SSI. Uso de memoria ya liberada.
• CVE-2026-95101. HTTP/3 con proxy_request_buffering on: parte de una trama desconocida se cuela como cuerpo de la petición que se envía al otro lado. Las notas de la versión añaden que eso sirve también para saltarse el límite de client_max_body_size.
• CVE-2026-97629. ssl_session_cache shared sin ssl_session_ticket_key. Con la rotación automática, una de las tres claves se quedaba sin inicializar y se puede falsificar una sesión. F5 añade que con ella se puede saltar la verificación del certificado de cliente, y que la falsificación sale de forma no determinista, fuera del control de quien ataca.

Merece la pena leer la letra pequeña de F5 en los tres de corrupción de memoria. Lo que describe como final normal es que el proceso trabajador se desborde y se reinicie: denegación de servicio. La ejecución de código la da por posible solo en sistemas con el ASLR desactivado, o si quien ataca consigue saltárselo.

El de los tickets tiene su gracia: no castiga a quien gestiona las claves a mano, sino a quien deja que nginx las rote solo. En el código se ve claro. Sin fichero de claves, nginx reserva tres claves; la 1.30.5 las sincroniza con la memoria compartida copiando dos.

Lo que contesta mi configuración

Con las precondiciones escritas, comprobarlas es un rato de grep sobre la configuración que de verdad está cargada, no sobre los ficheros que uno recuerda haber escrito. nginx -T la imprime entera, incluidos los include que mete el panel:

# La configuracion cargada, no los ficheros sueltos
nginx -T 2>/dev/null > /dev/shm/cfg

# Una linea por precondicion
for d in alias rewrite ssl_session_cache ssl_session_ticket_key aio ssi; do
  printf '%-24s %s\n' "$d:" "$(grep -cE "^[[:space:]]*$d[[:space:]]" /dev/shm/cfg)"
done
printf '%-24s %s\n' 'listen con quic:' "$(grep -cE '^[[:space:]]*listen[^;]*quic' /dev/shm/cfg)"
printf '%-24s %s\n' 'alias con variables:' "$(grep -E '^[[:space:]]*alias[[:space:]]' /dev/shm/cfg | grep -c '\$')"

# alias:                   67
# rewrite:                 89
# ssl_session_cache:       0
# ssl_session_ticket_key:  0
# aio:                     0
# ssi:                     0
# listen con quic:         0
# alias con variables:     35

Cero en caché de sesión TLS, cero en HTTP/3, cero en entrada asíncrona y cero en SSI. Quedan los dos desbordamientos, y ahí hay alias y rewrite de sobra. Pero ningún location de esta máquina tiene los dos a la vez, y $request_filename no aparece en ningún set, return ni formato de registro.

Los 35 alias con variables son casi todos el mismo bloque, el de usuarios web que Plesk escribe en cada dominio que crea: location ~ ^/~(.+?)(/.*?\.php)(/.*)?$ apuntando a web_users/$1/$2. Son 34 líneas en 17 de los 30 dominios de la máquina, de una a seis cada uno. Aquí ni siquiera existe la carpeta web_users.

Eso no lo apaga. Pedí /~nadie/prueba.php y me contestó un 404, pero el 404 de WordPress: el =404 del bloque lo recoge un error_page de Plesk y lo manda al bloque de reserva de los enlaces permanentes. El alias con capturas se evalúa igual en cada petición así.

La maqueta: la misma petición en 1.30.5 y en 1.30.6

Para ver el desbordamiento del alias no hace falta atacar nada. Basta con escribir la configuración que describe F5 y mirar qué devuelve cada versión. Compilé las dos en mi directorio, sin tocar el nginx del sistema, y las arranqué en 127.0.0.1 con su propio pid y sus propios registros.

location /prefijo/muy/largo/ {
    alias /home/ubuntu/nginx-src-20261019/lab/docs/;
    rewrite ^.*$ /x;                 # sin bandera: sigue en la fase
    set $f "$request_filename";      # fuerza el calculo de la ruta
    return 200 "f=$f\n";
}

# curl http://127.0.0.1:8099/prefijo/muy/largo/x | xxd
#
# 1.30.5 -> 200, Content-Length: 27
#   00000000: 663d 0000 0000 0000 0000 0000 0000 0000  f=..............
#   00000010: 0000 0000 0000 0000 0000 0a              ...........
#   error.log: ninguna linea
#
# 1.30.6 -> 200, Content-Length: 3
#   00000000: 663d 0a                                  f=.
#   error.log: 1 [alert] por peticion

Veinticuatro bytes nulos donde debería ir una ruta. La cuenta está en ngx_http_map_uri_to_path(): la raíz del alias (41), más la URI reescrita (2), menos el prefijo del location (19), más uno. Da 25 bytes reservados, y después copia los 41 de la raíz.

Dieciséis bytes fuera del sitio. Y el valor de la variable sale con longitud 24, que es justo lo que he medido en la respuesta. La 1.30.6 añade dos comprobaciones: que la URI no haya cambiado y que el prefijo no sea más largo que ella. Si alguna falla, no calcula la ruta y escribe esto:

[alert] 1548701#0: *1 «alias» cannot be used in location «/prefijo/muy/largo/» where URI was rewritten, client: 127.0.0.1, request: «GET /prefijo/muy/largo/x HTTP/1.1»

error.log de la maqueta con nginx 1.30.6, 19/10/2026

Cambié la raíz del alias y repetí la petición en la 1.30.5. Con una raíz de 51 caracteres salen 34 bytes nulos, justo lo que predice la fórmula. Con una de 5 la resta se va por debajo de cero y la variable vuelve vacía. La aritmética es lectura del código; los bytes los he contado yo.

Y con el binario de Plesk, igual

Repetí la prueba con el binario que sirve mis webs, /usr/sbin/nginx, arrancado aparte en otro puerto local y como usuario sin privilegios. Los mismos 27 bytes, los mismos 24 nulos, ni una línea en el registro. El maestro de producción siguió con su PID del día 15, intacto.

Qué no he probado

• Los otros tres fallos. Sin HTTP/3, sin SSI y sin caché de sesión compartida no tengo dónde montarlos, y no los he reproducido en ninguna parte.
• Tirar un proceso trabajador o sacar memoria ajena. Me he quedado en la cuenta y en los bytes que devuelve la respuesta. Lo que hay detrás de esos 24 nulos no lo he mirado.
• Nada en ARM ni en otra distribución. Todo es Ubuntu 24.04 sobre x86-64, con la 1.30.5 y la 1.30.6 compiladas con las opciones por defecto, no con las de Plesk.

Quién ha parcheado y quién no

Debian subió el día 15 su nginx 1.30.4-8 a inestable, con urgencia alta y los cinco parches de la 1.30.6 metidos a mano. Ubuntu 24.04 sigue con la 1.24.0 de septiembre. Y el repositorio de Plesk, con la 1.30.5. Nadie llega tarde todavía, pero conviene saber en qué cola está uno.

Con una salvedad: a la 1.24.0 de Ubuntu solo le tocan tres de los cinco. Los rangos de la página de avisos dejan fuera el del map, que empieza en la 1.30.0, y el de HTTP/3, que empieza en la 1.25.0. El paquete viejo no siempre está más expuesto.

Mientras Plesk no saque paquete

Aquí no hay mitigación que aplicar, porque no hay precondición que cumplir. Si la hubiera, lo que haría es quitar la forma, no el paquete: separar el rewrite del alias, sacar $request_filename del formato de registro, poner un fichero de claves de ticket. No he cambiado nada de eso en esta máquina.

Y una línea que me faltaba. Mi checklist de Ubuntu recién instalado no nombra nginx ni una vez. Debería preguntar quién empaqueta cada cosa que escucha en el 443, porque eso es lo que decide cuándo te llega el arreglo. Es la misma historia que las cuatro libcurl de octubre.

Si alguien lee esto con un panel delante, conviene empezar por ahí. En el resto de guías de Ubuntu y Linux hay más cosas de estas.