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.
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/(?[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