NGINX Rift: La vulnerabilidad de 18 años que convierte el servidor web más usado del mundo en puerta de entrada para atacantes
NGINX Rift: La vulnerabilidad de 18 años que convierte el servidor web más usado del mundo en puerta de entrada para atacantes
*Una falla introducida en el código de NGINX alrededor del año 2008 pasó desapercibida durante casi dos décadas hasta que el 13 de mayo de 2026 el equipo de investigación depthfirst la expuso. Bautizada como NGINX Rift y registrada como CVE-2026-42945, la vulnerabilidad afecta a un servidor web presente en aproximadamente un tercio de todos los sitios web existentes en el mundo, no requiere autenticación ni acceso previo, y puede derivar en ejecución remota de código con una sola solicitud HTTP.
El 13 de mayo de 2026 el equipo de investigación depthfirst publicó los detalles de una vulnerabilidad que convierte al servidor en el punto de entrada, esto debido a que un atacante que puede alcanzar un servidor NGINX vulnerable a través de HTTP puede enviar una única solicitud que desborda el montón de memoria del proceso de trabajo y logra ejecución remota de código, sin ningún tipo de autenticación, sin requisito de acceso previo y sin necesidad de una sesión existente. Al tener todas estas vulnerabilidades hace que el registro CVE-2026-42945 cuente con una puntuación CVSS v4 de 9.2. Esta falla afecta al módulo ngx_http_rewrite_module de NGINX y según investigadores esta lleva latente desde aproximadamente el año 2008.
El hallazgo fue divulgado inicialmente a F5, empresa propietaria de NGINX, el 21 de abril de 2026. Menos de un mes después, el 14 de mayo, F5 publicó los parches correctivos junto a un advisory oficial. Sin embargo junto a la divulgación, depthfirst publicó una prueba de concepto funcional que demuestra ejecución remota de código con ASLR desactivado. Esto significa que la barrera técnica para explotar la vulnerabilidad cayó el mismo día en que se anunció.
¿Qué es NGINX y por qué importa esta vulnerabilidad?
NGINX es un servidor web de código abierto que también actúa como proxy inverso, balanceador de carga y caché HTTP. Según el análisis de Picus Security, NGINX impulsa cerca de un tercio de todos los sitios web globalmente y es desplegado por proveedores de nube hiperscala, redes de distribución de contenido, plataformas de comercio electrónico, bancos, agencias de gobierno e innumerables pequeñas empresas.
Lo que hace a una vulnerabilidad en NGINX tan diferente de una falla en una aplicación cualquiera es su posición en la arquitectura: NGINX es típicamente el primer componente de software en procesar cualquier solicitud HTTP entrante. Los atacantes no necesitan superar defensas adicionales para alcanzarlo; el propio servidor web se convierte en la puerta de acceso. Como señala Picus Security, una sola falla en esta capa del stack puede exponer incontables sistemas de backend que se encuentran protegidos detrás de él.
El problema técnico: cuando dos pasadas de memoria no cuentan lo mismo
La vulnerabilidad reside en el módulo ngx_http_rewrite_module, el componente encargado de transformar y redirigir las URLs que los usuarios solicitan al servidor. Este módulo es ampliamente utilizado en entornos de producción reales para enrutar tráfico, gestionar aplicaciones y administrar proxies.
El fallo técnico, en esencia, es un desbordamiento de buffer en el montón de memoria (heap buffer overflow). A nivel de implementación, el problema emerge de una discrepancia entre dos pasadas que NGINX ejecuta al procesar reglas de reescritura: la primera calcula cuánto espacio de memoria se necesita para almacenar el resultado; la segunda escribe el resultado real. Bajo condiciones específicas de configuración, estas dos pasadas manejan ciertos caracteres de manera distinta, de forma que la primera subestima el tamaño necesario y la segunda escribe más datos de los que caben en el espacio reservado, corrompiendo memoria adyacente del proceso de trabajo.
La condición de activación requiere una combinación precisa de elementos en la configuración de NGINX: una directiva rewrite que use capturas sin nombre en expresiones regulares con una cadena de reemplazo que contenga un signo de interrogación (?), seguida de otra directiva rewrite, if o set. Este patrón no es exótico ni inusual; como advierte SOCRadar, es común en entornos que usan NGINX para enrutar aplicaciones, gestionar autenticación o administrar rutas multi-tenant, lo que amplía considerablemente la superficie de exposición real.
La cadena de explotación: seis pasos desde una URL hasta la ejecución de código
Lo que convierte a NGINX Rift en una vulnerabilidad técnicamente sofisticada no es solo el desbordamiento en sí, sino la cadena de pasos que los investigadores de depthfirst documentaron para transformar esa corrupción de memoria en ejecución de código arbitrario.
El atacante comienza enviando una solicitud HTTP cuya URI coincide con un location block vulnerable. Los signos más (+) y otros caracteres escapables en la URL son expandidos durante la fase de escritura mientras que la fase de cálculo los contabilizó sin expansión, creando el desbordamiento. El atacante puede entonces orientar la corrupción hacia el campo cleanup de una estructura ngx_pool_t adyacente en el montón: este campo apunta a una lista encadenada de entradas que contienen punteros de función que NGINX ejecuta automáticamente al destruir el pool de memoria de una solicitud. Controlando ese puntero, el atacante controla qué función se ejecuta y con qué argumento.
Para superar el obstáculo de que el desbordamiento es secuencial los investigadores documentaron una técnica de sincronización de conexiones entre dos solicitudes: una primera conexión provoca el desbordamiento que corrompe el pool de una segunda conexión víctima, y el atacante cierra inmediatamente esa segunda conexión para forzar la destrucción del pool antes de que cualquier otro código acceda a los metadatos corrompidos. El resultado final es la ejecución de la función system() de libc con un comando arbitrario del atacante.
Este nivel de control sobre la explotación, junto a la arquitectura de múltiples procesos de NGINX donde cada worker hereda el mismo layout de memoria del proceso maestro, es precisamente lo que justifica la puntuación crítica de 9.2 y la alarma de la comunidad de seguridad.
Impacto real: denegación de servicio versus ejecución de código remoto
El escenario más frecuente en entornos con protecciones estándar es la denegación de servicio. En este caso partícular el proceso de trabajo de NGINX colapsa y el servidor lo reinicia automáticamente. Si el atacante repite el ataque de forma continua, puede mantener los procesos en un bucle de fallas que afecta la disponibilidad de todos los sitios servidos por esa instancia. Los bytes escritos más allá de la asignación provienen de la URI del atacante, por lo que la corrupción está orientada por el atacante y no es aleatoria; incluso sin lograr ejecución de código, puede usarse para degradar la disponibilidad de forma deliberada.
La variante más grave, la ejecución remota de código (RCE), es posible cuando el sistema tiene desactivado ASLR (Address Space Layout Randomization), el mecanismo de protección que aleatoriza las direcciones de memoria en tiempo de ejecución. SOCRadar enfatiza una distinción importante para el proceso de clasificación de riesgo, tomando en cuenta que en entornos con mitigaciones modernas activas el impacto tiende hacia la denegación de servicio; en entornos sin esas mitigaciones, que incluyen algunos sistemas embebidos, instancias legacy o configuraciones especializadas, el riesgo de RCE se vuelve concreto. Esta distinción es relevante para priorizar la respuesta, ya que no todos los sistemas expuestos tienen el mismo perfil de riesgo.
Productos afectados: más allá del NGINX que todos conocen
La vulnerabilidad no se limita a las instalaciones básicas de NGINX. F5 documentó en su advisory oficial un listado extenso de productos afectados que incluye NGINX Plus (versiones R32 a R36), NGINX Open Source (versiones 1.0.0 a 1.30.0, con versiones más antiguas como 0.6.27 a 0.9.7 para las que no se planea parche), NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX App Protect DoS, NGINX Gateway Fabric y el NGINX Ingress Controller. Las versiones corregidas para las ramas principales son NGINX Open Source 1.30.1 y 1.31.0, y NGINX Plus R32 P6 y R36 P4.
Junto a CVE-2026-42945, la misma ronda de parches corrigió tres vulnerabilidades adicionales: CVE-2026-42946 (CVSS 8.3), una asignación excesiva de memoria en los módulos SCGI y uWSGI que puede permitir a un atacante con capacidades de intermediario leer memoria del proceso de trabajo; CVE-2026-40701 (CVSS 6.3), una vulnerabilidad use-after-free en el módulo SSL que puede causar modificación limitada de datos o reinicio del proceso; y CVE-2026-42934 (CVSS 6.3), una lectura fuera de límites en el módulo de conjuntos de caracteres que puede divulgar contenido de memoria. La acumulación de cuatro fallas en una sola auditoría sugiere que la revisión profunda del código de NGINX estaba significativamente rezagada.
Perspectiva defensiva: qué deben hacer los equipos de seguridad
El primer paso es identificar el inventario de instancias NGINX en producción y determinar cuáles utilizan directivas rewrite con el patrón de activación documentado, el cual contiene capturas sin nombre combinadas con signos de interrogación en la cadena de reemplazo, seguidas de directivas rewrite, if o set. No toda instalación de NGINX está expuesta de la misma manera, y esta distinción define la urgencia real del parche en cada sistema.
Para quienes no puedan aplicar la actualización de forma inmediata, F5 documentó una mitigación temporal, la cual consiste en reemplazar las capturas sin nombre ($1, $2) por capturas con nombre en todas las directivas rewrite afectadas de la configuración. Esta modificación no elimina la vulnerabilidad del binario, pero desactiva el camino de activación conocido mientras se completa el ciclo de actualización formal. Es una solución de emergencia, no un sustituto del parche.
A nivel de monitoreo, SOCRadar recomienda vigilar aumentos inusuales en reinicios de procesos de trabajo de NGINX, especialmente tras picos de tráfico con URIs anómalas o con densidades elevadas de caracteres especiales como signos más, ampersands o secuencias de escape. Un worker que colapsa repetidamente ante un patrón de tráfico específico es una señal de explotación activa incluso antes de que se registre una intrusión exitosa.
En sistemas Linux, confirmar que ASLR está completamente habilitado es un paso obligatorio en el proceso de clasificación:
cat /proc/sys/kernel/randomize_va_space
Un valor de 2 indica que la protección está activa. Cualquier valor inferior, especialmente en servidores de larga data que no han sido revisados recientemente, debe tratarse como urgente.
Análisis: lo que esta falla revela sobre la deuda técnica en infraestructura crítica
El caso de NGINX Rift no es simplemente la historia de una vulnerabilidad más. Es un indicador sobre cómo el ecosistema de software de infraestructura puede sconder fallos delicados y pasar desapercibidos durante años, sin tener actualizaciones técnicas debido a una idea falsa confianza.
El problema de la antigüedad como garantía de seguridad. NGINX lleva más de dos décadas de despliegue masivo y ha sido auditado por miles de ingenieros a lo largo de ese tiempo. Sin embargo, la falla que se acaba de revelar tenía 18 años. El mecanismo de activación es suficientemente específico debido a que requiere una combinación precisa de configuración, razón por la cual no activa alarmas en el uso cotidiano, pero suficientemente explotable como para representar un riesgo crítico cuando se conoce el vector. La longevidad de un proyecto de código abierto no es garantía de cobertura exhaustiva de seguridad; es simplemente tiempo acumulado en el que la falla pudo haber sido encontrada por actores con menos disposición a la divulgación responsable.
La ventana entre divulgación y explotación masiva se ha cerrado. Años atrás, la publicación de una vulnerabilidad crítica daba a los equipos defensivos semanas o incluso meses antes de que actores maliciosos desarrollaran herramientas de explotación funcionales. Hoy, depthfirst publicó la prueba de concepto el mismo día de la divulgación. La ventana entre el conocimiento público de una falla y la aparición de intentos de explotación activa en el ecosistema de amenazas se ha reducido a horas o días. Esto no es un caso aislado; es el patrón que define la operación de los equipos de seguridad en 2026.
El peso de NGINX como target de alto valor. Los grupos de ransomware y los actores de amenaza persistente avanzada llevan años apuntando a las capas de infraestructura que son comunes a múltiples organizaciones simultáneamente: VPNs, firewalls, servidores web. Una vulnerabilidad que funciona contra cualquier instalación de NGINX con el patrón de configuración correcto no es un ataque a una organización específica; es un arma que escala horizontalmente. El valor para un actor criminal no está en comprometer un solo servidor, sino en identificar mediante escaneos masivos cuántos de los millones de servidores NGINX en producción tienen el patrón vulnerable activo.
La pregunta que este caso deja sobre la mesa no es si NGINX Rift será explotada activamente en los próximos días. La pregunta es cuántas organizaciones habrán completado el ciclo de parche antes de que eso ocurra.
Bibliografía
F5. (2026, 14 de mayo). K000161019: NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945. F5 Support. https://my.f5.com/manage/s/article/K000161019
Lin, Z. (2026, 13 de mayo). NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability. depthfirst. https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability
SOCRadar. (2026, 14 de mayo). CVE-2026-42945: NGINX Rewrite Heap Overflow Enables Remote DoS & Potential RCE. SOCRadar Cyber Intelligence Inc. https://socradar.io/blog/cve-2026-42945-nginx-rewrite-heap-overflow-dos-rce/
Yuceel, H. C. (2026, 14 de mayo). NGINX Rift: CVE-2026-42945 Critical Heap Buffer Overflow Vulnerability Explained. Picus Security. https://www.picussecurity.com/resource/blog/nginx-rift-cve-2026-42945-critical-heap-buffer-overflow-vulnerability-explained