Vulnerabilidad crítica en NGINX permite DoS y posible ejecución de código remoto

ARTÍCULO—

Introducción

Desde julio de 2026, los equipos de infraestructura que usan NGINX enfrentan una vulnerabilidad crítica en el motor de scripts del servidor: CVE-2026-42533. El problema no es un fallo genérico de memoria, sino un desbordamiento de heap controlado por el atacante que ocurre en dos pasos durante la evaluación de expresiones dinámicas. Lo más preocupante es que, en entornos con ASLR deshabilitado o vulnerable, el atacante podría no solo provocar un denial of service (DoS), sino también ejecutar código remoto con solicitudes HTTP especialmente diseñadas.

Lo distintivo de esta vulnerabilidad es su dependencia de la configuración, no solo de la versión. No todos los servidores NGINX están expuestos: solo aquellos que combinan mapas basados en regex con variables de captura numeradas en expresiones de cadena. Esta combinación específica activa un race condition en el motor de scripts de NGINX, donde la primera pasada mide el tamaño del buffer requerido, pero la segunda pasada escribe datos de un tamaño distinto, sobrescribiendo el estado compartido de las capturas.

Qué ocurrió

El 15 de julio de 2026, F5 (dueña de NGINX) publicó parches para CVE-2026-42533 en:

• NGINX 1.30.4 (stable)
• NGINX 1.31.3 (mainline)
• NGINX Plus 37.0.3.1

El vector de ataque requiere:

1. Configuración vulnerable: un mapa con regex cuyo resultado se usa en una expresión de cadena, junto con una captura numerada ($1, $2, etc.) de un regex anterior.
2. Solicitud HTTP maliciosa: un atacante envía un payload que sobrescribe el estado de las capturas entre las dos pasadas del motor de scripts.

El desbordamiento ocurre porque:

• Primera pasada: NGINX mide el tamaño necesario para el buffer basado en la captura original ($1).
• Segunda pasada: sobrescribe el estado de la captura con datos del atacante (más grandes o más pequeños), pero usa el tamaño medido en la primera pasada. Si el buffer es demasiado pequeño, se produce el desbordamiento.

Según Stan Shaw (investigador que reportó la vulnerabilidad), en sistemas Ubuntu 24.04 por defecto, un atacante puede recuperar direcciones de memoria con una sola petición GET, lo que facilita eludir ASLR y lograr ejecución de código. Shaw afirma haber probado el exploit con éxito en 10 de cada 10 intentos en su laboratorio, pero mantiene el proof-of-concept (PoC) privado por ahora.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Riesgo operativo y de seguridad

• CVSS v4: 9.2 (Crítico)
• CVSS v3.1: 8.1 (Alto)
• Complejidad de ataque: Alta, pero alcanzable con conocimientos técnicos medios.

• NGINX desde 0.9.6 (2011, cuando se agregó soporte para regex en map) hasta 1.31.2.
• NGINX Ingress Controller, Gateway Fabric, App Protect WAF e Instance Manager (F5 no publicó versiones parcheadas para estos productos al momento del anuncio).

• DoS: Caída de trabajadores de NGINX, interrupción del servicio.
• RCE: En entornos sin ASLR o con ASLR vulnerable, posible ejecución de código remoto.

Es la tercera vulnerabilidad de desbordamiento de heap en el motor de scripts de NGINX en dos meses:

1. CVE-2026-42945 («Rift», mayo 2026).
2. CVE-2026-9256 (bug de capturas superpuestas en el módulo rewrite).

Todas comparten la misma raíz: el motor de dos pasadas de NGINX confía en su propia medición, pero el estado compartido entre pasadas puede ser alterado.

Escenario de explotación real

Un atacante envía una petición HTTP con:

GET / HTTP/1.1
Host: ejemplo.com

Donde el cuerpo o los headers contienen:

• Un regex que define una captura numerada ($1).
• Un mapa que usa $1 en una expresión de cadena.

Si la configuración cumple con los criterios, NGINX:

1. Mide el buffer necesario para $1.
2. Procesa el mapa, pero la captura $1 es sobrescrita por datos del atacante (más grandes o más pequeños).
3. Escribe en el buffer con el tamaño original, pero con datos del nuevo tamaño → desbordamiento de heap.

Detalles técnicos

Mecanismo del exploit

El motor de scripts de NGINX evalúa expresiones en dos pasadas:

• Las capturas ($1, $2, etc.) se almacenan en un buffer compartido (ngx_http_script_regex_captures).
• Si entre la primera y segunda pasada se sobrescribe este buffer, la escritura posterior usará un tamaño incorrecto.

http {
    map $http_host $new_var {
        default "";
        ~^(?<sub>.+)\.ejemplo\.com$ $sub;  # Captura nombrada 'sub'
    }

    server {
        location / {
            set $combined "$new_var-$1";  # Usa captura numerada $1 Y variable de mapa
            return 200 $combined;
        }
    }
}

> Nota: La vulnerabilidad se activa cuando $1 es sobrescrita entre las dos pasadas, pero el buffer fue dimensionado para el valor original.

Configuraciones no vulnerables

1. Mapas sin regex:

   map $http_host $var { default ""; ejemplo.com 1; }
   

