Parche de seguridad NGINX (Rift y CVEs de 2026)
En 2026 NGINX ha corregido varias tandas de fallos: NGINX Rift (CVE-2026-42945) en mayo, CVE-2026-42533, con una prueba de concepto pública, y cinco CVEs en octubre, entre ellos un request smuggling en HTTP/3 y una falsificación de sesión TLS que salta la verificación de certificado de cliente. Para tenerlas todas hace falta 1.31.7 o superior (mainline) o 1.30.6 o superior (estable).
¿Tienes esta vulnerabilidad? Actualizamos NGINX en tus servidores y contenedores, revisamos la configuración que hace explotables algunos de estos fallos y comprobamos que todo siga sirviendo igual.
$ nginx -vnginx version: nginx/1.30.2# Estable < 1.30.6: faltan las correcciones de octubre$ nginx -V 2>&1 | grep -o with-http_v3_modulewith-http_v3_module# HTTP/3 compilado: revisa CVE-2026-95101$ grep -rnE 'request_filename|alias ' /etc/nginx//etc/nginx/sites-enabled/app.conf:14: alias /var/www/static/;# alias en una ruta pública: patrón de CVE-2026-151761.31.7+ (mainline) · 1.30.6+ (stable)Tres tandas de fallos en NGINX en lo que va de 2026
Si actualizaste en mayo por Rift, te faltan las correcciones posteriores. Y si usas el NGINX de tu distribución, el número de versión puede ser antiguo aunque el paquete lleve los parches: manda el aviso de seguridad del proveedor.
NGINX Rift (CVE-2026-42945) lo encontró en mayo la plataforma de IA de DepthFirst en unas seis horas, y el fallo venía de la versión 0.6.27, de 2008. Afecta a NGINX Open Source de la 0.6.27 a la 1.30.0 y está corregido en 1.31.0 y 1.30.1. nginx.org lo califica de severidad media; Cloud Security Alliance y Help Net Security lo tratan como crítico (9.2). Según Help Net Security, VulnCheck vio intentos de explotación desde el 16 de mayo.
Después llegó CVE-2026-42533, corregido en 1.31.3 y 1.30.4, para el que DepthFirst publicó una prueba de concepto de cadena completa. En octubre, otra tanda de cinco: CVE-2026-15176, CVE-2026-93479, CVE-2026-95101 (request smuggling en HTTP/3), CVE-2026-97629 (falsificación de sesión TLS que salta la verificación de certificado de cliente) y CVE-2026-97205, todos corregidos en 1.31.7 y 1.30.6.
Fuentes: nginx.org security advisories · Cloud Security Alliance · Help Net Security
Versiones corregidas de NGINX
Compara tu versión con esta tabla. Vale para NGINX Open Source descargado de nginx.org o compilado por ti; con paquetes de distribución, consulta el aviso del proveedor para cada CVE.
| Si tienes | Actualiza a | Qué te falta |
|---|---|---|
| 1.31.3 – 1.31.6 | 1.31.7+ | La tanda de octubre |
| 1.31.0 – 1.31.2 | 1.31.7+ | CVE-2026-42533 y la tanda de octubre |
| 1.30.4 – 1.30.5 | 1.30.6+ | La tanda de octubre |
| 1.30.1 – 1.30.3 | 1.30.6+ | CVE-2026-42533 y la tanda de octubre |
| 0.6.27 – 1.30.0 | 1.30.6+ o 1.31.7+ | Rift y todo lo posterior |
Revisa esto
-
nginx -vda una versión anterior a 1.31.7 (mainline) o 1.30.6 (estable). - Tienes HTTP/3 activado: te afecta el request smuggling de CVE-2026-95101.
- Pides certificado de cliente (
ssl_verify_client): CVE-2026-97629 permite saltarse esa verificación. - Tu configuración usa
$request_filenameoalias(CVE-2026-15176), o expresiones regulares con capturas sin nombre (CVE-2026-93479). - NGINX corre dentro de imágenes Docker o como ingress de Kubernetes: cada imagen se actualiza por separado.
Cambios de configuración mientras actualizas
nginx.org propone ajustes de configuración para algunos fallos de octubre. Reducen la exposición a esos CVEs concretos; para Rift y el resto, la corrección es la actualización.
- 01 CVE-2026-15176: evita
$request_filenameyaliasen laslocationexpuestas. - 02 CVE-2026-93479: usa capturas con nombre, como
(?<ruta>.+), en lugar de capturas sin nombre ($1,$2). - 03 Revisa en cada
serversi de verdad usas HTTP/3 y certificados de cliente: son las funciones afectadas por CVE-2026-95101 y CVE-2026-97629. - 04 Antes de recargar,
nginx -t. Un error de sintaxis en producción tumba más servicios que el fallo que estás corrigiendo.
Siete pasos, en este orden
Aplicamos el mismo procedimiento en cada servidor: primero saber qué versión hay en cada sitio, después corregir y al final comprobar que nadie entró antes del parche.
Inventario de versiones
Listamos cada NGINX: servidores, balanceadores, contenedores e ingress, con su versión, los módulos compilados (nginx -V) y de dónde viene el paquete: nginx.org, distribución o imagen Docker.
Mitigación inmediata
Buscamos $request_filename, alias y capturas sin nombre en la configuración, y los cambiamos donde se puede sin alterar lo que sirve la web.
Actualización
Subimos a 1.31.7+ o 1.30.6+, o al paquete parcheado de tu distribución, y reconstruimos las imágenes que incluyen NGINX.
Verificación
Pasamos nginx -t, recargamos y comprobamos redirecciones, certificados, HTTP/2 y HTTP/3 y las rutas que sirven ficheros estáticos.
Revisión de indicios de compromiso
Revisamos los logs de acceso y de error en busca de peticiones anómalas, desde mayo si el servidor estaba en una versión afectada por Rift.
Rotación de secretos, si procede
Si hay señales de intrusión, renovamos certificados y claves privadas TLS y las credenciales que pasan por el proxy.
Vigilancia de nuevos avisos
Dejamos anotada la versión y el origen de cada NGINX, para que la siguiente tanda de avisos de nginx.org empiece desde ese inventario.
Lo que deja fuera un parche solo por Rift
¿Tienes varios NGINX y no sabes qué versión lleva cada uno?
Consultoría gratuita →Preguntas frecuentes sobre los CVEs de NGINX de 2026
¿Qué es NGINX Rift?
Ya actualicé por Rift, ¿estoy cubierto?
Mi distribución trae una versión más antigua, ¿estoy afectado?
¿Puedo protegerme cambiando solo la configuración?
Cuéntanos dónde corre tu NGINX
Empezamos por el inventario: versión, origen del paquete y módulos de cada NGINX, y qué configuración hay que tocar antes de actualizar.
Cuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.