GHSA-g7gc-gmgp-wgqg: High severity pip/eml_parser vulnerability
Summary
emlparser strips parenthesised CFWS comments from Received: headers using a regex-based fix-point loop. The loop has quadratic time complexity in the number of nested parens. A single Received: header containing 5,000 nested parens causes ~1.3 seconds of CPU saturation per parsed message; runtime quadruples per doubling of nesting depth.
Impact
This represents a CPU exhaustion DoS in any pipeline that processes attacker-supplied EML files. An attacker can create relatively small EML files that will take multiple seconds to parse.
This is particularly problematic for synchronous email-processing pipelines (gateways, sandboxes, real-time triage) where worker latency directly translates to queue backpressure and possible service-level outages.
Patches
Since version 3.0.2, emlparser uses a linear-time algorithm to remove the comments from Received: headers.
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 - Compensating control
Mitigate CPU-exhaustion DoS by adding rate limiting and/or resource controls around ingestion/processing of attacker-supplied EML files in synchronous pipelines (gateways, sandboxes, real-time triage) to reduce worker latency and queue backpressure.
Event History
Frequently Asked Questions
Which deployments are most exposed to service disruption?
Pipelines that parse attacker-supplied EML files are affected, especially synchronous email gateways, sandboxes, and real-time triage services. In these environments, parser delays can create worker queue backpressure and potentially lead to service-level outages.
What does an attacker need to send to trigger the issue?
An attacker only needs to provide an EML file with a Received: header containing deeply nested parenthesized comments. A header with 5,000 nested parentheses can consume about 1.3 seconds of CPU time for each parsed message, and processing time grows quadratically as nesting increases.
What version resolves the CPU exhaustion issue?
Version 3.0.2 and later use a linear-time algorithm to remove comments from Received: headers, resolving the quadratic processing behavior.