Ingeniería AI-native

NGINX 1.30.6 y 1.31.7: por qué actualizar tras los avisos de octubre

Las versiones de nginx del 14 de octubre corrigen cinco fallos según la configuración: cómo ver tu versión, qué revisar y cómo fijarla.

Publicado 2026-10-23Actualizado 2026-10-238 min de lectura

NGINXsecurityDevOpsNode.jspatching

Este artículo es educativo y no sustituye una auditoría formal de smart contracts, asesoría legal, asesoría financiera ni una revisión de seguridad específica del protocolo.

El 14 de octubre de 2026, nginx.org publicó nginx 1.30.6, de la rama stable, y nginx 1.31.7, de la rama mainline. Las dos corrigen cinco vulnerabilidades de severidad media. Cuatro de ellas afectan a versiones publicadas hace años, y cada una solo se puede activar con una configuración concreta, por ejemplo HTTP/3 o alias con rewrite.

Si sirves tráfico en producción con NGINX Open Source, actualiza a 1.30.6 o a 1.31.7 o posterior, o al paquete parcheado de tu distribución. Revisar la configuración sirve para decidir el orden, no para quedarse en una versión afectada: la configuración cambia con el tiempo y la versión parcheada deja de depender de ese análisis.

Un módulo de mármol blanco con cuatro cartuchos de cristal cobalto: una mano introduce el nuevo; delante queda el cartucho viejo, esmerilado y con una banda ámbar, y arriba brillan cinco luces, tres en cobalto y dos en ámbar. — Ilustración conceptual.

Este artículo explica qué corrigen esas versiones, cómo saber qué NGINX tienes de verdad en servidores, paquetes e imágenes de contenedor, qué directivas conviene buscar y cómo fijar la versión nueva para que no vuelva atrás. Al final, un caso real con Node.js muestra el mismo patrón aplicado a otro componente.

Qué corrigen 1.30.6 y 1.31.7

Según el registro de cambios de nginx.org, las cinco correcciones del 14 de octubre son estas:

CVE-2026-15176: desbordamiento de búfer en un proceso worker cuando la directiva alias sirve una URI que antes ha cambiado rewrite. Afecta de la 0.1.29 a la 1.31.6.
CVE-2026-93479: desbordamiento de búfer al evaluar expresiones con variables, que interviene en el cálculo de root y en los logs de los módulos http y stream. Afecta de la 1.30.0 a la 1.30.5 y de la 1.31.2 a la 1.31.6.
CVE-2026-95101: con HTTP/3, parte de un frame desconocido se puede tratar como cuerpo de la petición, lo que permite saltarse client_max_body_size o inyectar datos en la petición que se envía al backend. Afecta de la 1.25.0 a la 1.31.6.
CVE-2026-97629: al rotar las claves de los tickets de sesión TLS, una de ellas quedaba sin inicializar, lo que podía permitir falsificar una sesión. Afecta de la 1.23.2 a la 1.31.6.
CVE-2026-97205: con E/S asíncrona (aio), una página SSI con comandos include virtual puede provocar un use-after-free. Afecta de la 0.8.11 a la 1.31.6.

nginx.org las clasifica como de severidad media. F5, que asigna los CVE de NGINX, publica en el NVD puntuaciones CVSS 3.1 de entre 5,3 y 8,1. A 23 de octubre, el NVD aún no había hecho su propio análisis de ninguna de las cinco.

Si vienes de una versión anterior a la 1.30.4, la actualización trae además correcciones previas. La más relevante es CVE-2026-42533, que nginx.org clasifica como major y corrigió el 15 de julio en la 1.30.4: un desbordamiento de memoria cuando se combinan map con expresiones regulares y una captura de ese map. La 1.31.8 mainline, del 21 de octubre, no añade correcciones de seguridad.

Por qué actualizar aunque tu configuración no las active

Cada una de estas vulnerabilidades necesita una combinación concreta: alias con rewrite, HTTP/3, rotación de tickets TLS, aio con SSI. Es tentador revisar la configuración, no encontrar esas directivas y dejar la versión como está. Hay tres razones para no hacerlo.

La primera es que la configuración se mueve. Un include nuevo, una plantilla de un equipo distinto o la activación de HTTP/3 en un servidor pueden reabrir la exposición sin que nadie vuelva a mirar el aviso. La versión parcheada no depende de que ese análisis siga siendo cierto.

La segunda es el coste. La 1.30.6 pertenece a la misma rama que la 1.30.5 y su registro de cambios solo lista correcciones y un cambio en el nivel de algunos mensajes de log, sin funciones nuevas. En la rama stable, actualizar suele ser más barato que mantener y justificar una excepción.

