Decoding a header that holds a long run of joinable RFC 2047 base64 encoded words, such as =?utf-8?B?QUJD?= repeated tens of thousands of times in a Subject, From, To, a filename or a description, took time quadratic in the number of words. The join check ran a regex over the text joined so far for every word, which flattens the accumulated string each time. A single well formed message of about 1.6 MB blocked the event loop for one to twenty seconds depending on the host, and inline message/rfc822 parts multiplied the cost, since each nested message carried its own header budget.

Any application that parses untrusted mail with postal-mime 3.0.0 through 4.0.7, including the exported decodeWords() helper, is affected. There is no confidentiality or integrity impact.

Fixed in 4.0.8. The pad check now tracks the last appended word instead of testing the joined text, so decoding is linear in the header length. The same release also counts the parts and header bytes of inline message/rfc822 sub-messages against the limits of the message as a whole, counts every header line for at least 64 bytes of maxHeadersSize, and adds a scaling test that measures every stage of the parser at two input sizes.

Lower maxHeadersSize from its 2 MiB default to bound the cost per message, or parse untrusted mail in a worker that can be terminated.

Reported by Felipe Fernández.