Nginx saca dos parches de seguridad en nueve días: siete CVEs y por qué toca actualizar ya

Dos avisos en la misma quincena

Cuando un proyecto tan maduro como Nginx publica dos versiones de seguridad en nueve días, conviene levantar la vista de lo que estés haciendo. Es justo lo que pasó a mediados de mayo: primero la tanda gorda del 13 (seis CVEs de golpe) y, como propina, otro parche el 22 con una séptima.

Ninguna es el fin del mundo por separado, pero en conjunto tocan piezas que casi todo el mundo tiene activas: el módulo rewrite, el proxy HTTP/2, HTTP/3 y el resolver. Si gestionas servidores web —propios o de clientes— esto va contigo.

En una frase

Hay siete vulnerabilidades repartidas en dos releases. La que más respeto da es un desbordamiento de búfer en el módulo rewrite (el que usa medio internet para reescribir URLs), y la más comentada es una inyección de peticiones HTTP/2 cuando Nginx hace de proxy. El resto son lecturas fuera de límites, una suplantación de dirección en HTTP/3 y un use-after-free en las consultas OCSP.

La buena noticia: se arregla actualizando el paquete y recargando. Sin reinicio de máquina.

Las siete, ordenadas por lo que deberías mirar primero

Estos son los datos tal y como los publica el propio aviso de seguridad de Nginx:

Las dos del módulo rewrite (CVE-2026-42945 y CVE-2026-9256)

Son las que más te interesan, por una razón sencilla: casi nadie sirve sin rewrite. Redirecciones, URLs amigables, forzar HTTPS, reescrituras de proxy... todo eso pasa por ese módulo. Un desbordamiento de búfer ahí es, en el peor de los casos, la antesala de una ejecución de código. Que hayan tenido que volver a tocarlo nueve días después (CVE-2026-9256) dice que el área estaba caliente.

La inyección HTTP/2 (CVE-2026-42926)

La más llamativa, aunque con condiciones: solo afecta si configuras Nginx para proxyar hacia el upstream por HTTP/2 (proxy_http_version 2) y además usas proxy_set_body. En ese escenario, un atacante puede colar bytes que el upstream interpreta como cabeceras o frames HTTP/2 adicionales, manipulando la petición que llega detrás. Su CVSS es 5.8 (medio), pero el patrón "request smuggling" siempre da más sustos de los que su nota sugiere. Si no usas esa combinación, no te afecta; si la usas, es prioritaria.

Las otras cuatro

• CVE-2026-42946 y CVE-2026-42934: lecturas fuera de límites en scgi/uwsgi y en charset. Filtración de memoria o caída del worker. Relevantes sobre todo si haces de pasarela a aplicaciones Python/PHP vía SCGI/uWSGI.
• CVE-2026-40460: suplantación de dirección en HTTP/3. Solo te toca si tienes QUIC/HTTP/3 activado (cada vez más común; si seguiste nuestro artículo de HTTP/3, repásalo).
• CVE-2026-40701: use-after-free en las peticiones OCSP del resolver. Aparece con OCSP stapling y resolución dinámica.

A quién afecta

• Ramas afectadas: las versiones mainline 1.29.x hasta 1.30.0, y las stable previas a 1.30.1. Si tu nginx -v es anterior a esos números, estás en el saco.
• Quién está en mayor riesgo: cualquier Nginx de cara a internet, y muy especialmente los que actúan de proxy inverso (que es prácticamente el caso de uso por defecto hoy). El módulo rewrite lo tiene activo casi todo el mundo.

Qué tienes que hacer hoy

Sin rodeos. Comprueba versión y actualiza a la rama que te corresponda.

1. Mira qué versión tienes

nginx -v

• Si vas por la rama stable, el objetivo es 1.30.2 o superior.
• Si vas por mainline, el objetivo es 1.31.1 o superior.

2. Actualiza y recarga (sin downtime)

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
sudo nginx -t && sudo systemctl reload nginx

# RHEL / AlmaLinux / Rocky
sudo dnf update nginx
sudo nginx -t && sudo systemctl reload nginx

El nginx -t antes del reload no es opcional: valida la configuración y evita que un recargado deje el servicio caído por un error tonto. El reload aplica el binario nuevo sin cortar las conexiones en curso.

Si instalaste Nginx desde el repositorio oficial de nginx.org en lugar del de tu distro, actualiza desde ahí (nginx.org/packages). Las distribuciones a veces backportean el fix manteniendo el número de versión: no te fíes solo del número, comprueba la fecha del paquete o el changelog de seguridad de tu distro.

3. Si no puedes actualizar ahora mismo

Mitigaciones temporales según lo que tengas expuesto:

• HTTP/2 como proxy (CVE-2026-42926): si no necesitas proxy_http_version 2 con proxy_set_body, baja el proxy a HTTP/1.1 mientras parcheas.
• HTTP/3 (CVE-2026-40460): si tienes QUIC activado de forma experimental, puedes desactivarlo temporalmente (listen 443 quic;) hasta actualizar.

Son paliativos para reducir superficie. No sustituyen al parche.

Lo que hicimos nosotros

En cuanto salió la tanda del 13 desplegamos sobre los Nginx de cara a internet que gestionamos, priorizando los que hacen de proxy inverso con rewrite complejo. Cuando llegó el segundo parche el 22 con CVE-2026-9256 —otra vez el módulo rewrite— repetimos pasada en lugar de asumir que con la primera valía. Es la diferencia entre "ya lo actualicé el otro día" y "está en la versión correcta": lo segundo se comprueba con un nginx -v, no con la memoria.

La rutina de siempre

Con Nginx, igual que con el kernel, los cinco gestos son los mismos:

• nginx -v para saber dónde estás.
• apt/dnf update.
• nginx -t para validar.
• systemctl reload nginx.
• Volver a mirar nginx -v para confirmar.

Tener el plan de actualizaciones al día no es un lujo: es lo que hace que una tanda de siete CVEs sea un martes cualquiera y no un incidente. Si tu servidor web hace meses que no toca un parche, hablamos.

Referencias

• nginx security advisories — nginx.org
• nginx news 2026 — nginx.org
• CVE-2026-42926 Detail — NVD
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945 — oss-security