La tercera es que las ramas antiguas no reciben estos parches en nginx.org. La página de descargas lista la 1.28, la 1.26 y otras como versiones legacy, y el aviso marca como corregidas solo la 1.30.6 y la 1.31.7 en adelante. Si usas una de esas ramas, la salida es la 1.30.6 o el paquete parcheado de tu distribución.

Paso 1: saber qué NGINX tienes de verdad

La versión que importa es la del binario que atiende el tráfico, y no siempre coincide con la que figura en un README o en una etiqueta de imagen.

bash

# Versión del binario
nginx -v

# Módulos compilados: HTTP/3 aparece como --with-http_v3_module
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|file-aio|threads'

# Debian y Ubuntu: la versión del paquete es la que dice si el parche está aplicado
apt-cache policy nginx

# Contenedores: versión real dentro de la imagen
docker run --rm nginx:1.30.6-alpine nginx -v

Con los paquetes de una distribución, el número de nginx -v puede engañar. Las distribuciones suelen aplicar el parche sobre su versión sin cambiar el número principal. En Debian 13, por ejemplo, el paquete que corrige los cinco CVE de octubre es el 1.26.3-3+deb13u10, según el aviso DSA-6575-1, y nginx -v sigue mostrando 1.26.3. Lo que hay que comparar es la versión completa del paquete con la del aviso de tu distribución.

Debian security tracker: DSA-6575-1

En Kubernetes, un controlador de ingress o una imagen de terceros puede traer su propia compilación de NGINX. La página de nginx.org distingue, por ejemplo, su NGINX Ingress Controller del proyecto comunitario ingress-nginx. En esos casos, la versión parcheada la publica quien mantiene el controlador o la imagen.

Paso 2: mirar qué directivas usa la configuración

nginx -T valida la configuración y la imprime completa, con todos los include resueltos. Filtrarla con grep da una primera lista de las directivas relacionadas con los avisos de este año:

bash

# Configuración completa (con los include resueltos), filtrada por las directivas de los avisos.
# Los números de línea son los de la salida de nginx -T, no los de cada archivo.
sudo nginx -T 2>/dev/null | grep -nE '^\s*(alias|rewrite|map|aio|ssi|http3|ssl_session_cache|ssl_session_ticket_key)\b|\$request_filename|\bquic\b'

Cómo leer el resultado, según las descripciones que F5 publica en el NVD para cada CVE:

Una location con alias junto con rewrite y una directiva set o return que hace referencia a la variable $request_filename, o $request_filename en el formato del access log (log_format), apuntan a CVE-2026-15176.
Un map con expresiones regulares cuyas variables de captura aparecen en root o en el formato del access log antes que la variable de salida del map apunta a CVE-2026-93479. Si aparecen así en cualquier expresión con variables, apuntan a CVE-2026-42533.
listen con quic o http3 on apuntan a CVE-2026-95101.
ssl_session_cache shared sin ssl_session_ticket_key apunta a CVE-2026-97629.
aio junto con ssi apunta a CVE-2026-97205.

Una coincidencia no confirma que la vulnerabilidad se pueda explotar, y ninguna coincidencia no la descarta del todo: el grep no ve módulos de terceros ni configuraciones generadas al arrancar. Sirve para ordenar el trabajo. Los servidores con coincidencias van primero, y el resto se actualiza igual.

Paso 3: actualizar y fijar la versión

En servidores con paquetes, la actualización es la habitual de cada sistema: instalar el paquete nuevo, validar con nginx -t y reiniciar el servicio para que el binario nuevo atienda el tráfico. Según la documentación de nginx, un reload solo relee la configuración; cambiar de binario requiere reiniciar o la actualización en caliente con la señal USR2.

nginx: controlling nginx

En contenedores, conviene fijar la imagen por etiqueta y por digest. La etiqueta dice qué versión querías y el digest fija exactamente la imagen revisada, aunque alguien vuelva a publicar la etiqueta.

dockerfile

# Etiqueta legible y digest inmutable.
# El digest se obtiene con: crane digest nginx:1.30.6-alpine
FROM nginx:1.30.6-alpine@sha256:47928bf67eb62a1863cb08d9ecb52d3e704304ba614eaee17884204677702951

El digest de este ejemplo es el que devolvía la etiqueta el 23 de octubre de 2026. Una etiqueta puede volver a publicarse con otro contenido, por ejemplo al reconstruir la imagen, así que obtén el digest en el momento de fijarlo.

