CVE-2026-55619: eml_parser: Parser DoS via deeply nested parentheses in e-mail headers
Summary
emlparser uses the email.utils.getaddresses() function from the CPython standard library to parse e-mail headers that contain e-mail addresses (such as To, Cc, Bcc, From, Reply-To, Sender, ...). When the input header contains a deeply nested CFWS (comment / folding white space) construct, the recursive descent parser in the standard library exhausts the call stack. The resulting RecursionError is not caught by emlparser, so the exception propagates and aborts parsing of the whole message.
Impact
SOC pipelines use emlparser to process untrusted e-mails. An attacker can easily create an eml file that will trigger the RecursionError during parsing.
The impact is mitigated by the fact that there are various other situations in which emlparser will raise an exception when attempting to parse a malformed or pathological eml file. In particular, very deeply nested multipart e-mails also result in a RecursionError being raised by the library voluntarily. Therefore, systems relying on emlparser already need to detect and handle errors emanating from the library in an appropriate way.
Workarounds
The issue can be avoided by wrapping the call to emlparser.decodeemail or emlparser.decodeemailbytes in a try/except construct.
Patches
Since version 3.0.2, emlparser will catch the error in the standard library parser and fall back to a simpler parser based on a regular expression.
Other sources
emlparser serves as a python module for parsing eml files and returning various information found in the e-mail as well as computed information. Prior to 3.0.2, emlparser.parser.HeaderParser.headerfetchparse in emlparser/parser.py uses email.utils.getaddresses() to parse address-bearing e-mail headers. A deeply nested CFWS comment construct exhausts the standard-library recursive descent parser's call stack and raises RecursionError, which is not caught and therefore aborts parsing of the entire message. An attacker can disrupt SOC pipelines that process untrusted EML files, although callers already need to handle exceptions from malformed or pathological messages. This issue is fixed in version 3.0.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/eml_parserto a version that resolves this vulnerability.Fixed in 3.0.2 - Upgrade
Upgrade
eml_parserto a version that resolves this vulnerability.Fixed in 3.0.2 - Configuration
Avoid parser abort by wrapping calls to `eml_parser.decode_email` or `eml_parser.decode_email_bytes` in a `try/except` construct so a `RecursionError` does not propagate and abort parsing of the entire message.
eml_parser decode_email / decode_email_bytes error handling = wrap in try/except for RecursionError (and/or generic exceptions)
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this denial of service?
SOC pipelines and other systems that use eml_parser to process untrusted e-mail messages are exposed. A crafted message can cause parsing of the entire message to abort.
What does an attacker need to do to trigger the issue?
An attacker needs to provide an EML message with an address-bearing header, such as To, Cc, From, Reply-To, or Sender, containing deeply nested comment/folding-whitespace syntax. No authentication or user interaction is indicated.
Are applications already expected to handle similar parsing failures?
Yes. eml_parser can also raise exceptions for other malformed or pathological messages, including deeply nested multipart e-mails that produce a RecursionError. Systems using the library should already detect and handle errors returned by parsing.
What can be done if the available fix cannot be deployed immediately?
Wrap calls to eml_parser so that parsing exceptions, including RecursionError, are caught and handled rather than allowed to abort the surrounding processing pipeline.