Mail Mime Parser
Monthly
Denial of service in zbateson/mail-mime-parser 2.0.0 through 3.0.5 and 4.0.0/4.0.1 allows unauthenticated remote attackers to exhaust CPU and memory by supplying a crafted email to any application that parses untrusted messages with this PHP library, since the single prerequisite is that the message is actually parsed (the cost is paid lazily on the first getAllParts() call or content read). Three independent parsing paths are super-linear in cost, so a crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory, potentially triggering an out-of-memory kill; because the parsing cost grows super-linearly, a caller-side input byte-size cap does not bound the work performed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the availability-only impact, low attack complexity and unauthenticated remote vector make it a genuine though moderate-priority denial-of-service risk; fixes that add configurable limits are available in 3.0.6 and 4.0.2, while the end-of-life 2.x line will not receive patches.
CRLF header injection in zbateson/mail-mime-parser before 3.0.6 and 4.0.2 allows an attacker-influenced attachment filename - including one harvested directly from parsed inbound mail - to be interpolated unescaped into Content-Type and Content-Disposition, so a filename containing \r\n serializes into one or more additional attacker-controlled header lines, for example a forged Bcc: that silently exfiltrates a copy of the outgoing message. Exploitation is limited to PHP applications that use the library to build or forward MIME messages with untrusted filenames (reusing getFilename() output or passing an attacker-supplied name into the attachment APIs); parse-only applications that never re-serialize the filename are not exposed. Per the CVSS vector the issue is network-reachable and requires no authentication or user interaction, no public exploit code was identified at time of analysis, and the vendor has shipped fixes in 3.0.6 and 4.0.2 while the 1.x and 2.x lines are end-of-life and will not be patched.
CRLF header injection in the PHP library zbateson/mail-mime-parser (3.0.0 through 4.0.5) lets an attacker who controls a value handed to the message-building helpers inject forged header lines, such as a Bcc, into MIME messages the application generates. The flaw is reachable only when the consuming application forwards attacker-influenced input into addAttachmentPart()/addAttachmentPartFromFile() ($mimeType, $encoding), setTextPart()/setHtmlPart() ($charset) or setAsMultipartSigned() ($micalg, $protocol) - most plausibly an upload's browser-supplied Content-Type; parsing hostile inbound email does not trigger it, and the vendor notes the charset, encoding, micalg and protocol arguments are normally application-chosen, so reaching the bug through them requires unusual design. All requests are unauthenticated per the assessed vector, and fixes are released in 3.0.9 and 4.0.6; the advisory includes a public PoC reference that is not verified as working exploit code, and there is no evidence of active exploitation (not in CISA KEV).
Denial of service in zbateson/mail-mime-parser 2.0.0 through 3.0.5 and 4.0.0/4.0.1 allows unauthenticated remote attackers to exhaust CPU and memory by supplying a crafted email to any application that parses untrusted messages with this PHP library, since the single prerequisite is that the message is actually parsed (the cost is paid lazily on the first getAllParts() call or content read). Three independent parsing paths are super-linear in cost, so a crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory, potentially triggering an out-of-memory kill; because the parsing cost grows super-linearly, a caller-side input byte-size cap does not bound the work performed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), but the availability-only impact, low attack complexity and unauthenticated remote vector make it a genuine though moderate-priority denial-of-service risk; fixes that add configurable limits are available in 3.0.6 and 4.0.2, while the end-of-life 2.x line will not receive patches.
CRLF header injection in zbateson/mail-mime-parser before 3.0.6 and 4.0.2 allows an attacker-influenced attachment filename - including one harvested directly from parsed inbound mail - to be interpolated unescaped into Content-Type and Content-Disposition, so a filename containing \r\n serializes into one or more additional attacker-controlled header lines, for example a forged Bcc: that silently exfiltrates a copy of the outgoing message. Exploitation is limited to PHP applications that use the library to build or forward MIME messages with untrusted filenames (reusing getFilename() output or passing an attacker-supplied name into the attachment APIs); parse-only applications that never re-serialize the filename are not exposed. Per the CVSS vector the issue is network-reachable and requires no authentication or user interaction, no public exploit code was identified at time of analysis, and the vendor has shipped fixes in 3.0.6 and 4.0.2 while the 1.x and 2.x lines are end-of-life and will not be patched.
CRLF header injection in the PHP library zbateson/mail-mime-parser (3.0.0 through 4.0.5) lets an attacker who controls a value handed to the message-building helpers inject forged header lines, such as a Bcc, into MIME messages the application generates. The flaw is reachable only when the consuming application forwards attacker-influenced input into addAttachmentPart()/addAttachmentPartFromFile() ($mimeType, $encoding), setTextPart()/setHtmlPart() ($charset) or setAsMultipartSigned() ($micalg, $protocol) - most plausibly an upload's browser-supplied Content-Type; parsing hostile inbound email does not trigger it, and the vendor notes the charset, encoding, micalg and protocol arguments are normally application-chosen, so reaching the bug through them requires unusual design. All requests are unauthenticated per the assessed vector, and fixes are released in 3.0.9 and 4.0.6; the advisory includes a public PoC reference that is not verified as working exploit code, and there is no evidence of active exploitation (not in CISA KEV).