Para que la versión no vuelva atrás, una comprobación en el CI puede fallar si algún Dockerfile o manifiesto usa una imagen de NGINX anterior a la corregida:

bash

#!/usr/bin/env bash
# Falla si algún Dockerfile o manifiesto YAML usa una imagen de NGINX anterior a 1.30.6 (stable) o 1.31.7 (mainline).
set -euo pipefail
refs=$(grep -rhoE --include='Dockerfile*' --include='*.yaml' --include='*.yml' \
  '(nginx|nginxinc/nginx-unprivileged):[0-9]+\.[0-9]+(\.[0-9]+)?' . | sort -u || true)
bad=0
for ref in $refs; do
  ver=${ref##*:}
  IFS=. read -r major minor patch <<< "$ver"
  patch=${patch:-0}
  if (( major < 1 || ( major == 1 && ( minor < 30 || (minor == 30 && patch < 6) || (minor == 31 && patch < 7) ) ) )); then
    echo "Needs update: $ref"; bad=1
  fi
done
exit $bad

El script solo reconoce etiquetas con número de versión. Las etiquetas flotantes como stable-alpine o latest no tienen número que comparar, y es otra razón para fijar versión y digest.

Un caso real: el mismo patrón con Node.js

El 21 de octubre, Node.js publicó las versiones 24.22.1, 22.23.4 y 26.12.1. Corrigen varias vulnerabilidades, la más grave de severidad alta según el propio proyecto, y actualizan los certificados raíz a NSS 3.131.1, una actualización que el aviso de Node.js vincula al compromiso de una CA intermedia de eMudhra.

El compromiso de eMudhra tiene su propio artículo sobre qué actualizar en las herramientas de desarrollo de macOS.

eMudhra en macOS: qué actualizar en curl, Node, Python, Go, Java, Rust y Docker

Un proyecto Node.js en producción, con varias imágenes de contenedor, ya tiene esa actualización en su rama de desarrollo, con tres piezas que sirven igual para NGINX:

Todas sus imágenes pasaron a node:24.22.1-alpine, fijada por etiqueta y por digest.
Una imagen auxiliar que traía su propio Node 22 y una imagen base antigua con Node 20 pasaron a la misma versión.
El package.json declara engines.node con el valor >=24.22.1, y el CI tiene comprobaciones que rechazan imágenes con una versión anterior.

bash

# Versión de Node dentro de la imagen, sin arrancar la aplicación
docker run --rm node:24.22.1-alpine node -v

# Digest para fijar la imagen
crane digest node:24.22.1-alpine

# Solo la línea 24.x parcheada (>=24.22.1 <25); con --engine-strict, npm install falla con cualquier Node fuera de ese rango
npm pkg set engines.node='^24.22.1'
npm install --engine-strict

La lección se traslada tal cual. Una actualización de seguridad no termina cuando se cambia una línea: termina cuando la versión queda fijada en la imagen, declarada en el proyecto y comprobada en el CI, de modo que un cambio posterior no la deshaga sin que nadie lo vea.

Qué no cubre esta actualización

Si NGINX no es tuyo, el parche tampoco. Un CDN o una plataforma gestionada que pone su propio proxy delante de tu aplicación lo actualiza su proveedor, y tu tarea es saber qué componentes sí gestionas tú. Tampoco cubre otros productos de la familia: njs, por ejemplo, publicó su propia versión 1.0.2 el mismo 14 de octubre con correcciones distintas.

Actualizar, fijar y comprobar

Los avisos del 14 de octubre piden cerrar el trabajo, no reaccionar con prisa: saber qué NGINX atiende el tráfico, actualizar a 1.30.6 o 1.31.7, fijar la imagen por digest y dejar en el CI una comprobación que impida volver atrás.

Si quieres comentar cómo aplicar este proceso a tu infraestructura, puedes escribirnos desde la página de contacto; en el mensaje, menciona este artículo, sin credenciales ni detalles de configuración sensibles.

Solicitar revisión técnica

Fuentes

Fuentes consultadas el 23 de octubre de 2026. Ejecutado en Linux, con la salida guardada: nginx -v y nginx -V sobre el paquete 1.30.6 de nginx.org y el 1.26.3 de Debian 13; nginx -T y el filtro de directivas sobre una configuración de prueba; el script del CI sobre manifiestos de prueba; crane digest para las imágenes del artículo; la versión de NGINX y de Node dentro de las imágenes nginx:1.30.6-alpine y node:24.22.1-alpine, extraídas con crane; npm pkg set y npm install --engine-strict. No ejecutado: docker run, sustituido por la extracción de la imagen con crane, y la actualización y el reinicio del servicio en un servidor.