mail-mime-parser EUVD-2026-116903

Exploitation requires the consuming application to pass an attacker-influenced string into one of the message-building methods that build headers without stripping CR/LF: $mimeType or $encoding in IMessage::addAttachmentPart()/addAttachmentPartFromFile(), $charset in setTextPart()/setHtmlPart(), or $micalg/$protocol in setAsMultipartSigned() (affected versions >=3.0.0 up to and including 4.0.5; fixed in 3.0.9 and 4.0.6). The realistic exposure is the MIME type, e.g. a browser-supplied upload Content-Type forwarded as $mimeType. Key limiting factors per the vendor: parsing/processing hostile inbound email does NOT trigger this (header values read from parsed messages never reach this builder code); setRawHeader()/addRawHeader() are explicitly out of scope; and charset, encoding, micalg and protocol are normally chosen by the application, so reaching the flaw through them requires an unusual application design. No exploitation is possible on fixed versions, which replace control characters with a space.

This is a medium-severity CRLF header-injection flaw (CWE-93) in a PHP library, not a drop-everything emergency. The supplied CVSS 4.0 vector (6.9) encodes AV:N/AC:L/PR:N/UI:N with low integrity/confidentiality impact on both the vulnerable and a subsequent system, consistent with a forged header being delivered into outgoing mail. The vuln.today decision label is 'this_month' (not act_now/emergency), and there is no CISA KEV listing and no EPSS score in the input, so there is no signal of active or widespread exploitation - treat it as a routine-priority patch. A working PoC is published inside the GHSA advisory itself, so exploitability is demonstrated, but PoC availability is not the same as in-the-wild exploitation. The single most important caveat is that the PR:N in the vector overstates real-world exposure: the vendor states explicitly that exploitation requires the consuming application to pass attacker-influenced data into specific message-building methods, and that only the MIME type is a likely untrusted input (e.g. a browser-supplied upload Content-Type) - charset, encoding, micalg and protocol are normally application-chosen and 'require an unusual design' to be attacker-controlled. Parsing hostile email does NOT trigger this. So the realistic risk is confined to applications that build (not just parse) MIME messages using untrusted values.

A web application lets users upload a file and passes the browser-supplied Content-Type straight into IMessage::addAttachmentPart() as $mimeType. An attacker sets that upload Content-Type to a value containing CRLF followed by 'Bcc: attacker@evil.test', causing the generated Content-Type header to terminate early and a forged Bcc line to be serialized into the outgoing message, silently copying mail to the attacker. A functional PoC demonstrating exactly this (and the charset variant) is published in the vendor's GHSA advisory.