R32 a R36<\/strong>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nLa vulnerabilidad se encuentra en el m\u00f3dulo ngx_http_rewrite_module<\/strong> y solo se manifiesta cuando se cumplen ciertas condiciones en las directivas rewrite<\/strong>, if<\/strong> o set<\/strong> que usan capturas PCRE sin nombre ($1<\/strong>, $2<\/strong>, etc.) con cadenas de reemplazo que contienen el car\u00e1cter ?<\/strong>.<\/p>\n\n\n\nDescripci\u00f3n<\/h2>\n\n\n\n
Recientemente se ha publicado una vulnerabilidad llamada CVE\u20112026\u201142945 con un score CVSSv3.1 8.1<\/strong>, apodada \u201cNGINX Rift\u201d<\/em>, es un heap buffer overflow<\/strong> en el m\u00f3dulo ngx_http_rewrite_module de NGINX que puede ser explotado de forma remota mediante una \u00fanica petici\u00f3n HTTP especialmente dise\u00f1ada. Bajo configuraci\u00f3n vulnerable, permite a un atacante no autenticado provocar reinicios de los procesos worker<\/strong> (Denial of Service), y en sistemas donde ASLR est\u00e1 desactivado o debilitado<\/strong>, puede abrir la puerta a ejecuci\u00f3n remota de c\u00f3digo (RCE)<\/strong>.<\/p>\n\n\n\nF5, como CNA de este CVE, eval\u00faa el fallo con una severidad de 9.2 (CRITICAL) en CVSS v4.0<\/strong> y 8.1 (High) en CVSS v3.1, y confirma que el bug lleva presente en el c\u00f3digo desde 2008, afectando a todas las versiones de NGINX Open Source desde la 0.6.27. Dado que NGINX se usa masivamente como reverse proxy y front door de aplicaciones web y APIs, el impacto potencial para infraestructuras empresariales e ISPs es muy alto.<\/p>\n\n\n\nCondiciones para que exista la vulnerabilidad<\/strong><\/p>\n\n\n\nEl problema est\u00e1 en c\u00f3mo ngx_http_rewrite_module <\/strong>gestiona determinadas reglas que combinan:<\/p>\n\n\n\n\n- Una directiva\u00a0rewrite,\u00a0if\u00a0o\u00a0set<\/strong>\u00a0que utiliza\u00a0capturas PCRE sin nombre<\/strong>\u00a0($1,\u00a0$2, \u2026)<\/li>\n\n\n\n
- Una\u00a0cadena de reemplazo que incluye\u00a0?<\/strong>\u00a0(habitual cuando se reescriben rutas y query strings)<\/li>\n\n\n\n
- Patrones donde ciertos caracteres como\u00a0+,\u00a0%\u00a0y\u00a0&\u00a0pueden \u201cexpandirse\u201d al re\u2011escaparse, haciendo que la longitud resultante sea mayor que la calculada inicialmente.<\/li>\n<\/ul>\n\n\n\n
En estas condiciones, el m\u00f3dulo calcula un tama\u00f1o de buffer insuficiente para el resultado, pero aun as\u00ed escribe la cadena re\u2011escapada, lo que provoca que la escritura se desborde m\u00e1s all\u00e1 del final del buffer<\/strong> en el heap.<\/p>\n\n\n\nVector de ataque<\/strong><\/p>\n\n\n\nUn atacante remoto puede:<\/p>\n\n\n\n
\n- Enviar\u00a0una \u00fanica petici\u00f3n HTTP<\/strong>\u00a0cuidadosamente construida hacia un servidor NGINX que tenga reglas\u00a0rewrite\u00a0vulnerables.<\/li>\n\n\n\n
- Forzar que se ejecute la ruta de c\u00f3digo donde se produce el desbordamiento.<\/li>\n\n\n\n
- Como m\u00ednimo, provocar que el worker de NGINX se caiga y se reinicie, generando un\u00a0DoS intermitente<\/strong>\u00a0o continuado.<\/li>\n\n\n\n
- En entornos donde\u00a0ASLR est\u00e1 desactivado<\/strong>\u00a0(por ejemplo, sistemas legacy o configuraciones endurecidas manualmente pero mal testeadas), el contenido controlado que se escribe fuera del buffer puede permitir\u00a0RCE<\/strong>\u00a0si el atacante consigue una primitiva de corrupci\u00f3n \u00fatil.<\/li>\n<\/ul>\n\n\n\n
Importante para sysadmins: el fallo no requiere autenticaci\u00f3n, ni m\u00f3dulos \u201cex\u00f3ticos\u201d: solo una configuraci\u00f3n desafortunada del propio <\/p>\n\n\n\n
A las pocas horas de publicarse el advisory, varios investigadores han liberado PoC p\u00fablicos para CVE\u20112026\u201142945, incluyendo exploits funcionales en GitHub y write\u2011ups t\u00e9cnicos detallando la cadena de explotaci\u00f3n. Esto reduce dr\u00e1sticamente la ventana de tiempo entre la divulgaci\u00f3n y la explotaci\u00f3n masiva, por lo que se recomienda tratar esta vulnerabilidad como cr\u00edtica y de explotaci\u00f3n probable a muy corto plazo, priorizando la aplicaci\u00f3n de parches y\/o la reconfiguraci\u00f3n de reglas rewrite vulnerables.<\/p>\n\n\n\n
Mitigaci\u00f3n<\/h2>\n\n\n\n
Mientras no se pueda aplicar actualizaci\u00f3n, F5 y varios vendors recomiendan las siguientes mitigaciones temporales:<\/p>\n\n\n\n
\n- Revisar y corregir reglas\u00a0rewrite\u00a0vulnerables<\/strong>\n
\n- Auditar la configuraci\u00f3n NGINX (nginx.conf\u00a0y\u00a0conf.d\/*.conf) buscando directivas\u00a0rewrite,\u00a0if\u00a0y\u00a0set\u00a0que:\n
\n- usen capturas\u00a0$1,\u00a0$2, etc. y<\/li>\n\n\n\n
- incluyan\u00a0?\u00a0en la cadena de reemplazo.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Reescribir estas reglas para evitar combinaciones que provoquen re\u2011escapado \u201cexpandido\u201d (por ejemplo, minimizando uso de\u00a0+,\u00a0%,\u00a0&\u00a0en patrones o cambiando la forma de construir la query string).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Reducir superficie de exposici\u00f3n<\/strong>\n
\n- Limitar el acceso desde Internet solo a los endpoints necesarios (WAF, reverse proxies adicionales, VPN, etc.).<\/li>\n\n\n\n
- Usar listas de control de acceso (ACL) o firewalls para segmentar qui\u00e9n puede llegar a NGINX si se trata de paneles internos o APIs administrativas.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Endurecer el sistema operativo<\/strong>\n
\n- Verificar que\u00a0ASLR est\u00e9 habilitado<\/strong>\u00a0en todos los hosts que ejecutan NGINX; esto baja de forma significativa la probabilidad de explotaci\u00f3n RCE, aunque no evita el DoS.<\/li>\n\n\n\n
- Asegurar que otras mitigaciones como stack canaries, RELRO y PIE est\u00e9n activas seg\u00fan la distro.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Monitorizaci\u00f3n y detecci\u00f3n<\/strong>\n
\n- Activar logs de error y acceso y\u00a0monitorizar reinicios frecuentes<\/strong>\u00a0de procesos worker NGINX, especialmente en hosts expuestos a Internet.<\/li>\n\n\n\n
- Revisar herramientas EDR\/NIDS para detectar patrones de request repetitivos hacia paths que disparan reglas\u00a0rewrite\u00a0complejas.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
Soluci\u00f3n:<\/h2>\n\n\n\n
La remediaci\u00f3n definitiva pasa por actualizar NGINX a versiones corregidas<\/strong> seg\u00fan la gu\u00eda de F5:<\/p>\n\n\n\n\n- NGINX Open Source<\/strong>\n
\n- Actualizar a una versi\u00f3n\u00a0posterior a 1.30.0<\/strong>\u00a0donde el bug ha sido corregido (por ejemplo, versiones 1.30.x o 1.31.x ya parcheadas seg\u00fan tu distribuci\u00f3n).<\/li>\n\n\n\n
- En distros Linux, aplicar los paquetes de seguridad provistos por el vendor (AlmaLinux, Debian, Ubuntu, etc.) que ya incorporan el fix para CVE\u20112026\u201142945.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- NGINX Plus (F5)<\/strong>\n
\n- Actualizar a las versiones\u00a0R37 o superiores<\/strong>, seg\u00fan el advisory K000161019 y la Quarterly Security Notification de mayo 2026.<\/li>\n\n\n\n
- Seguir la gu\u00eda oficial de upgrade de F5 para NGINX Plus, validando compatibilidad con m\u00f3dulos comerciales y entorno (K000160932 y documentaci\u00f3n de actualizaci\u00f3n de NGINX Plus).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
- Plan de actualizaci\u00f3n recomendado<\/strong>\n
\n- Probar primero la actualizaci\u00f3n en un entorno de\u00a0pre\u2011producci\u00f3n<\/strong>\u00a0que replique las reglas\u00a0rewrite\u00a0y el tr\u00e1fico t\u00edpico.<\/li>\n\n\n\n
- Medir impacto en rendimiento y compatibilidad (m\u00f3dulos de terceros, WAF, Lua, etc.).<\/li>\n\n\n\n
- Programar ventana de mantenimiento para producci\u00f3n y aplicar la actualizaci\u00f3n siguiendo la gu\u00eda de rollback (snapshot de VM, backup de configs).<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
En todos los casos, se recomienda documentar expl\u00edcitamente que el riesgo asociado a CVE\u20112026\u201142945 queda mitigado solo cuando se ha actualizado NGINX<\/strong> y, en paralelo, se han revisado las reglas rewrite problem\u00e1ticas.<\/p>\n\n\n\n