En NGINX Plus y NGINX Open Source se ha identificado la vulnerabilidad crítica CVE-2026-42945 (NGINX Rift, CVSS v4 9.2) en el módulo ngx_http_rewrite_module, que pasó desapercibida durante 18 años y permite la ejecución remota de código o un ataque de denegación de servicio mediante una petición HTTP no autenticada. Se ven afectados servidores web, reverse‑proxy, ingress controllers y WAF basados en NGINX, por lo que los administradores deben actualizar inmediatamente las versiones o cambiar la configuración de las reglas de rewrite, eliminando las expresiones regulares inseguras.

Detalles técnicos de las vulnerabilidades

El defecto de origen NGINX Rift / CVE-2026-42945 fue descubierto por los investigadores del proyecto depthfirst y descrito en detalle en su análisis NGINX Rift. Según el aviso de F5 para los clientes de NGINX (advisory oficial de F5), el problema es un desbordamiento de búfer en el heap en el módulo ngx_http_rewrite_module, que se produce con una combinación específica de directivas y expresiones regulares.

Las condiciones de explotación de CVE-2026-42945 son las siguientes:

• se utiliza el módulo ngx_http_rewrite_module con la directiva rewrite,
• a continuación aparece una directiva rewrite, if o set,
• en las reglas se emplean capturas PCRE anónimas ($1, $2, etc.),
• en la cadena de sustitución hay un carácter ?.

Un atacante remoto y no autenticado, capaz de enviar peticiones HTTP a un servidor vulnerable, puede construir un URI especialmente preparado que provoque un desbordamiento de heap en el proceso worker de NGINX. Con ASLR activado, esto es al menos una forma fiable de provocar el fallo y reinicio del worker (denegación de servicio). Con ASLR desactivado, según la evaluación de depthfirst y F5, pasa a ser viable la ejecución remota de código en el contexto del proceso NGINX. Véase también la entrada en NVD: CVE-2026-42945.

La particularidad de la vulnerabilidad es que:

• su explotación no requiere autenticación ni acceso previo;
• una sola petición basta para provocar el desbordamiento de heap;
• los bytes que se escriben fuera del bloque asignado están completamente controlados por el atacante a través del URI, lo que convierte la corrupción de memoria en algo dirigido y no aleatorio;
• las peticiones repetidas pueden hacer que los procesos worker entren en un ciclo de caídas, reduciendo la disponibilidad de todos los sitios del mismo servidor.

Según F5, la vulnerabilidad afecta a:

• NGINX Plus R32–R36 (corregido en R32 P6 y R36 P4);
• NGINX Open Source 1.0.0–1.30.0 (corregido en 1.30.1 y 1.31.0);
• NGINX Open Source 0.6.27–0.9.7 (no se prevén correcciones);
• una serie de productos basados en NGINX: NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS, NGINX Gateway Fabric, NGINX Ingress Controller, en rangos de versiones concretos indicados en el advisory de F5.

Vulnerabilidades adicionales en NGINX

Al mismo tiempo se han corregido otras tres vulnerabilidades de gravedad media y alta:

• CVE-2026-42946 (CVSS v4 8.3): asignación de memoria excesiva en los módulos ngx_http_scgi_module y ngx_http_uwsgi_module. Un atacante no autenticado con capacidad para interceptar y modificar las respuestas del servidor upstream (adversary-in-the-middle) puede generar respuestas tales que NGINX gestione incorrectamente la memoria del proceso worker, lo que conduce a la lectura de datos de su memoria o al reinicio del proceso cuando se usan las directivas scgi_pass o uwsgi_pass. Véanse el advisory sobre CVE-2026-42946 y la entrada CVE-2026-42946.
• CVE-2026-40701 (CVSS v4 6.3): use-after-free en ngx_http_ssl_module. Condición: ssl_verify_client está configurada en on u optional, y ssl_ocsp en on. Esto permite a un atacante remoto y no autenticado modificar datos en cierta medida o provocar el reinicio del proceso worker. Véanse el advisory sobre CVE-2026-40701 y CVE-2026-40701.
• CVE-2026-42934 (CVSS v4 6.3): lectura fuera de los límites del búfer en ngx_http_charset_module. Existe riesgo de divulgación del contenido de la memoria o reinicio del worker cuando se configuran simultáneamente las directivas charset, source_charset, charset_map y proxy_pass con la desactivación del almacenamiento en búfer (off). Véanse el advisory sobre CVE-2026-42934 y CVE-2026-42934.

