Nginx parchea un desbordamiento crítico que arrastra desde 2011: CVE-2026-42533 y la cuenta atrás del exploit

Quince años en el código

Hay parches que cierran un fallo de la última release, y parches que cierran un fallo con quince años de antigüedad. Este es de los segundos: el desbordamiento de búfer identificado como CVE-2026-42533 está presente en todas las versiones de Nginx desde la 0.9.6, publicada en 2011. Es decir: si tienes un Nginx en producción, da casi igual cuándo lo instalaras — estaba afectado.

El 15 de julio F5 publicó las versiones que lo corrigen: 1.30.4 (stable), 1.31.3 (mainline) y NGINX Plus 37.0.3.1. Y no viene solo: en la misma tanda caen otras dos vulnerabilidades que conviene conocer.

En una frase

Una petición HTTP manipulada puede provocar un desbordamiento de búfer en el heap del worker de Nginx. En el mejor de los casos para el atacante malo, tira el worker y provoca denegación de servicio; en el peor, si el sistema no tiene ASLR o el atacante consigue esquivarlo, la cosa puede escalar a ejecución remota de código. CVSS 9.2 en la escala v4 (8.1 en v3.1, por la complejidad alta del ataque).

Qué se sabe del fallo

El desbordamiento se produce en el motor de evaluación de expresiones de Nginx al procesar peticiones HTTP especialmente construidas. Los detalles finos están, deliberadamente, sin publicar: el investigador que lo reportó, Stan Shaw, ha anunciado que liberará su prueba de concepto 21 días después del parche — o sea, a principios de agosto.

Ese modelo de "os doy tres semanas" es cada vez más común y hay que leerlo como lo que es: una cuenta atrás. Hoy no hay exploit público ni constancia de explotación activa (no está en el catálogo KEV de CISA a fecha de este artículo). Pero el día que el PoC salga, los escáneres automáticos tardan horas en incorporarlo, no semanas. La ventana cómoda para actualizar es ahora, no en agosto.

Lo que viene en la misma tanda

Las versiones 1.30.4 y 1.31.3 corrigen además:

• CVE-2026-60005 — divulgación de memoria en ngx_http_slice_module. Si usas el módulo slice (típico en configuraciones de caché de vídeo o ficheros grandes troceados), una respuesta manipulada puede filtrar contenido de memoria del worker.
• Un use-after-free en ngx_http_ssi_module, el módulo de Server Side Includes. Menos gente lo usa hoy, pero si tienes ssi on; en alguna config heredada, también te toca.

Tres fallos, un solo paquete. Razón de más para no dejarlo pasar.

A quién afecta

• Versiones afectadas: de la 0.9.6 a la 1.31.2. En la práctica, todo Nginx sin el parche del 15 de julio.
• Mayor exposición: cualquier Nginx de cara a internet, que es exactamente donde Nginx suele estar. La complejidad del ataque es alta, pero la superficie es universal.
• NGINX Plus: afectado igualmente; el fix está en 37.0.3.1.

Si en mayo aplicaste la tanda de siete CVEs y pensaste que ya estabas al día: lo estabas. Hasta ahora. Así funciona esto.

Qué tienes que hacer hoy

La rutina de siempre, sin dramatismo y sin dejarlo para luego.

1. Mira qué versión tienes

nginx -v

• Rama stable: el objetivo es 1.30.4 o superior.
• Rama mainline: el objetivo es 1.31.3 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 valida la configuración y te ahorra el susto de un servicio caído por una errata. El reload aplica el binario nuevo sin cortar conexiones en curso.

Recuerda el matiz de los repositorios de distro: a veces backportean el fix manteniendo el número de versión antiguo. Si tu nginx -v no llega al 1.30.4 pero el paquete es de después del 15 de julio, revisa el changelog de seguridad de tu distro antes de asustarte — y al revés: no des por hecho que estás cubierto solo porque hiciste apt upgrade la semana pasada.

3. Si usas slice o SSI

Aprovecha la pasada para confirmarlo:

nginx -T 2>/dev/null | grep -E "slice|ssi on"

Si aparece algo, esos dos fallos secundarios también te aplicaban y el parche los cierra de golpe.

Lo que hicimos nosotros

El mismo día 15 actualizamos los Nginx de cara a internet que gestionamos, empezando por los proxies inversos expuestos. Sin esperar al PoC, sin esperar a que aparezca en el KEV de CISA: cuando un fallo lleva quince años en el código, afecta a todas las versiones y tiene fecha anunciada de exploit público, el cálculo coste/beneficio de actualizar ya está hecho.

Y después del reload, el gesto que separa "creo que está" de "está": volver a ejecutar nginx -v y comprobarlo. Con la memoria no se verifica nada.

Si tu Nginx lleva meses sin ver un parche —o no sabes ni qué versión corre—, hablamos.

Referencias

• nginx security advisories — nginx.org
• Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution — The Hacker News
• NGINX vulnerability CVE-2026-42533 — F5 (K000161019)
• Releases — NGINX Documentation