NGINX CVE-2026-42533: heap overflow en map

Si tenés NGINX de cara a internet, esta semana el tema en los foros de seguridad tiene nombre y apellido: CVE-2026-42533, un desbordamiento de memoria en la directiva map que un atacante remoto sin credenciales puede disparar con una simple petición HTTP. Lo que lo mueve del casillero "otra CVE más" al de "parchear ya" es que dejó de ser teoría: hay un exploit full-chain público que encadena una fuga de memoria con el overflow para saltarse el ASLR y terminar ejecutando comandos.

CVE-2026-42533 es una vulnerabilidad de heap buffer overflow (CWE-122) en el servidor web NGINX, descubierta y parcheada por F5/NGINX el 15 de julio de 2026. Se manifiesta en la directiva map cuando usa matching por expresiones regulares y una cadena referencia variables de captura numeradas ($1, $2) antes que la variable de salida del map. Un atacante remoto sin autenticar puede corromper la memoria del proceso worker con peticiones diseñadas y, si el ASLR está deshabilitado o se puede bypassear, llegar a ejecución de código.

¿A qué versiones de NGINX afecta y cómo sé si estoy en riesgo?

NGINX CVE-2026-42533: heap overflow en map y PoC de RCE

Estás expuesto si corrés una versión anterior a las parcheadas y tu configuración tiene un map con regex que usa capturas numeradas. De acuerdo con The Hacker News y el aviso de F5/NGINX, el código vulnerable está presente en NGINX Open Source desde la 0.9.6 hasta la 1.30.3 (rama stable) y en la mainline hasta la 1.31.2, además de NGINX Plus. La corrección llegó en:

Producto	Rama	Versión con fix
NGINX Open Source	stable	1.30.4
NGINX Open Source	mainline	1.31.3
NGINX Plus	—	37.0.3.1 (o R36 P7)

El primer chequeo es trivial. Mirá tu versión y contrastala con la tabla:

nginx -v
# nginx version: nginx/1.30.3   <- vulnerable (anterior a 1.30.4)

Importante: no todos los NGINX del planeta son explotables de inmediato. El camino peligroso necesita una configuración específica donde un map basado en regex y sus capturas numeradas se evalúan en un orden inseguro. Si no usás map con regex, el riesgo de RCE cae mucho — pero eso no es excusa para no actualizar, porque la superficie de crash sigue ahí.

¿Por qué falla la directiva map? El bug de las dos pasadas

La raíz es el motor de evaluación de cadenas en dos pasadas de NGINX. En la primera pasada NGINX mide cuánto espacio necesita el resultado; en la segunda lo escribe. El problema aparece cuando, entre una pasada y otra, un map con regex sobrescribe la estructura compartida r->captures que guarda las capturas del último regex.

La medición se hace con un tamaño y la escritura con otro. Si la captura de la segunda pasada quedó más grande, NGINX escribe más bytes de los reservados: eso es el heap buffer overflow. Si quedó más chica, se filtran datos residuales del heap (info leak).
El overflow corrompe estructuras internas del pool. El PoC apunta a los registros ngx_pool_cleanup_s, que contienen punteros a funciones de limpieza; secuestrar esos punteros es lo que abre la puerta a ejecutar código.
El disparador es una petición HTTP normal. No hace falta autenticación ni un cliente especial: alcanza con que la request golpee el server/location que evalúa ese map.

¿Qué hace el PoC full-chain público?

Convierte un crash en una ejecución de comandos completa. Según reportó la prensa de seguridad, a fines de julio de 2026 (alrededor del 27-28) se publicó un exploit full-chain que encadena la fuga de memoria con el desbordamiento: primero recupera direcciones del heap y de libc para derrotar al ASLR, después rocía registros ngx_pool_cleanup_s falsos y redirige el manejo de cleanup hacia system() de libc para correr un comando.

Un repositorio público de PoC confirma el crash de forma reproducible: reporta un SIGABRT con el clásico error "invalid next size" de glibc en Ubuntu 24.04 x86_64, e incluye un modo diagnóstico que muestra el desajuste de tamaños entre las dos pasadas sin tumbar el proceso. Que el crash sea trivial de reproducir y que el chain de RCE ya esté escrito es exactamente lo que acorta la ventana entre "salió la CVE" y "alguien la usa contra vos".