En los avisos originales no se menciona explotación confirmada de estas vulnerabilidades en ataques reales, pero el perfil técnico de CVE-2026-42945 la convierte en un objetivo atractivo para la automatización y el escaneo masivo.

Contexto y características de la amenaza

Tradicionalmente, NGINX se utiliza como servidor web de alto rendimiento y reverse‑proxy, así como base para ingress controllers en Kubernetes y soluciones comerciales de F5. El fallo en el mecanismo de rewrite, presente desde las primeras versiones (0.6.x), ilustra bien los riesgos de la lógica de «frontera»: combinaciones poco habituales de directivas, integración con PCRE y patrones URI complejos históricamente se prueban peor, pero se emplean de forma activa en configuraciones reales.

Es crucial que el segmento de código vulnerable se ejecute antes de cualquier comprobación de autenticación de la aplicación o de la lógica de negocio. En la práctica, NGINX actúa aquí como superficie de ataque en sí misma. Esto incrementa el valor de la vulnerabilidad para los atacantes: basta con que el puerto HTTP sea accesible por red, incluso si detrás de NGINX hay un backend bien protegido.

Las vulnerabilidades adicionales (SCGI/UWSGI, SSL, charset) ilustran otra clase de problemas: cuando NGINX confía en el contenido procedente del servidor upstream o de la infraestructura de validación de certificados (OCSP), los errores en el procesamiento de esos datos permiten sobrepasar los límites esperados de la memoria. En escenarios en los que el atacante controla o puede suplantar las respuestas del upstream, estos defectos se convierten en una potente herramienta para leer fragmentos de memoria o desactivar servicios.

Evaluación del impacto

Están en mayor riesgo:

• organizaciones que usan NGINX como servidor web público o reverse‑proxy con ngx_http_rewrite_module activo, especialmente con un gran número de reglas complejas;
• entornos de nube y proveedores de hosting donde una única instancia de NGINX da servicio a múltiples inquilinos: la explotación con éxito de CVE-2026-42945 puede afectar a todos los clientes del nodo;
• clústeres de Kubernetes con NGINX Ingress Controller, así como instalaciones de NGINX App Protect WAF/DoS y NGINX Gateway Fabric en versiones vulnerables;
• sistemas donde ASLR está desactivado o debilitado (por ejemplo, appliances especializados o entornos muy optimizados para el rendimiento).

Si no se adoptan medidas de respuesta, son posibles las siguientes consecuencias:

• compromiso completo del nodo mediante RCE en el proceso NGINX (CVE-2026-42945) con posterior movimiento lateral en la red;
• compromiso de datos confidenciales debido a la lectura de fragmentos de memoria del proceso worker (CVE-2026-42946, CVE-2026-42934), donde pueden residir tokens, cookies, partes de peticiones y respuestas;
• denegación de servicio a gran escala: caídas cíclicas de los procesos worker, indisponibilidad de sitios y API, aumento de latencia y errores 502/504;
• pérdidas indirectas: riesgos de reputación, incumplimiento de SLA, posibles sanciones por filtración de datos personales.

Recomendaciones prácticas

1. Priorización y plazos

• Tratar CVE-2026-42945 como crítica: la actualización o la aplicación de una solución temporal debe tener prioridad «inmediata/en las próximas horas» en los nodos expuestos públicamente.
• El resto de vulnerabilidades (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) tienen prioridad «alta» y deben incluirse en el próximo intervalo de mantenimiento.

