El 13 de mayo de 2026 F5 publicó los parches para CVE-2026-42945, un fallo en el módulo de reescritura de NGINX al que los investigadores han bautizado como NGINX Rift. Lo llamativo no es solo su gravedad (CVSS 4.0 de 9.2, crítica) sino que llevaba ahí desde 2008. El código vulnerable se introdujo en la versión 0.6.27 y ha pasado dieciocho años sin que nadie lo detectara.
Qué es exactamente
Es un desbordamiento de buffer en heap (CWE-122) dentro de ngx_http_rewrite_module, el componente que procesa las directivas rewrite, if y set en la configuración de NGINX. El motor de scripts de NGINX trabaja en dos pasadas: primero calcula la longitud de la cadena resultante y luego la copia. El problema está en que un indicador interno de estado (is_args), que se activa durante la fase de cálculo, se filtra a la fase de copia. Cuando una regla de rewrite combina una captura PCRE sin nombre con un signo de interrogación en la cadena de reemplazo, ngx_escape_uri acaba escribiendo más allá del buffer reservado.
El resultado es un desbordamiento determinista de 4.000 bytes. Las pruebas de concepto lo disparan enviando una petición con 349 bytes de relleno seguidos de 2.000 caracteres que NGINX intenta escapar en la URI.
A quién afecta
A casi todo el mundo que use NGINX con reglas de reescritura que encajen en ese patrón. La vulnerabilidad alcanza a NGINX Open Source desde la 0.6.27 hasta la 1.30.0 y a NGINX Plus de la R32 a la R36. También salpica a despliegues que dependen de NGINX por debajo, como Ingress NGINX en Kubernetes o builds de OpenResty.
Un atacante remoto sin autenticación puede provocar el reinicio repetido de los procesos worker enviando peticiones HTTP manipuladas, lo que ya constituye una denegación de servicio. En sistemas con ASLR desactivado, o cuando el atacante consigue sortear esa protección, el desbordamiento abre la puerta a ejecución remota de código.
Y no es teórico. VulnCheck detectó explotación activa en la red desde el 16 de mayo de 2026, pocos días después de que se publicara el parche.
Gravedad
Crítica. Hablamos de un servidor web que suele estar expuesto directamente a internet, una ruta de explotación que no requiere credenciales y código de prueba público. La combinación de antigüedad, alcance y exposición lo coloca entre los avisos más serios del mes.
Mitigación y parches
Lo primero es actualizar. El proyecto NGINX corrigió el fallo en 1.30.1 (rama estable) y 1.31.0 (mainline). Si usas paquetes de tu distribución, espera a la versión que la incorpore en lugar de compilar a mano.
En el caso de Red Hat Enterprise Linux 9, el aviso RHSA-2026:18029 (severidad crítica) entrega el paquete corregido nginx-1.20.1-24.el9_7.3, con el backport del parche sobre la rama 1.20.1 que mantiene Red Hat. Cubre RHEL 9 en todas sus arquitecturas (x86_64, aarch64, ppc64le, s390x) y las variantes de soporte extendido.
Si no puedes parchear de inmediato, revisa tu configuración y elimina temporalmente las directivas rewrite que usen capturas PCRE sin nombre junto a un signo de interrogación en el reemplazo. Reduce la superficie, aunque no sustituye a la actualización. Tras parchear, reinicia NGINX para que se carguen los binarios nuevos.
Si gestionas RHEL en producción puede interesarte repasar las novedades de Red Hat Enterprise Linux 10.2 para planificar futuras migraciones.
Fuente
- Red Hat Security Advisory: RHSA-2026:18029
- NVD: CVE-2026-42945