Description

eml_parser 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, eml_parser.parser.HeaderParser.header_fetch_parse in eml_parser/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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-25T19:16:50.477Z",
  "pubdate": "2026-08-25T19:16:50.477Z",
  "executiveSummary": "A stack exhaustion vulnerability exists in the eml_parser Python module, specifically within the header parsing logic. This vulnerability is classified as a Denial of Service (DoS) risk, as it allows a remote attacker to crash the parsing process by providing a specially crafted EML file containing deeply nested comment structures.\nThe vulnerability resides in the interaction between the header_fetch_parse function and the standard library's email.utils.getaddresses() method. By leveraging pathological CFWS (Comment and Folding White Space) syntax, an attacker can trigger an unhandled RecursionError. This results in the immediate termination of the parsing application, which can be particularly damaging to security operations center (SOC) pipelines designed to process and analyze incoming email traffic automatically.\nThe flaw affects all versions of eml_parser prior to 3.0.2. Exploitation requires no authentication or special privileges; it is achieved simply by delivering a malformed email file to a system utilizing the vulnerable module. To mitigate this risk, users must upgrade to version 3.0.2 or higher, which implements the necessary fixes to handle or sanitize these recursive constructs effectively.",
  "technicalDetails": "The vulnerability is located in the eml_parser/parser.py file, within the header_fetch_parse function of the HeaderParser class. The module relies on the Python standard library's email.utils.getaddresses() utility to process address-bearing headers, such as 'To:', 'From:', and 'Cc:'.\nThe root cause is an improper handling of nested CFWS (Comment and Folding White Space) within these email headers. According to RFC specifications, email headers may include comments enclosed in parentheses, which can theoretically be nested. The standard library's recursive descent parser implementation uses the function call stack to process these nested structures. When an EML file contains an excessively deep level of nesting, the parser reaches the maximum recursion depth limit defined by the Python interpreter.\nWhen this limit is exceeded, a RecursionError is raised. In the versions of eml_parser prior to 3.0.2, this exception is not caught within the header_fetch_parse execution block. Consequently, the exception propagates upwards, causing the entire parsing process to abort. This effectively creates a Denial of Service (DoS) condition on any downstream system, such as an automated SOC triage pipeline, that relies on the integrity of the eml_parser output to classify or investigate emails.\nThe exploitation flow is straightforward: an attacker constructs a malicious EML file containing a header field (e.g., 'From: ( ( ( ... (attacker@example.com) ... ) ) )') where the parenthesis nesting depth exceeds the stack limit of the environment. Because eml_parser is typically used to process untrusted input, no authentication or prior system access is required for an attacker to deliver the malicious payload. Once the parsing component receives the file, the attempt to parse the deeply nested structure triggers the stack exhaustion before the system can perform any further analysis or identification of the email content.\nThis vulnerability is particularly impactful in production environments where the parser is integrated into high-volume asynchronous message queues. A single crafted email can cause the parser to fail repeatedly, potentially blocking the entire processing queue and preventing legitimate messages from being analyzed. As the vulnerability resides in the core logic of header processing, all workflows utilizing the affected versions of the module are potentially exposed, regardless of the operating system or specific parsing configuration."
}