2. Actualización a versiones corregidas

• Para NGINX Plus, actualizar al menos a R32 P6 o R36 P4 o a versiones más recientes que incluyan las correcciones (véase el advisory de F5).
• Para NGINX Open Source, pasar a 1.30.1 o 1.31.0 y superiores.
• Para productos basados en NGINX (Ingress Controller, App Protect WAF/DoS, Gateway Fabric, Instance Manager, F5 WAF for NGINX), comparar las versiones actuales con los rangos indicados en los correspondientes advisory de F5 y actualizar a los lanzamientos recomendados.
• Para ramas muy antiguas 0.6.27–0.9.7, donde no se prevén correcciones, la única opción es migrar a versiones soportadas.

3. Solución temporal para CVE-2026-42945

Si no es posible actualizar de inmediato, se recomienda modificar la configuración de las reglas de rewrite, como describen F5 y depthfirst:

• Localizar todas las directivas rewrite a las que sigue rewrite, if o set, en las que:
  • se usan capturas anónimas del tipo $1, $2, etc.;
  • en la cadena de sustitución aparece el carácter ?.
• Reescribir las expresiones regulares utilizando capturas con nombre de PCRE, por ejemplo:
  • antes: rewrite ^/user/(\d+)\?(.*)$ /profile.php?id=$1?$2;
  • después: rewrite ^/user/(?<uid>\d+)\?(?<rest>.*)$ /profile.php?id=$uid?$rest;
• Comprobar tras los cambios que la funcionalidad de redirecciones se mantiene y reiniciar NGINX.

La esencia de la solución es transformar las capturas anónimas en capturas con nombre, lo que cambia la ruta de procesamiento de datos en el código de NGINX y elimina el escenario vulnerable.

4. Reducción de riesgo para las vulnerabilidades adicionales

Hasta la actualización, es posible reducir temporalmente la superficie de ataque:

• Para CVE-2026-42946: en la medida de lo posible, limitar o desactivar temporalmente scgi_pass y uwsgi_pass en los bordes externos, especialmente donde el upstream pueda estar bajo control de terceros.
• Para CVE-2026-40701: si la criticidad de la validación de cliente y OCSP no es elevada, considerar la desactivación temporal de ssl_ocsp on o la relajación de ssl_verify_client, tras evaluar el impacto sobre los requisitos de autenticación de cliente.
• Para CVE-2026-42934: minimizar el uso de charset_map combinado con proxy_pass y almacenamiento en búfer desactivado, siempre que sea posible sin perjudicar al negocio.

5. Comprobación de exposición y monitorización

• Verificar la versión de NGINX con el comando nginx -v y compararla con los rangos de versiones vulnerables.
• Analizar la configuración:
  • buscar en nginx.conf y ficheros incluidos las claves rewrite, $1, $2, ?;
  • identificar las reglas que encajen con el patrón descrito.
• Activar o reforzar el registro de errores de NGINX y el registro del sistema:
  • prestar atención a caídas repetidas de los procesos worker, señales de segmentation fault, reinicios cíclicos;
  • correlacionar estos eventos con peticiones HTTP sospechosas que contengan URI poco habituales con ? y patrones complejos.
• Asegurarse de que ASLR está activado en los servidores a nivel de sistema operativo como defensa adicional frente a RCE, incluso después de instalar los parches.

La acción clave para los responsables de infraestructuras basadas en NGINX es actualizar lo antes posible NGINX Plus, NGINX Open Source y los productos relacionados a versiones que incluyan las correcciones de CVE-2026-42945 y las vulnerabilidades asociadas. En caso de retrasos en la actualización, debe realizarse de inmediato una auditoría de las reglas de rewrite, sustituyendo las capturas anónimas por capturas con nombre en todas las configuraciones expuestas a Internet.