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.routing.noparenthesis in eml_parser/routing.py removes parenthesized CFWS comments from Received: headers with a regex-based fix-point loop whose running time is quadratic in the nesting depth. A single Received: header with 5,000 nested parentheses causes approximately 1.3 seconds of CPU saturation per parsed message, and doubling the nesting depth approximately quadruples the running time. An attacker can submit relatively small EML files that consume multiple seconds of processing time, causing worker latency, queue backpressure, and possible service-level outages in synchronous gateways, sandboxes, and real-time triage pipelines. This issue is fixed in version 3.0.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-25T19:16:50.627Z",
  "pubdate": "2026-08-25T19:16:50.627Z",
  "executiveSummary": "A ReDoS (Regular Expression Denial of Service) vulnerability exists in the eml_parser Python module prior to version 3.0.2.\nThe vulnerability resides in the eml_parser.routing.noparenthesis function within the file eml_parser/routing.py, which utilizes a flawed regex-based fix-point loop to process nested parenthetical comments within Received: headers.\nThe computational complexity of this implementation is quadratic relative to the nesting depth of the parentheses.\nAn attacker can exploit this by crafting an EML file containing deeply nested parentheses, leading to significant CPU saturation.\nThis behavior results in worker latency, queue backpressure, and potential service-level outages for systems utilizing the parser for synchronous email processing, sandboxing, or real-time triage.\nNo authentication or specific privileges are required to initiate this attack, as the payload is delivered via standard email ingestion vectors.",
  "technicalDetails": "The vulnerability is caused by a performance bottleneck in the parsing logic for email headers. Specifically, the eml_parser.routing.noparenthesis function is tasked with removing CFWS (Commented Folding White Space) parenthesized comments from Received: headers.\nThe implementation uses a regex-based approach that iteratively attempts to strip nested parentheses. Because this mechanism relies on a fix-point loop that does not scale linearly with input size, the algorithm exhibits quadratic time complexity O(n^2) where n is the depth of the nesting.\nAs nesting depth increases, the number of operations required to resolve the header string grows at an exponential rate relative to the input length. Empirical testing confirms that 5,000 nested parentheses cause approximately 1.3 seconds of CPU saturation per single message processed.\nThe attack flow follows a straightforward pattern: 1) An attacker crafts a malicious EML file containing a malformed Received: header with an extremely high degree of parenthesis nesting. 2) The EML file is submitted to a target application or service pipeline that utilizes an affected version of eml_parser (prior to 3.0.2). 3) The parsing module triggers the vulnerable loop in eml_parser.routing.py. 4) The host system experiences high CPU utilization, leading to thread exhaustion and increased processing latency for subsequent legitimate tasks.\nBecause the parser performs this operation synchronously during standard email ingestion, the impact is immediately felt across the service pipeline. For gateways or sandboxes that process large volumes of mail, this effectively prevents the system from maintaining real-time performance, potentially causing service-wide outages or mass denial of service for email processing functionality.\nThe flaw affects all versions of eml_parser prior to 3.0.2. Exploitation is remote and requires no interaction from the targeted system's administrators, as the vulnerability is triggered automatically upon the parser attempting to process the malicious input."
}