¿Está siendo explotado en el mundo real?

Hasta el momento no hay explotación masiva confirmada ni la CVE figura en el catálogo KEV de CISA, según los reportes disponibles. Eso no es tranquilizante por dos motivos: primero, la CVE recibió un puntaje alto —CVSS v4.0 9.2 (v3.1 8.1) según el aviso de F5/NGINX— y segundo, la historia reciente muestra que un PoC público de esta calidad se transforma en escaneo automatizado en cuestión de días. Es el mismo patrón que ya vimos en otros casos de "PoC público → root" que cubrimos en el blog.

¿Cómo me protejo hoy?

Actualizá NGINX a una versión con el fix. Es la única solución completa; todo lo demás es mitigación temporal.

Verificá tu versión y actualizá. En Ubuntu/Debian, si usás los paquetes oficiales de nginx.org, corré apt update && apt upgrade nginx y confirmá con nginx -v que quedaste en 1.30.4 / 1.31.3 o superior. Ojo: los paquetes de la distro pueden ir atrasados — verificá el número de versión real, no asumas.
Auditá tus maps con regex. Buscá bloques map que usen capturas numeradas: grep -rnE 'map\s' /etc/nginx/ y revisá cuáles combinan regex con $1, $2, etc.
Mitigación temporal: pasá a capturas nombradas. Reemplazar $1/$2 por capturas nombradas (?<nombre>...) reduce la exposición mientras coordinás la actualización, pero no reemplaza al parche.
Reiniciá el servicio tras actualizar. Un nginx -t && systemctl reload nginx no basta si cambió el binario: para cargar el ejecutable parcheado necesitás systemctl restart nginx (o un upgrade en caliente del binario si no podés cortar).

Un ejemplo ilustrativo del cambio de capturas numeradas a nombradas:

# Patrón a revisar (regex + captura numerada usada aguas arriba)
map $http_host $tenant {
    ~^(?:www\.)?(.+)$   $1;
}

# Mitigación temporal: captura nombrada
map $http_host $tenant {
    ~^(?:www\.)?(?<host>.+)$   $host;
}

Esto es solo para bajar la superficie mientras parcheás; el orden de evaluación seguro lo garantiza recién la versión corregida.

Lectura complementaria

Si venís siguiendo la seguridad de NGINX en el blog, esta nota se conecta directamente con dos que ya publicamos: "NGINX Rift (CVE-2026-42945): el full-chain que anula el ASLR", que profundiza en la mecánica de derrotar el ASLR en este mismo servidor, y "HTTP/2 Bomb (CVE-2026-49975): un DoS que voltea proxies en segundos", otro caso de peticiones HTTP que tumban tu capa de proxy. El patrón "PoC público a root en minutos" también aparece en "BadGarbage (CVE-2026-53361)".

Preguntas frecuentes

¿Qué versiones de NGINX corrigen CVE-2026-42533?

NGINX Open Source 1.30.4 (stable) y 1.31.3 (mainline), y NGINX Plus 37.0.3.1 (o R36 P7). Cualquier versión de la 0.9.6 a la 1.30.3 en stable queda expuesta.

¿La vulnerabilidad permite ejecución remota de código?

Sí, pero condicionada. El impacto garantizado es DoS (crash/reinicio del worker). La RCE requiere una configuración con map regex vulnerable y que el ASLR esté deshabilitado o se pueda bypassear, cosa que el PoC full-chain público ya demuestra.

¿Necesito estar autenticado para explotarla?

No. Es una falla pre-autenticación: un atacante remoto anónimo puede dispararla enviando peticiones HTTP diseñadas al endpoint que evalúa el map afectado.

¿Alcanza con recargar la configuración para aplicar el parche?

No. Un reload recarga la config pero no cambia el binario en ejecución. Después de actualizar el paquete tenés que reiniciar el servicio (o hacer un upgrade en caliente del binario) para correr el código corregido.

¿Ya está siendo explotada activamente?

Al momento de escribir esta nota no hay explotación masiva confirmada ni figura en el catálogo KEV de CISA, pero existe un PoC full-chain público desde fines de julio de 2026, lo que eleva el riesgo de escaneo automatizado a corto plazo.

Fuentes: nginx.org — Security Advisories, The Hacker News, Security Affairs.