Una vulnerabilidad de 18 años en el servidor web de código abierto NGINX ha sido descubierta mediante un sistema autónomo de escaneo. Esta falla puede provocar denegación de servicio y, bajo ciertas condiciones, ejecución remota de código (RCE). La vulnerabilidad está registrada como CVE-2026-42945 y ha recibido una calificación de gravedad crítica de 9.2 según la versión más reciente del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS).
Tres fallos adicionales de corrupción de memoria fueron descubiertos durante la misma sesión de análisis de seis horas por investigadores de DepthFirst AI, una empresa de seguridad nativa de IA. NGINX es un servidor web y proxy inverso masivamente utilizado, que impulsa un tercio de los sitios web más populares. Es mantenido por la empresa estadounidense F5 y utilizado por proveedores de nube, empresas SaaS, bancos, plataformas de medios y sitios de comercio electrónico, así como en clústeres de Kubernetes.
Detalles de la vulnerabilidad
CVE-2026-42945 es un desbordamiento de búfer en el montón (heap buffer overflow) en el módulo ngx_http_rewrite_module que afecta a las versiones de NGINX desde la 0.6.27 hasta la 1.30.0, y ha estado presente en el código del proyecto durante aproximadamente 18 años. Según DepthFirst, la vulnerabilidad se puede desencadenar cuando las configuraciones de NGINX utilizan tanto las directivas 'rewrite' como 'set', un patrón común en puertas de enlace API y configuraciones de proxy inverso.
El fallo se origina en un manejo inconsistente del estado en el motor de scripts interno de NGINX, que procesa las reescrituras en dos pasos: uno para calcular la cantidad de memoria a asignar y otro para copiar los datos reales. Un indicador 'is_args' permanece establecido después de una reescritura que contiene '?', lo que hace que NGINX calcule el tamaño del búfer utilizando longitudes de URI sin escapar, pero luego escriba datos escapados más grandes como '+' y '&', lo que provoca un desbordamiento del búfer del montón.
Los investigadores demostraron la ejecución remota de código no autenticada mediante solicitudes HTTP especialmente manipuladas que corrompen las estructuras adyacentes del grupo de memoria de NGINX, sobrescriben punteros de manejadores de limpieza, introducen estructuras falsas en la memoria a través de cuerpos de solicitud POST y fuerzan a NGINX a ejecutar 'system()' durante la limpieza del grupo.
Sin embargo, la ejecución remota de código se logró en un sistema con la protección de Aleatorización del Diseño del Espacio de Direcciones (ASLR) desactivada. Esta defensa está activa por defecto, pero puede desactivarse para aumentar el rendimiento en algunos entornos, como sistemas integrados y máquinas virtuales utilizadas para análisis. DepthFirst señala que la arquitectura multiproceso de NGINX facilita la explotación porque los procesos trabajadores heredan diseños de memoria casi idénticos del proceso maestro, lo que permite una manipulación fiable del montón y reintentos repetidos si un trabajador falla.
Si nuestro exploit falla y bloquea un trabajador, el proceso maestro simplemente genera uno nuevo con el mismo diseño de memoria. Esto nos permite intentar varias veces de manera segura hasta que tengamos éxito, sin preocuparnos de que el trabajador se bloquee y cambie el diseño de memoria.
Los investigadores añadieron: "Teóricamente, podríamos aprovechar este diseño para filtrar ASLR sobrescribiendo progresivamente punteros byte a byte".
Otras vulnerabilidades descubiertas
- CVE-2026-42946 — asignación excesiva de memoria en módulos SCGI/UWSGI que puede bloquear trabajadores mediante asignaciones de ~1 TB (gravedad alta).
- CVE-2026-40701 — use-after-free en la resolución asíncrona de DNS OCSP (gravedad media).
- CVE-2026-42934 — error de análisis UTF-8 por uno que causa lecturas fuera de los límites (gravedad media).
Impacto y parches
Las vulnerabilidades fueron descubiertas el 18 de abril de 2026 y reportadas al proveedor el 21 de abril. Según el aviso de seguridad de F5, los fallos afectan a las siguientes compilaciones de NGINX: NGINX Open Source versiones 0.6.27 a 1.30.0; NGINX Plus R32 a R36; NGINX Instance Manager 2.16.0 a 2.21.1; F5 WAF para NGINX 5.9.0 a 5.12.1; NGINX App Protect WAF 4.9.0 a 4.16.0 y 5.1.0 a 5.8.0; F5 DoS para NGINX 4.8.0; NGINX App Protect DoS 4.3.0 a 4.7.0; NGINX Gateway Fabric 1.3.0 a 1.6.2 y 2.0.0 a 2.5.1; y NGINX Ingress Controller 3.5.0 a 3.7.2, 4.0.0 a 4.0.1 y 5.0.0 a 5.4.1.
Las correcciones están disponibles en NGINX Open Source 1.31.0 y 1.30.1, NGINX Plus R36 P4 y NGINX Plus R32 P6. Para aquellos que no puedan actualizar, F5 recomienda reemplazar los grupos de captura no nombrados ($1, $2, etc.) en las reglas 'rewrite' vulnerables por capturas con nombre, lo que elimina el principal requisito previo para la explotación.
Explotabilidad en el mundo real
Algunos investigadores de seguridad han cuestionado las afirmaciones de explotabilidad en el mundo real de CVE-2026-42945, argumentando que la prueba de concepto de DepthFirst se basa en condiciones altamente específicas que no están presentes en las implementaciones predeterminadas. El investigador Kevin Beaumont señaló que la explotación requiere una configuración vulnerable de NGINX que use patrones de reescritura particulares, el atacante debe conocer o descubrir el endpoint afectado, y el PoC de RCE publicado fue probado con ASLR desactivado.
Beaumont enfatizó que el exploit de los investigadores fue construido contra una configuración deliberadamente vulnerable y no demuestra una ejecución de código confiable contra sistemas del mundo real endurecidos. AlmaLinux se hizo eco de una evaluación similar en su aviso, tras reproducir la falla de forma independiente.
Los mantenedores de la distribución Linux confirmaron que bloquear los procesos trabajadores de NGINX a través de una solicitud manipulada es trivial y confiable, lo que hace que los ataques de denegación de servicio sean realistas. Sin embargo, afirmaron que convertir el desbordamiento del montón en una ejecución remota de código fiable en sistemas con ASLR habilitado "no es trivial" y no esperan que surja un exploit genérico y confiable del trabajo de DepthFirst. Al mismo tiempo, AlmaLinux advirtió que "no fácil" no significa imposible, y el potencial de DoS por sí solo es suficiente para tratar el problema como urgente.
