postal-mime: Quadratic CPU Consumption via Crafted Email Headers (GHSA-f2hq-32vh-53cc)

What Happened

A vulnerability was disclosed in postal-mime affecting how it decodes email headers containing long runs of joinable RFC 2047 base64 encoded words (such as repeated `=?utf-8?B?QUJT?=` sequences in a Subject, From, To, filename, or description field). The decoding logic ran a regular expression over the entire accumulated text for every word processed, causing the parsing time to grow quadratically with the number of words rather than linearly.

Technical Cause

The vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption). The underlying cause is that postal-mime's join check for RFC 2047 encoded words re-flattened and re-scanned the accumulated string with a regex for each new word, rather than tracking only the most recently appended word. A single well-formed message of roughly 1.6 MB containing such a header was reported to block the event loop for one to twenty seconds, depending on the host. Inline `message/rfc822` parts (nested messages) further multiplied the cost, since each nested message carried its own separate header budget.

Why It Matters

This issue carries a CVSS score of 7.5 (vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), reflecting a network-exploitable denial-of-service condition that requires no authentication and no user interaction, with high impact on availability but none on confidentiality or integrity. Any application that uses postal-mime to parse untrusted or externally-supplied email — including through the exported `decodeWords()` helper — can be forced to consume excessive CPU, potentially degrading or blocking processing of other requests while the event loop is occupied.

Who Is Affected

Any application or service that uses the postal-mime npm package to parse untrusted email input is affected if running an impacted version.

Affected Versions

postal-mime versions 3.0.0 up to but not including 4.0.8 are affected, including version 4.0.7. The issue is fixed in version 4.0.8.

Fixes and Mitigation

The issue is fixed in postal-mime 4.0.8. The fix changes the pad check to track only the last appended word instead of re-testing the entire joined text, making decoding time linear in header length. The 4.0.8 release also counts the parts and header bytes of inline `message/rfc822` sub-messages against the overall message's limits, counts every header line for at least 64 bytes toward `maxHeadersSize`, and adds a scaling test measuring parser performance at two input sizes. As a workaround for systems that cannot immediately update, lowering `maxHeadersSize` from its 2 MiB default can bound the cost per message, or untrusted mail can be parsed in a worker process that can be terminated if it runs too long.

Recommended Action

Update postal-mime to version 4.0.8 as soon as practical. If an immediate update is not feasible, reduce the `maxHeadersSize` setting from its default or isolate untrusted mail parsing in a terminable worker process as a temporary mitigation.