# nginx: man-in-the-middle injection when proxying to TLS servers (CVE-2026-1642, DSA-6131-1) - **Published on:** 2026-02-12 - **Category:** Security - **Original page:** https://linuxgratis.com/en/articles/dsa-6131-nginx-mitm-proxy-tls-debian Debian releases DSA-6131-1 to fix CVE-2026-1642 in nginx, a race condition that lets an attacker inject plaintext data into responses from proxied upstream TLS servers. --- The Debian security team has shipped advisory **DSA-6131-1** to fix **CVE-2026-1642**, a vulnerability in **nginx** that hits deployments where the server acts as a reverse proxy to a **TLS upstream**, meaning nginx encrypts the connection to the backend. Under the right conditions, the flaw allows a **man-in-the-middle injection** attack. ## What the vulnerability is The root of it is a **race condition** in nginx's event loop when it sets up new encrypted connections to an upstream server. When nginx opens a TCP connection to the TLS backend, it checks for incoming data (a read event) **before** it sends the TLS handshake `Client Hello` (a write event). An attacker who holds a **man-in-the-middle position on the upstream side** can use that window. By sending a plaintext HTTP response right after the TCP connection is established, but before TLS negotiation kicks off, they get nginx to **accept that unencrypted data** as if it came from the trusted backend, skipping the TLS handshake entirely. The upshot is that the attacker can **inject plaintext data** into the response nginx returns to the client, mixing untrusted input with trusted data. It falls under **CWE-349 (Acceptance of Extraneous Untrusted Data With Trusted Data)**, and upstream documentation refers to it informally as "NGINX Rift". ## Who is affected Only configurations where nginx **proxies to an upstream over TLS** are affected (for example, using `proxy_pass https://...` or `proxy_ssl on`). If your install only serves static content or proxies in plaintext, this vector doesn't expose you. According to upstream, affected versions range from **nginx 1.3.0 through 1.28.2** and **1.29.x before 1.29.5**. ## Severity To pull this off, the attacker already needs a **privileged man-in-the-middle position** between nginx and the upstream server, plus timing conditions that fall outside their full control. That lowers the real-world likelihood on well-segmented networks. Even so, the consequences are serious: data injection can lead to **information disclosure** or, in specific scenarios, open the door to a larger compromise. Debian rates it **high** severity. ## Mitigation and patch The advice here is blunt: **update nginx now**. Debian has released fixed packages: - **bookworm (oldstable):** version `1.22.1-9+deb12u4` or later. - **trixie (stable):** version `1.26.3-3+deb13u2` or later. Run `apt update && apt upgrade` and restart the nginx service. As an extra line of defense, make sure the network between nginx and its backends is **properly segmented and encrypted end to end**, so an attacker can't easily get on the path. If you run nginx from the official upstream, update to **1.28.2 / 1.29.5** or later. To harden the host running nginx, review the system's mandatory access control policies; see [SELinux and AppArmor](/en/articles/selinux-y-apparmor). ## Source - Debian Security Advisory DSA-6131-1: - NVD CVE-2026-1642: