CVE-2026-59919: 
Java 취약성 분석 및 완화

CVE-2026-59919 is a CRLF injection vulnerability in Netty's HAProxy codec component (io.netty:netty-codec-haproxy) that allows injection of a second HAProxy PROXY protocol header via maliciously crafted AF_UNIX socket addresses, enabling client IP spoofing. It affects all versions of netty-codec-haproxy in the 4.2.x line prior to 4.2.16.Final and all versions in the 4.1.x line prior to 4.1.136.Final. The vulnerability was published on July 20, 2026, and the GitHub Advisory Database entry was updated on July 22, 2026. The CVSS v3.1 score assigned by GitHub is 5.5 (Moderate) (local attack vector, low privileges required), though the advisory's own summary cites a score of 7.5 (High) under a network-based vector (GitHub Advisory, Netty Security Advisory).

The root cause is CWE-93 (Improper Neutralization of CRLF Sequences): the HAProxyMessageEncoder.encodeV1() method writes sourceAddress and destinationAddress fields directly into the HAProxy V1 text protocol output without any CRLF validation. While IPv4 and IPv6 addresses are implicitly protected by format-checking routines (NetUtil.isValidIpV4Address, NetUtil.isValidIpV6Address), the checkAddress() method in HAProxyMessage only validates that AF_UNIX addresses are ≤108 bytes in length — permitting arbitrary characters including \r and \n. Because the V1 protocol uses \r\n as its line terminator, embedding a CRLF sequence in an AF_UNIX address splits the single PROXY header line into multiple lines, injecting a second, attacker-controlled PROXY header. Exploitation requires that the application uses HAProxyMessageEncoder to construct V1 headers with AF_UNIX addresses derived from user-controlled input, and that the resulting encoded stream is forwarded to a downstream server or load balancer (GitHub Advisory, Netty Security Advisory).

Successful exploitation allows an attacker to inject a forged PROXY protocol header, causing the downstream backend to attribute the connection to an arbitrary client IP address (client IP spoofing). Depending on the backend's PROXY protocol implementation, it may process the injected second header instead of the legitimate first one, completely misidentifying the originating client. This undermines IP-based access controls, rate limiting, audit logging, and fraud detection systems that rely on the client IP reported via the PROXY protocol. There is no direct confidentiality or availability impact, but the integrity impact is high due to the ability to falsify connection metadata (GitHub Advisory).

1. Identify a vulnerable target: Locate an application using io.netty:netty-codec-haproxy version ≤4.2.15.Final or ≤4.1.135.Final that constructs HAProxy V1 PROXY headers with AF_UNIX addresses derived from user-controlled input and forwards them to a backend server.
2. Craft a malicious AF_UNIX address: Construct a source address string containing an embedded CRLF sequence followed by a forged PROXY header line, e.g., "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80".
3. Inject the address into a HAProxyMessage: Supply the malicious string as the sourceAddress parameter when constructing a HAProxyMessage with HAProxyProtocolVersion.V1 and HAProxyProxiedProtocol.UNIX_STREAM. The checkAddress() method will accept it since only length is validated for AF_UNIX.
4. Encode and transmit: Pass the message through HAProxyMessageEncoder. The encodeV1() method writes the address verbatim, producing two PROXY lines on the wire: the legitimate (truncated) first line and the injected second line with the attacker-chosen IP.
5. Achieve IP spoofing on the backend: The downstream server receives both PROXY lines. Implementations that process the second line will attribute the connection to the attacker-specified IP (e.g., 10.0.0.1), bypassing IP-based access controls or audit logging (GitHub Advisory, Netty Security Advisory).

• Network: Downstream backend servers receiving HAProxy PROXY protocol streams containing two consecutive PROXY header lines (i.e., a second PROXY line appearing before the actual payload); unexpected PROXY TCP4 or PROXY TCP6 lines following a PROXY UNIX_STREAM or PROXY UNIX_DGRAM line in the same connection.
• Logs: Backend access logs recording client IPs that do not correspond to any known upstream Netty proxy node; mismatches between the IP reported in PROXY headers and the actual TCP connection source IP at the load balancer or backend.
• Application: HAProxy or backend application logs showing connections attributed to internal or unexpected IP addresses (e.g., RFC 1918 addresses) when the actual upstream is a UNIX socket relay; IllegalArgumentException or HAProxyProtocolException stack traces in Netty application logs after patching (indicating attempted injection that is now rejected).

Upgrade io.netty:netty-codec-haproxy to 4.2.16.Final (for the 4.2.x line) or 4.1.136.Final (for the 4.1.x line), both of which include the fix (Netty 4.2.16.Final Release, Netty 4.1.136.Final Release). As a workaround prior to patching, applications should sanitize AF_UNIX address strings before passing them to HAProxyMessage, explicitly rejecting any input containing \r or \n characters. Additionally, restrict the sources of AF_UNIX address values to trusted, non-user-controlled configuration to eliminate the attack surface (GitHub Advisory).