NGINX Rift - nuevo exploit para NGINX

• NGINX Rift es una PoC de ejecución remota de código para CVE-2026-42945, un desbordamiento crítico de búfer en el heap en ngx_http_rewrite_module de NGINX
• Esta vulnerabilidad permite ejecución remota de código sin autenticación en servidores que usan las directivas rewrite y set
• El problema proviene de un bug introducido en 2008, causado porque el paso de cálculo de longitud y el paso de copia del motor de scripts de NGINX manejan de forma distinta la bandera is_args
• Si la cadena de sustitución de rewrite contiene ?, en el motor principal se establece is_args, pero el cálculo de longitud se ejecuta en un submotor recién inicializado en 0, por lo que solo devuelve la longitud de la captura original
• En la etapa de copia, con is_args = 1, se invocan ngx_escape_uri y NGX_ESCAPE_ARGS, haciendo que cada byte escapable se expanda a 3 bytes y provocando que el búfer del heap, subasignado, se desborde con datos de URI controlados por el atacante
• El exploit usa heap feng shui entre solicitudes para corromper el puntero cleanup de un ngx_pool_t adyacente y, como no puede insertar bytes nulos en los bytes del URI, realiza el spray a través del cuerpo de un POST
• El puntero corrompido se redirige a un ngx_pool_cleanup_s falso y se configura para invocar system() al destruir el pool
• Junto con CVE-2026-42945, el sistema de análisis de seguridad de depthfirst también descubrió de forma autónoma, en una sola incorporación del código fuente de NGINX, otros 3 problemas de corrupción de memoria: CVE-2026-42946, CVE-2026-40701 y CVE-2026-42934
• Las versiones afectadas son NGINX Open Source 0.6.27–1.30.0 y NGINX Plus R32–R36; las versiones corregidas indicadas son Open Source 1.31.0/1.30.1 y Plus R36 P4/R35 P2/R32 P6
• El aviso completo del proveedor está en https://my.f5.com/manage/s/article/K000160932, y los detalles técnicos se tratan en el technical write-up
• La PoC fue probada en Ubuntu 24.04.3 LTS y ofrece un flujo para levantar un contenedor vulnerable de NGINX y ejecutar una shell en este orden: ./setup.sh, docker compose -f env/docker-compose.yml up, python3 poc.py --shell

[GN⁺]

Opiniones en Hacker News

• Como responsable de seguridad, me cansa ver tantas reacciones que afirman o insinúan que este problema da mucho menos miedo solo porque el exploit publicado no hace bypass de ASLR
  El texto original afirma que hay una forma de saltarse ASLR de manera confiable con este ataque, y me parece razonable creerlo como hipótesis por defecto incluso sin pruebas
  ASLR es solo una técnica de defensa en profundidad que hace más difícil la explotación, y en la mayoría de los casos, con tiempo y habilidad, terminan encontrándole bypass a ASLR
  Por culpa de los agentes LLM, esa barrera de tiempo y habilidad también está bajando cada pocas semanas, así que es cuestión de tiempo para que aparezca un exploit completamente weaponized, ya sea público o privado
  Decir “si tienes ASLR activado no es peligroso” es claramente falso, y muy dañino para quienes se lo crean
  La creencia equivocada de que no hace falta preocuparse por una vulnerabilidad de seguridad porque las mitigaciones pueden dificultar el exploit ya ha causado mucho daño en el pasado
  Qué bueno que existan mitigaciones modernas, pero hay que parchear lo antes posible, y si eres un vendor, no deberías tratar un reporte de vulnerabilidad como inválido solo porque el investigador no mostró un bypass de ASLR; hay que corregir la causa raíz

  • Las vulnerabilidades accesibles de forma remota no deben tomarse a la ligera
    Aun así, por ahora los prerrequisitos se ven algo inusuales
    Llevo 10 años usando nginx en varias configuraciones y nunca he usado rewrite junto con set
  • Se puede asumir con seguridad que quienes dicen “la IA va a resolver la ciberseguridad” y quienes dicen “si ASLR está activado, está bien” se solapan 1:1
    Y además siempre dicen “cyber”
  • No estoy de acuerdo con ese enfoque, o al menos lo expresaría distinto
    ASLR se parece a una contraseña extra que hay que adivinar, tiene cierta entropía y normalmente es estable
    Si la vulnerabilidad no incluye una parte de filtración de información, ASLR puede mitigarla por completo, o bien hace falta una segunda vulnerabilidad
    Esa es otra discusión
    ASLR puede mitigar por completo vulnerabilidades individuales, pero no puede impedir una cadena de explotación
    Aun así, para convencer a la gente de parchear rápido, creo que es mejor apoyarse en la posibilidad de una segunda vulnerabilidad que genere una filtración de información
    Las cadenas de exploit son peligrosas con vulnerabilidades de cualquier tipo
  • Es difícil impedir que se difunda información incorrecta en internet, y la mayoría ni siquiera sabe que está equivocada
    Lo realmente dañino es creer a ciegas en comentarios aleatorios de internet expresados con total seguridad
    Desarrollar la capacidad de detectar eso ayuda no solo en seguridad, sino también en otros ámbitos
  • Cuando leo un reporte de ejecución remota de código en software expuesto al internet público, normalmente actualizo en pocos minutos
    Por eso leo este tipo de reportes, y hay que tomárselos en serio
    Si no, pronto te comprometen la máquina
    Últimamente parece que muchos exploits públicos de ejecución remota de código salen sin aviso previo, y al menos me gustaría que dieran unos minutos para actualizar el software
    Se parece a finales de los 80 y principios de los 90, cuando caían bugs de sendmail explotables de forma remota y no había salvaguardas en la divulgación
    Si no lees estos reportes o los lees demasiado tarde, millones de máquinas pueden verse comprometidas
    Actualmente nginx ocupa alrededor del 39–43% del mercado de servidores web públicos, así que es bastante serio

