CVE-2026-55620: eml_parser Denial of Service Vulnerability

CVE-2026-55620 Overview

CVE-2026-55620 is a regular expression denial of service (ReDoS) vulnerability in eml_parser, a Python module used to parse .eml email files and extract routing, header, and body information. The flaw resides in eml_parser.routing.noparenthesis inside eml_parser/routing.py, where a regex-based fix-point loop exhibits quadratic runtime relative to parenthesis nesting depth in Received: headers. A single crafted header with 5,000 nested parentheses consumes approximately 1.3 seconds of CPU per message, and runtime approximately quadruples each time nesting depth doubles. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling] and is fixed in version 3.0.2.

Critical Impact
Attackers can submit small EML files that saturate parser workers, causing queue backpressure and service outages in mail gateways, sandboxes, and real-time triage pipelines.

Affected Products

eml_parser Python module, all versions prior to 3.0.2
Email security gateways and sandboxes embedding eml_parser
Real-time email triage pipelines that parse untrusted EML input

Discovery Timeline

2026-08-25 - CVE-2026-55620 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-55620

Vulnerability Analysis

The vulnerability lives in the noparenthesis helper used to strip CFWS (comments/folding white space) parenthesized comments from Received: headers during routing extraction. The function iteratively applies a regex to remove innermost parenthesized groups until none remain. Because each iteration rescans the string and only removes one nesting level, total work scales quadratically with the depth of nested parentheses.

An attacker crafts an EML file containing a Received: header with thousands of nested (...) groups. Parsing a single such message consumes multiple seconds of CPU time. When queued across parser workers in a synchronous gateway or sandbox, this yields sustained CPU saturation, worker starvation, and cascading delays for legitimate mail.

Root Cause

The root cause is unbounded input processing combined with an inefficient parenthesis-stripping algorithm. The regex fix-point loop performs O(n) scans over an O(n)-length string for O(n) iterations, producing quadratic complexity. No input-size or nesting-depth limits are enforced before parsing, allowing small inputs to trigger large amounts of CPU work.

Attack Vector

Exploitation requires only the ability to submit an EML file into a system that invokes eml_parser. This includes SMTP gateways, phishing analysis sandboxes, security orchestration pipelines, and web-facing email inspection services. No authentication or user interaction is needed, and the payload is a plaintext header requiring no binary crafting.

python

# Patched code excerpt from eml_parser/parser.py (v3.0.2)
# The fix adds a RecursionError guard in header_fetch_parse to prevent
# pathological headers from crashing the recursive descent parser and
# falls back to a bounded regex-based address extraction.

elif header in ('sender', 'resent-sender', 'to', 'resent-to', 'cc',
                'resent-cc', 'bcc', 'resent-bcc', 'from', 'resent-from',
                'reply-to'):
    try:
        return super().header_fetch_parse(name, value)
    except RecursionError:
        # Pathological header. Extract addresses via bounded regex.
        m = eml_parser.regexes.email_regex.findall(value)
        return ', '.join(m)

return super().header_fetch_parse(name, value)

Source: GitHub Commit 746a69f

Detection Methods for CVE-2026-55620

Indicators of Compromise

EML messages containing Received: headers with unusually deep nested parentheses (hundreds or thousands of levels).
Parser worker processes showing sustained single-core CPU saturation while handling one message.
Sudden increases in email processing latency or queue depth without a corresponding increase in message volume.

Detection Strategies

Instrument eml_parser invocations with per-message CPU time and wall-clock timers, alerting on outliers exceeding a baseline threshold (for example, 500 ms).
Pre-scan incoming EML files for header lines with excessive ( character counts before handing them to the parser.
Log and correlate parser exceptions, timeouts, and worker restarts in email inspection pipelines.

Monitoring Recommendations

Track CPU utilization and processing latency on mail gateway and sandbox workers running Python email parsers.
Monitor SMTP receive queues for backpressure and repeated retries associated with the same source or message pattern.
Alert on repeated RecursionError or timeout events emitted by eml_parser in application logs.

How to Mitigate CVE-2026-55620

Immediate Actions Required

Upgrade eml_parser to version 3.0.2 or later across all environments that ingest untrusted EML content.
Enforce per-message CPU and wall-clock time limits on parser workers to contain any residual pathological input.
Cap maximum EML file size and maximum header length at ingestion boundaries.

Patch Information

The fix is available in eml_parser v3.0.2. Technical background is documented in GHSA-g7gc-gmgp-wgqg and Pull Request #90. Rebuild and redeploy any container images, serverless functions, or virtual appliances that vendor the vulnerable version.

Workarounds

Run eml_parser invocations inside a subprocess or worker with a strict timeout, terminating any parse that exceeds the budget.
Reject or quarantine messages whose Received: headers contain more than a small threshold of unmatched or nested ( characters.
Isolate parsing workloads on dedicated workers so that CPU exhaustion does not degrade unrelated services.

bash

# Upgrade the vulnerable module
pip install --upgrade 'eml_parser>=3.0.2'

# Verify the installed version
python -c "import eml_parser; print(eml_parser.__version__)"