NGINX Rift: vulnerabilidad crítica en NGINX y F5

Investigadores descubrieron una vulnerabilidad crítica de desbordamiento de búfer de 18 años de antigüedad en NGINX, denominada NGINX Rift. "NGINX Plus y NGINX Open Source tienen una vulnerabilidad en el módulo ngx_http_rewrite_module", dijo F5.

NGINX Rift (código) es una vulnerabilidad crítica de desbordamiento de búfer en el montón, presente tanto en NGINX Plus como en NGINX Open Source, que había permanecido sin detectar en el código fuente durante dieciocho años. Esta vulnerabilidad, identificada como CVE-2026-42945 (CVSS 9.2), y sus implicaciones van mucho más allá de un ciclo de parches rutinario.

El desbordamiento de búfer del módulo ngx_http_rewrite_module a las versiones de NGINX desde la 0.6.27 hasta la 1.30.0. La explotación exitosa puede permitir a un atacante no autenticado bloquear procesos de trabajo o ejecutar código remoto mediante solicitudes HTTP manipuladas. Sin embargo, cabe destacar que la ejecución de código solo es posible en dispositivos donde la aleatorización del espacio de direcciones (ASLR), una medida de seguridad contra ataques basados ​​en memoria, esté desactivada.

"Para que sea vulnerable, requiere una configuración específica de NGINX y que un atacante conozca o descubra dicha configuración para explotarla", explicó el investigador de seguridad Kevin Beaumont. 

Los últimos hallazgos de VulnCheck muestran que los ciberdelincuentes han comenzado a explotar la vulnerabilidad, detectándose intentos de ataque contra sus redes honeypot. Se desconoce la naturaleza de la actividad de ataque y sus objetivos finales. Se recomienda a los usuarios aplicar las últimas correcciones de F5 para proteger sus redes contra las amenazas activas.

NGINX impulsa una parte sustancial de Internet, proxies inversos, balanceadores de carga, controladores de entrada y plataformas de entrega de aplicaciones, lo que hace que la superficie de ataque sea excepcionalmente amplia. La vulnerabilidad reside en `ngx_http_rewrite_module`, un componente incluido en todas las compilaciones estándar de NGINX, y el desencadenante es un patrón de configuración lo suficientemente común como para que una parte significativa de las implementaciones reales se vean afectadas sin que nadie lo sepa.

La raíz del problema reside en cómo NGINX gestiona las directivas de reescritura que combinan grupos de captura PCRE sin nombre, la sintaxis habitual `$1, $2`, con una cadena de reemplazo que contiene un signo de interrogación, cuando va seguida de otra directiva de reescritura, `if` o `set` en el mismo ámbito.

El mecanismo es sutil, pero el resultado no lo es. Cuando aparece un signo de interrogación en el reemplazo, se activa una bandera interna en el motor de scripts que nunca se borra. Un cálculo de longitud posterior utiliza un submotor nuevo que no tiene en cuenta el escape de URI, lo que produce un búfer del tamaño de los bytes sin procesar. Sin embargo, la escritura real se ejecuta en el motor original, donde la bandera de escape sigue activa, y caracteres como `+`, `%` y `&` se expanden en dos bytes durante la copia. El resultado es una escritura que se ejecuta de forma determinista más allá del final del búfer asignado, un desbordamiento de pila controlado por el contenido de la URI del atacante.

A diferencia de muchos errores de corrupción de memoria donde el desbordamiento está influenciado por un estado interno impredecible, los bytes escritos más allá de la asignación en este caso se derivan directamente de la solicitud del atacante. La corrupción está controlada, no es aleatoria, lo que mejora significativamente la fiabilidad de la explotación.

"Un atacante que pueda acceder a un servidor NGINX vulnerable a través de HTTP puede enviar una única solicitud que desborde la pila en el proceso de trabajo y logre la ejecución remota de código", continúa el informe. "No se requiere autenticación, acceso previo ni una sesión existente".

En sistemas con ASLR deshabilitado, una configuración que aún se encuentra en algunos entornos de producción, la ejecución remota de código en el proceso de trabajo de NGINX se puede lograr con una sola solicitud HTTP manipulada. Incluso con ASLR habilitado, las solicitudes repetidas pueden usarse para provocar un bucle de fallos en los procesos de trabajo, lo que degrada la disponibilidad de todas las aplicaciones servidas por esa instancia.

"Los bytes escritos después de la asignación se derivan de la URI del atacante, por lo que la corrupción está controlada por el atacante, no es aleatoria. Las solicitudes repetidas también pueden usarse para mantener a los procesos de trabajo en un bucle de fallos y degradar la disponibilidad de todos los sitios servidos por la instancia."

La vulnerabilidad afecta a una amplia gama de productos F5 y NGINX.

• NGINX Open Source 0.6.27 through 1.30.0
• NGINX Plus R32 through R36.
• NGINX Instance Manager 2.16.0 through 2.21.1.
• F5 WAF for NGINX 5.9.0 through 5.12.1.
• NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0.
• F5 DoS for NGINX 4.8.0.
• NGINX App Protect DoS 4.3.0 through 4.7.0.
• NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.5.1.
• NGINX Ingress Controller 3.5.0 through 3.7.2, 4.0.0 through 4.0.1, and 5.0.0 through 5.4.1.

Tras la divulgación responsable de la vulnerabilidad, se publicaron versiones corregidas el 21 de abril de 2026. Los usuarios de NGINX Open Source deben actualizar a la versión 1.30.1 o 1.31.0. Los usuarios de NGINX Plus R36 deben aplicar R36 P4, mientras que los usuarios de R32 deben aplicar R32 P6. Las correcciones para Instance Manager, App Protect, Gateway Fabric e Ingress Controller están disponibles en las ramas de lanzamiento actualizadas.

La divulgación de Rift vino acompañada de parches para tres vulnerabilidades adicionales en NGINX Plus y NGINX Open Source:

• CVE-2026-42946 (CVSS 8.3): Un fallo de asignación excesiva de memoria en los módulos ngx_http_scgi_module y ngx_http_uwsgi_module.
• CVE-2026-40701 (CVSS 6.3): Un fallo de uso de memoria liberada en ngx_http_ssl_module que puede ser activado por un atacante remoto no autenticado.
• CVE-2026-42934 (CVSS 6.3): Una lectura fuera de límites en ngx_http_charset_module puede exponer el contenido de la memoria o provocar el reinicio de un proceso.

La acción recomendada es sencilla: actualizar. Reinicie NGINX después de instalar la versión corregida para que los procesos recarguen el binario parcheado.

Para entornos donde no sea factible una actualización inmediata, existe una solución alternativa a nivel de configuración específica para CVE-2026-42945. La vulnerabilidad solo se activa cuando se combinan capturas PCRE sin nombre con signos de interrogación en las cadenas de reemplazo. Reemplazar las capturas sin nombre ($1, $2) por capturas con nombre elimina la ruta de código vulnerable sin necesidad de tiempo de inactividad.

Una configuración vulnerable como:

rewrite ^/users/([0-9]+)$ /profile.php?id=$1 last;

se vuelve seguro al reescribir:

^/users/(?<user_id>[0-9]+)$ /profile.php?id=$user_id last;

Es un pequeño cambio con un valor de protección significativo mientras se implementan los parches.

No hay informes de que esta vulnerabilidad haya sido explotada en la práctica al momento de su divulgación, y DepthFirst coordinó la publicación con F5 para garantizar que las correcciones estuvieran disponibles junto con el aviso público. Esta ventana de tiempo no permanecerá abierta indefinidamente.

Fuente: SecurityAffairs

Suscríbete a nuestro Boletín