• Este caso es bastante malo, pero tiene prerrequisitos
  Requiere una directiva rewrite cuyo string de reemplazo contenga un signo de interrogación, seguida por una directiva set que haga referencia a un grupo de captura de regex
  Ejemplo: set $var $1
  Además, la prueba de concepto asume ASLR desactivado

  • Ejemplo: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...
  • ¿Existe alguna distribución que desactive ASLR por defecto?
    Incluso si se desactiva manualmente, nginx no me viene a la mente como un candidato probable para eso
  • ¿Hoy en día casi no se usa rewrite, no?
    Siento que era más de la vieja época de PHP y Apache

• La página oficial de F5 está aquí: https://my.f5.com/manage/s/article/K000161019
  Como ya se ha mencionado en otros lados, ASLR sí protege
  Como mitigación mientras llegan las versiones corregidas para las plataformas afectadas, recomiendan “usar capturas con nombre en lugar de capturas sin nombre en las definiciones de rewrite”
  Dicen: “para mitigar la vulnerabilidad en este ejemplo, reemplace $1 y $2 por las capturas con nombre correspondientes $user_id y $section”
  F5 ya parchó 1.31.0 y 1.30.1
  OpenResty tiene parches para 1.27 y 1.29: https://github.com/openresty/openresty/commit/ee60fb9cf645c9...
  El avance de OpenResty, el servidor de aplicaciones Lua basado en Nginx, puede verse aquí: https://github.com/openresty/openresty/issues/1119

• La prueba de concepto desactiva ASLR: https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...

  • Los procesos worker se crean con fork desde el master, así que reciben el mismo layout de memoria
    Se puede hacer que los workers fallen ilimitadamente
    Hay una alta probabilidad de que eso permita construir un oráculo de lectura
    Al menos parece posible provocar una denegación de servicio estable
    Análisis completo de Depth First: https://depthfirst.com/research/nginx-rift-achieving-nginx-r...

• ¿Hay alguna buena alternativa a Apache y Nginx que esté escrita en un lenguaje con seguridad de memoria y que no tenga tantos agujeros de seguridad?
  Revisé brevemente Jetty, escrito en Java, y Caddy, escrito en Go, pero no me queda claro que sean mejores, dado que Jetty tiene historial de otros tipos de vulnerabilidades, como inyección de shell

  • La seguridad de memoria ayuda, pero no detiene todas las amenazas
    Hoy en día quienes operan infraestructura deberían familiarizarse con la defensa activa de MAC, es decir, SELinux y AppArmor
    Antes tenían mucha fricción, pero ahora hay más herramientas que facilitan su uso
    https://presentations.nordisch.org/apparmor/
    https://github.com/nobody43/apparmor-profiles/blob/master/ng...
    https://github.com/nobody43/apparmor-suggest
    Por cierto, ambos repositorios los hice yo
  • En software usado a la escala de Apache y nginx, es inevitable que exista un historial de vulnerabilidades
    El hecho de que ambos hayan mantenido su cuota de mercado durante tanto tiempo es, de hecho, una buena señal
  • Caddy fue realmente fácil de usar
    Pero ese modelo donde, en lugar de un sistema de plugins decente, terminas con miles de binarios según la combinación de plugins que quieras, no me convence mucho
    Aun así, si lo compilas desde el código fuente, es bastante limpio y simple
  • Apache y probablemente también Nginx tienen una cantidad enorme de funciones y componentes
    La mayoría de los servidores HTTP alternativos reducen mucho el alcance, así que primero hay que decidir qué funcionalidades se necesitan
    No he visto muchas discusiones sobre servidores HTTP en lenguajes con seguridad de memoria
    Los tres grandes servidores en C — Apache, Nginx y lighttpd — son bastante sólidos, y no parece que mucha gente quiera migrar a un proyecto nuevo solo por el lenguaje
    Además, si eliges la mayoría de los lenguajes con seguridad de memoria, también terminas aceptando su runtime, a veces enorme, o su máquina virtual y componentes asociados
    Si es un servidor web en Java, existe la posibilidad de que use log4j, como suele pasar con proyectos Java aleatorios
  • Para uso como balanceador de carga, HAProxy lo está haciendo muy bien

• Eso de “el exploit usa heap feng shui entre solicitudes (cross-request heap feng shui)”... es la primera vez que veo feng shui usado de esta manera

• ¿Esto ya está parchado en Debian 12?
  Aun así, ¿se puede asumir que no te afecta si no usas rewrite ni set en ningún lado?

  • https://security-tracker.debian.org/tracker/CVE-2026-42945
  • Ubuntu ya estaba parchado hasta esta mañana
    Parece que Debian todavía no ha parchado trixie
  • Me parece muy raro usar nginx sin usar al menos set
    La mayoría de los casos de uso de nginx consisten en terminar TLS y pasar las solicitudes a node/php/go, etc.
    Por eso asumía que habría alguna línea como proxy_set_header X-Host $host; con un set que incluyera datos controlados por el atacante
    Corrección: parece que las capturas con nombre no están afectadas
    Si no hay ningún $1 en alguna parte, probablemente esté bien

• Mejor enlace:
  https://depthfirst.com/research/nginx-rift-achieving-nginx-r... (https://news.ycombinator.com/item?id=48126029)
  https://depthfirst.com/nginx-rift (https://news.ycombinator.com/item?id=48123365)