CVE-2026-59920

This CVE reveals a header injection vulnerability in Netty's STOMP encoder that stems from a dangerous assumption: the encoder treated 'spec says do not escape' as permission to skip validation entirely. The STOMP 1.2 specification explicitly instructs implementers not to escape control characters in CONNECT and CONNECTED frames — but that instruction defines wire syntax, not security policy. Netty's encoder took this as a passthrough contract: if a value reached the encoder, it went straight to the wire unchanged. The broker on the other end was expected to parse each line as a separate header. Neither layer validated whether the input contained newlines that could split a single header into multiple headers. The practical impact is authentication bypass or privilege escalation in any STOMP broker that naively parses CONNECT frame headers — which is the standard parsing model. An attacker can inject arbitrary headers (including authentication headers) by embedding raw newlines in header values. The vulnerability is broker-dependent: some brokers may reject malformed frames, others may process the injected headers as legitimate. That variance doesn't reduce the risk — it increases it, because you're relying on downstream validation you don't control. The fix is straightforward: reject newlines (and preferably all control characters) in STOMP header values at the encoder boundary. But this fix is localized — it doesn't address the architectural issue. Netty's encoding pipeline still treats itself as a transformer rather than a security boundary. That pattern (spec-compliant passthrough with no input validation) has generated this exact vulnerability class repeatedly across decades: HTTP response splitting, email header injection, log forging. The genetic sequence hasn't changed; only the protocol syntax has. Audit your deployment: confirm which STOMP broker you're using and whether it performs its own header validation. If you're using Netty's STOMP encoder directly, verify you're on a patched version. More broadly, treat any encoder that describes itself as 'spec-compliant passthrough' as a potential injection surface — the specification defines what bytes to send, not whether those bytes should be accepted as input in the first place.

Reviewed through automated stages and approved by a human before publication.