# nginx: inyección man-in-the-middle al hacer proxy a servidores TLS (CVE-2026-1642, DSA-6131-1) - **Publicado el:** 2026-02-12 - **Categoría:** Seguridad - **Página original:** https://linuxgratis.com/articulos/dsa-6131-nginx-mitm-proxy-tls-debian Debian publica DSA-6131-1 para corregir CVE-2026-1642 en nginx, una condición de carrera que permite inyectar datos en texto claro en respuestas de servidores TLS upstream proxificados. --- El equipo de seguridad de Debian ha sacado el aviso **DSA-6131-1** para corregir **CVE-2026-1642**, un fallo en **nginx** que afecta a quien usa el servidor como proxy inverso hacia un servidor **TLS upstream**, es decir, cuando nginx cifra la conexión hacia el backend. Bajo ciertas condiciones, el bug abre la puerta a un ataque de **inyección man-in-the-middle**. ## Qué es la vulnerabilidad El origen está en una **condición de carrera** dentro del bucle de eventos de nginx cuando levanta nuevas conexiones cifradas con un servidor upstream. Al abrir la conexión TCP hacia el backend TLS, nginx comprueba si hay datos entrantes (evento de lectura) **antes** de mandar el `Client Hello` del handshake TLS (evento de escritura). Un atacante con posición de **man-in-the-middle en el lado del upstream** tiene ahí su ventana. Si envía una respuesta HTTP en texto claro justo después de establecer la conexión TCP, pero antes de que arranque la negociación TLS, logra que nginx **acepte esos datos sin cifrar** como si vinieran del backend de confianza, y se salta el handshake TLS por completo. ¿La consecuencia? El atacante puede **inyectar datos en texto plano** en la respuesta que nginx devuelve al cliente, mezclando información que no es de fiar con datos de un origen que sí lo es. La clasificación es **CWE-349 (Acceptance of Extraneous Untrusted Data With Trusted Data)**, y la documentación de upstream la llama de forma informal "NGINX Rift". ## A quién afecta Esto solo toca a las configuraciones en que nginx hace **proxy hacia un upstream por TLS** (por ejemplo, con `proxy_pass https://...` o `proxy_ssl on`). Si tu instalación solo sirve contenido estático o hace proxy en texto plano, este vector no te expone. Según upstream, las versiones afectadas van desde **nginx 1.3.0 hasta 1.28.2** y las **1.29.x anteriores a 1.29.5**. ## Gravedad Para explotarlo, el atacante necesita ya una **posición privilegiada de man-in-the-middle** entre nginx y el upstream, más unas condiciones de temporización que no controla del todo. Eso baja bastante la probabilidad real en redes bien segmentadas. Aun así, las consecuencias no son menores: la inyección de datos puede acabar en **divulgación de información** o, en algún escenario concreto, dar pie a un compromiso mayor. Debian le pone gravedad **alta**. ## Mitigación y parche Aquí la recomendación es directa: **actualiza nginx ya**. Debian tiene listos los paquetes corregidos: - **bookworm (oldstable):** versión `1.22.1-9+deb12u4` o posterior. - **trixie (stable):** versión `1.26.3-3+deb13u2` o posterior. Lanza `apt update && apt upgrade` y reinicia el servicio nginx. Y de paso, como defensa extra, vale la pena que la red entre nginx y los backends esté **bien segmentada y cifrada de extremo a extremo**, para que a un atacante no le resulte fácil colarse en el camino. Si usas nginx desde el upstream oficial, actualiza a **1.28.2 / 1.29.5** o posterior. Para endurecer el host donde corre nginx, échale un ojo a las políticas de control de acceso obligatorio del sistema; mira [SELinux y AppArmor](/articulos/selinux-y-apparmor). ## Fuente - Debian Security Advisory DSA-6131-1: - NVD CVE-2026-1642: