Alerta de día cero en NGINX desbordamiento de heap en ngx_http_rewrite_module amenaza con DoS y posible RCE

Una vulnerabilidad de día cero recientemente divulgada en NGINX Plus y NGINX Open, identificada como CVE-2026-42945, está siendo explotada activamente en el entorno real apenas días después de su publicación, según informes de investigadores. Se trata de un desbordamiento de búfer en montón (heap buffer overflow) en el módulo ngx_http_rewrite_module, atribuible a código que, según análisis forenses, se introdujo hace años y afecta a una amplia gama de versiones históricas de NGINX. El riesgo se considera alto (CVSS ~9.x) porque un atacante no autenticado puede provocar la caída de procesos worker e, incluso en situaciones concretas, llegar a ejecución remota de código.

Es importante distinguir dos escenarios técnicos que definen la gravedad práctica: por un lado existe una condición de denegación de servicio (DoS) fiable al forzar el fallo de los workers; por otro, la ejecución remota de código (RCE) es teóricamente posible pero exige condiciones adicionales —en particular, que ASLR (Address Space Layout Randomization) esté desactivado— y que el atacante conozca o descubra una configuración concreta de NGINX que haga exploitable el módulo de reescrituras. En entornos modernos y bien configurados, ASLR suele estar activo por defecto, lo que complica convertir el overflow en un exploit estable, aunque no lo imposibilita.

Las consecuencias prácticas varían según el despliegue: para servidores web públicos la capacidad de provocar reinicios continuos de workers puede degradar servicios y abrir ventanas para ataques posteriores; para infraestructura gestionada con herramientas de automatización o contenedores, la combinación de este fallo con debilidades de configuración externa (por ejemplo, controles de acceso insuficientes) puede facilitar movimientos laterales y persistencia. Además, investigadores han observado que actores han comenzado a escanear y explotar instalaciones vulnerables, lo que convierte el hallazgo en una prioridad operativa para administradores.

Paralelamente, el mismo equipo de investigación detectó explotación contra openDCIM, una aplicación open source para gestión de infraestructuras de centro de datos, donde se identificaron varias fallas críticas que pueden encadenarse hasta obtener RCE en pocos pasos. Si su organización usa openDCIM, revise el código y despliegues inmediatamente; el proyecto está disponible en GitHub en https://github.com/samilliken/openDCIM, y conviene comparar la versión en uso con parches publicados por mantenedores o mitigaciones temporales.

Para priorizar la respuesta técnica, comience por aplicar parches oficiales en cuanto estén disponibles para su variante de NGINX. F5, que mantiene NGINX desde su adquisición, publica avisos y parches; también es aconsejable revisar la base de datos de vulnerabilidades pública en el NVD para referencias cruzadas y detalles del CVE en https://nvd.nist.gov/. Si no puede parchear de inmediato, implemente mitigaciones como restringir el acceso a las instancias afectadas desde Internet, aplicar reglas WAF para bloquear patrones de petición sospechosos al módulo de reescritura y aislar sistemas críticos.

Verifique y refuerce la protección de memoria del sistema: compruebe el estado de ASLR con el comando del kernel (por ejemplo, sysctl kernel.randomize_va_space) y, si por alguna razón está deshabilitado en sistemas de producción, habilítelo con sysctl -w kernel.randomize_va_space=2. Aunque activar ASLR no sustituye al parche, reduce significativamente la probabilidad de explotación exitosa que convierta el overflow en ejecución de código.

Audite configuraciones de NGINX buscando reglas complejas en ngx_http_rewrite_module y patrones poco habituales que puedan ser objetivo de peticiones manipuladas; el exploit requiere conocer o descubrir la configuración vulnerable, por lo que una revisión y simplificación de reglas de reescritura puede mitigar el riesgo. También monitorice logs de acceso y errores para detectar peticiones inusuales dirigidas a endpoints de reescritura y señales de tentativas de carga de shells web o comandos remotos.

En el caso de openDCIM y aplicaciones web similares, aplique el principio de menor privilegio: limite el acceso administrativo a redes de gestión, desactive variables de entorno como REMOTE_USER sin controles de autenticación en entornos Docker, y valide o sanee exhaustivamente parámetros que puedan ser pasados a sistemas o comandos, como el parámetro “dot” identificado en las investigaciones. La auditoría de integridad de ficheros y el control de salida saliente (e.g., conexiones reversas) ayudan a detectar web shells tempranamente.

Finalmente, tenga en cuenta que los atacantes están automatizando la detección de estas vulnerabilidades con herramientas que incorporan capacidades de inteligencia artificial, por lo que los intentos de explotación pueden escalar rápidamente. Mantenga un plan de respuesta que incluya parches, bloqueos de red temporales, análisis forense si detecta compromiso y comunicación a equipos de incident response. Para documentación técnica adicional sobre ASLR y mitigaciones de explotación de memoria consulte fuentes generales como la entrada de Wikipedia sobre Address Space Layout Randomization en https://en.wikipedia.org/wiki/Address_space_layout_randomization y la guía de seguridad de NGINX en https://nginx.org/.