CVE-2026-59919

Netty's HAProxyMessageEncoder writes AF_UNIX source and destination socket addresses into the HAProxy V1 text protocol without validating them for carriage-return or line-feed characters, so a crafted AF_UNIX address can inject CRLF sequences and split the single PROXY header into multiple lines (CWE-93; CVSS 3.1: 5.5). An attacker who controls an AF_UNIX address presented to the encoder — a local, low-privilege attack vector per the CVSS scoring — can forge an additional PROXY header line that downstream servers or load balancers treat as authoritative. The attacker gains spoofing of the client source and destination IP addresses seen by downstream consumers (high integrity impact, with no confidentiality or availability loss). Users of Netty versions before 4.1.136.Final and 4.2.16.Final who employ the HAProxyMessageEncoder with AF_UNIX addresses are affected; because Netty is broadly embedded in Java server software, the version-affected footprint is large even though the specific encoder-plus-AF_UNIX code path is narrow. No in-the-wild exploitation is known (EPSS 0.1%, not in CISA KEV), but a public advisory with a PoC reference has been published as GHSA-wh89-7897-x99h.

What to do: Upgrade to Netty 4.1.136.Final or 4.2.16.Final, or later. Where an immediate upgrade is not possible, avoid emitting HAProxy PROXY V1 headers for AF_UNIX addresses, or strip CR/LF characters from AF_UNIX address strings before they reach the encoder. Audit downstream PROXY-protocol consumers to determine whether spoofed source/destination addresses could affect allowlists, rate limiting, or security-relevant logging.