CVE-2026-59920 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 STOMP encoder ( StompSubframeEncoder ) does not escape or validate header values in CONNECT and CONNECTED frames, so raw newline ( \n ) characters in a header value are written directly to the wire, allowing an attacker who controls a header value to inject additional STOMP headers. This happens because the encoder intentionally skips escaping for CONNECT/CONNECTED frames per the STOMP 1.2 specification but never rejects the raw newlines, and since a broker parses each line as a separate header, an attacker controlling a value such as a user-supplied login or passcode can overwrite connection parameters or add authentication/role headers to bypass authentication or escalate privileges (the actual impact is broker-dependent). The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability in Netty's STOMP encoder represents a critical security flaw that exploits improper handling of header values in CONNECT and CONNECTED frames within the asynchronous network application framework. This issue affects versions prior to 4.1.136.Final and 4.2.16.Final, where the StompSubframeEncoder fails to properly escape or validate header values, creating an injection vector that allows attackers to manipulate STOMP protocol communication. The technical implementation flaw stems from the encoder's intentional bypass of escaping mechanisms for CONNECT/CONNECTED frames as specified in the STOMP 1.2 specification, yet it neglects to reject raw newline characters that could be exploited for malicious purposes.
The operational impact of this vulnerability extends beyond simple data corruption, as it enables attackers to inject additional STOMP headers through carefully crafted header values containing newline sequences. When a broker processes these malformed frames, each newline character causes the parser to treat subsequent content as separate headers, effectively allowing an attacker who controls a header value such as a login or passcode to overwrite connection parameters or inject authentication headers. This privilege escalation capability makes the vulnerability particularly dangerous in environments where STOMP brokers handle sensitive authentication flows and role-based access control mechanisms.
The security implications align with CWE-113, which addresses improper neutralization of input during web application processing, and can be mapped to ATT&CK technique T1566 for credential access through social engineering or exploitation of protocol implementations. The vulnerability creates a path for attackers to bypass authentication mechanisms by injecting forged headers that could establish unauthorized connections with elevated privileges or manipulate session parameters. The actual impact varies significantly based on the specific broker implementation and its configuration, but commonly results in unauthorized access, privilege escalation, or denial of service conditions.
Mitigation strategies should focus on upgrading to Netty versions 4.1.136.Final or 4.2.16.Final where the vulnerability has been addressed through proper validation and escaping of header values. Organizations should also implement network segmentation and monitoring to detect unusual STOMP frame patterns, while conducting security reviews of any custom STOMP implementations that might be vulnerable to similar injection attacks. Additional defensive measures include implementing strict input validation for all header values in STOMP communications and configuring brokers with appropriate access controls to limit the impact of potential exploitation.