1. Expresiones sin capturas numeradas:

   set $out "$var-$arg_user";  # Solo usa variables, no $1, $2, etc.
   

1. Mapas con capturas nombradas (mitigación temporal):

   map $http_host $var {
       ~^(?<sub>.+)\.ejemplo\.com$ $sub;  # Usa captura nombrada
   }
   set $out "$var-$sub";  # Solo usa capturas nombradas
   

Productos F5 afectados (sin parches publicados al 20/07/2026)

• NGINX Ingress Controller
• NGINX Gateway Fabric
• NGINX App Protect WAF
• NGINX Instance Manager

F5 no respondió a la consulta de The Hacker News sobre si las capturas nombradas cierran todos los vectores de ataque.

Qué deberían hacer los administradores y equipos técnicos

1. Evaluar exposición inmediata

Ejecutar este comando para buscar configuraciones vulnerables (requiere nginx -t):

sudo nginx -t 2>&1 | grep -E 'map.*\$[0-9]+|set.*\$[0-9]+'

Si la salida incluye:

• map con regex y variables como $1, $2, etc.
• set que concatena una variable de mapa con una captura numerada.

> Ejemplo de salida vulnerable:

>

> nginx: [emerg] unknown directive "map" in /etc/nginx/nginx.conf:1
> nginx: configuration file /etc/nginx/nginx.conf test failed
> 

2. Parchear NGINX y NGINX Plus

Ubuntu/Debian

# Verificar versión actual
nginx -v  # Ej: nginx version: nginx/1.25.5

# Actualizar NGINX (stable)
sudo apt update
sudo apt install nginx=1.30.4-1~jammy  # Versión específica para Ubuntu 22.04

# Reiniciar
sudo systemctl restart nginx

Red Hat/CentOS

# Instalar el repositorio oficial de NGINX
sudo yum install -y https://nginx.org/packages/centos/8/x86_64/RPMS/nginx-1.30.4-1.el8.ngx.x86_64.rpm

# Verificar
sudo nginx -v  # Debe mostrar: nginx version: nginx/1.30.4

NGINX Plus

# Actualizar desde el repositorio de F5
sudo apt update && sudo apt install -y nginx-plus=37.0.3.1-1~jammy

3. Mitigación temporal (si no se puede parchear)

F5 recomienda convertir capturas numeradas a capturas nombradas, pero no cierra todos los vectores:

# Configuración vulnerable:
map $http_host $var {
    ~^\d+\.\d+\.\d+\.(\d+)$ $1;  # Captura numerada $1
}

set $out "IP: $1-$var";  # Usa $1 Y $var

# Mitigación parcial (no cierra el vector de Shaw):
map $http_host $var {
    ~^\d+\.\d+\.\d+\.(?<ip>\d+)$ $ip;  # Captura nombrada
}

set $out "IP: $ip-$var";  # Solo usa capturas nombradas

> Advertencia: Stan Shaw confirmó que un mapa que define el mismo grupo nombrado que una captura de location puede activar la vulnerabilidad por otro camino. La única solución completa es parchear.

4. Validar la mitigación

Revisar los logs de NGINX después de aplicar cambios:

sudo tail -f /var/log/nginx/error.log | grep -E 'heap|overflow|script'

> Ausencia de errores no garantiza seguridad: Shaw demostró que el exploit puede operar sin dejar trazas en logs por defecto.

5. Monitorear intentos de explotación

Agregar reglas en WAF (si se usa App Protect WAF) o en el firewall perimetral:

• Bloquear solicitudes con patrones como:

  ^.*\$[0-9]+.*\$[a-zA-Z0-9]+
  

• Monitorear tráfico hacia endpoints que usen map con regex.

6. Planificar respuesta a incidentes

• Priorizar parcheo en servidores expuestos a Internet o con datos sensibles.
• Preparar rollback: tener versiones anteriores de NGINX listas en caso de que el parche genere regresiones.
• Aislar servicios críticos: si NGINX Ingress Controller o App Protect WAF están afectados, evaluar migración temporal a otro controlador de ingress.

Conclusión

CVE-2026-42533 es un recordatorio contundente sobre los riesgos de arquitecturas de dos pasadas en motores de scripts. NGINX no es el único afectado: el mismo patrón de vulnerabilidad (medir un buffer en una pasada, escribir en otra) se repitió en tres CVEs en dos meses. La diferencia aquí es que el exploit es determinista y reproducible, y en sistemas por defecto (como Ubuntu 24.04) puede recuperar direcciones de memoria con una sola petición.

La lección para equipos de DevOps e infraestructura:

1. No confiar en miticaciones temporales: las capturas nombradas no cierran todos los vectores.
2. Priorizar parches: el PoC de Shaw se publicará en 21 días; la historia (como con CVE-2026-42945) sugiere que la explotación masiva comenzará horas después.
3. Automatizar auditorías de configuración: herramientas como la de Stan Shaw (no oficial) pueden escanear configs en busca de patrones vulnerables sin explotarlos.

El parche existe, pero la ventana de riesgo se cierra rápido. Actualizar hoy es la única opción que mitiga el 100% del riesgo.

Fuentes

• The Hacker News: Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution
• F5 Advisory: CVE-2026-42533
• NetBSD Changes (referencia a vulnerabilidades en motores de scripts)