CVE-2026-59919 in Netty
Summary
by MITRE • 07/29/2026
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.136.Final and 4.2.16.Final, Netty's HAProxy encoder ( HAProxyMessageEncoder ) writes AF_UNIX source and destination socket addresses into the HAProxy V1 text protocol without validating them for CRLF characters, so an attacker who controls an AF_UNIX address can inject \r\n sequences and split the single PROXY header into multiple lines. This is possible because the V1 protocol uses CRLF as its line terminator and, unlike IPv4/IPv6 addresses whose format checks implicitly reject CRLF, AF_UNIX addresses are only validated for length (up to 108 bytes), allowing a forged second PROXY header line that spoofs the client source/destination IP to a downstream server or load balancer. The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability in Netty's HAProxy encoder represents a critical security flaw that exploits the protocol's handling of AF_UNIX socket addresses within the HAProxy V1 text protocol. This issue affects versions prior to 4.1.136.Final and 4.2.16.Final, where the HAProxyMessageEncoder fails to properly validate source and destination socket addresses for CRLF characters. The flaw stems from the asymmetric validation approach applied to different address types within the same protocol framework, creating a vector for header injection attacks that can fundamentally alter how network traffic is interpreted by downstream systems.
The technical implementation of this vulnerability occurs because the HAProxy V1 protocol uses CRLF (carriage return and line feed) characters as its line terminator, while the validation process for AF_UNIX addresses only checks length constraints up to 108 bytes without filtering out control characters. Unlike IPv4 and IPv6 addresses which undergo implicit format validation that would naturally reject CRLF sequences, AF_UNIX addresses are processed with minimal validation, allowing attackers to craft malicious socket paths containing \r\n sequences. This discrepancy creates an opportunity for header splitting attacks where a single PROXY header can be manipulated into multiple lines, effectively injecting additional header information.
The operational impact of this vulnerability extends beyond simple header manipulation to potentially enable sophisticated attack vectors including IP address spoofing and load balancer deception. When downstream servers or load balancers process these malformed headers, they may interpret the injected second line as a legitimate PROXY header, causing them to trust forged source and destination IP addresses. This can lead to unauthorized access attempts, traffic redirection, and bypass of security controls that rely on accurate client identification. The vulnerability particularly affects environments where Netty is used as a proxy or load balancing component in network infrastructure, making it a significant concern for organizations relying on HAProxy protocol support.
From a cybersecurity perspective, this vulnerability aligns with CWE-134, which addresses the use of format strings without proper validation, and demonstrates characteristics consistent with attack patterns found in the ATT&CK framework under T1071.501 for application layer protocol manipulation. The flaw represents a classic case of insufficient input validation where the security boundary is violated through improper handling of special characters in address fields. Organizations should prioritize updating their Netty implementations to versions 4.1.136.Final or 4.2.16.Final, while also implementing network monitoring to detect unusual PROXY header patterns that might indicate exploitation attempts. Additional mitigations include deploying network segmentation controls and implementing proper input sanitization at multiple layers of the application stack to prevent similar vulnerabilities from manifesting in other components handling similar protocol parsing scenarios.