← Volver a artículos
Seguridad· 3 min de lectura

nginx: inyección man-in-the-middle al hacer proxy a servidores TLS (CVE-2026-1642, DSA-6131-1)

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.

Fuente