zbateson/mail-mime-parser has uncontrolled resource consumption (CPU/memory DoS) parsing untrusted MIME

Monitoren (42/100) — monitoren. Bepalend: technische ernst (65/100) en exploiteerbaarheid (42/100). Houd dit in de gaten; directe actie is nu niet nodig. Deze prioritering is regelgebaseerd en navolgbaar; weeg de aannames en onzekerheden mee voor de eigen gemeentelijke omgeving.

Deze prioritering is regelgebaseerd en navolgbaar. Een CISO kan deze onderbouwing gebruiken richting directie of ICT-management; stem de opvolging af op de eigen gemeentelijke omgeving.

De acties zijn regelgebaseerd gegenereerd. Stem ze af op de eigen gemeentelijke omgeving en wijs per actie een eigenaar en deadline toe.

// Defender-waarschuwingen rond endpointcompromittatie
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Microsoft Defender for Endpoint"
| where AlertSeverity in ("High", "Medium")
| project TimeGenerated, AlertName, AlertSeverity, CompromisedEntity,
    Description
| order by TimeGenerated desc

Deze informatie is uitsluitend defensief: detectie en hunting. De KQL-queries zijn read-only en bedoeld voor Microsoft Sentinel.

Geachte heer/mevrouw,

Naar aanleiding van een beveiligingsmelding met kenmerk CVE-2026-61816 doet onze gemeente een uitvraag bij u als leverancier. Deze uitvraag dient ter verificatie en feitenvaststelling: wij willen vaststellen of en in welke mate de aan onze gemeente geleverde dienstverlening wordt geraakt. Het betreft mogelijk het product of onderdeel "zbateson/mail-mime-parser".

Wij verzoeken u de onderstaande vragen volledig en onderbouwd te beantwoorden en uw reactie binnen tien (10) werkdagen na ontvangst van dit bericht schriftelijk aan te leveren bij de informatiebeveiligingsfunctie van onze gemeente. Zijn bepaalde gegevens nog niet beschikbaar, dan ontvangen wij graag een tussentijdse terugkoppeling.

Vragen:
1. Gebruikt u de kwetsbare component of het geraakte product?
2. Welke versies zijn bij u in gebruik?
3. Is de kwetsbaarheid van toepassing op de dienstverlening aan onze gemeente?
4. Is de kwetsbaarheid inmiddels gepatcht?
5. Zo ja, op welke datum is de patch doorgevoerd?
6. Zo nee, welke mitigerende maatregelen zijn genomen?
7. Is er actief misbruik van de kwetsbaarheid geconstateerd?
8. Is er logging of forensisch onderzoek uitgevoerd?
9. Is er sprake van een risico op een datalek?
10. Wanneer verwacht u een definitieve oplossing door te voeren?
11. Welke restrisico's blijven na de oplossing bestaan?
12. Welke communicatie mogen wij richting onze interne stakeholders gebruiken?

Deze uitvraag is bedoeld om de feiten vast te stellen en gezamenlijk tot een passende opvolging te komen. Wij stellen uw tijdige medewerking op prijs.

Met vriendelijke groet,

[Naam]
Namens de informatiebeveiligingsfunctie
Gemeente [Gemeente]

Vul vóór verzending de afzender en gemeentenaam in. De tekst is zakelijk en gericht op feitenvaststelling; pas hem aan op de eigen situatie.

Deze dreiging raakt de onderstaande governance-thema's. Met de aanbevolen bewijsstukken kunt u aantonen dat het signaal is opgevolgd — bruikbaar voor BIO2, NIS2/CBW, ISMS en de ENSIA-verantwoording.

### Impact An uncontrolled resource consumption / algorithmic complexity vulnerability affecting any application that parses untrusted email with this library. Three independent parsing paths are super-linear in cost, so a byte-size cap on the caller side does **not** bound the work done. A crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory (leading to an out-of-memory kill), enabling denial of service. The parse is lazy, but the cost is paid on the first `getAllParts()` or content read. ### Details 1. **Deep multipart nesting is O(depth²).** `MimeParserService::findContentBoundary()` tests each content line against the current part and every ancestor via the recursive `ParserMimePartProxy::setEndBoundaryFound()`, so a nesting depth of D costs 1 + 2 + … + D comparisons. A ~600 KB message nested ~10,000 deep does not finish parsing in a minute. 2. **Many sibling parts is O(n²).** `PartChildrenContainer::add()` appends each child with `array_splice($children, count($children), 0, [$part])`, which reindexes the entire array on every call. The same container backs UUEncoded `begin` parts via `NonMimeParserService`. 3. **Header buffering is unbounded.** `HeaderParserService::parse()` reads header lines up to a blank line with no limit on header count or total size, so a few megabytes of header lines can hold hundreds of megabytes resident; a ~5 MB message of headers can reach multiple gigabytes and be OOM-killed. ### Proof of concept ```php composer require zbateson/mail-mime-parser parse($raw, false)->getAllParts()); printf("%-22s input=%5.2f MB time=%6.2f s peak=%6.1f MB\n", $label, strlen($raw) / 1048576, microtime(true) - $t, memory_get_peak_usage(true) / 1048576); } measure('nesting depth=2000', nestedMessage(2000)); measure('siblings=50000', siblingMessage(50000)); measure('headers=300000', headerMessage(300000)); ``` Run with a raised memory limit so the header case does not abort early: php -d memory_limit=2048M poc.php // nesting depth=2000 input= 0.13 MB time= 2.08 s peak= 30.0 MB // siblings=50000 input= 1.72 MB time= 5.11 s peak= 276.0 MB // headers=300000 input= 2.29 MB time= 0.40 s peak= 380.3 MB ### Patches Fixed in 4.0.2 and 3.0.6. The fixes add configurable limits on multipart nesting depth and on header count / total header size (recording a parse error past the threshold rather than throwing), and change sibling append to O(n). Users should upgrade to one of these (or later) versions. Versions 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. (Versions prior to 2.0 used a different parser and are not affected by all three paths.) ### Workarounds These costs are super-linear, so an input byte-size cap alone does not bound them. Until upgrading, restrict exposure of the parser to untrusted input, and run parsing under a constrained memory_limit and execution time limit so a malicious message fails its own request rather than exhausting the host. - Found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches.