Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 3.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
emlparser performs certain validations on potential URL strings to discard bogus values. In versions prior to 3.0.2, this validation was performed before unescaping any HTML entities that might occur in the string. This caused the library to wrongfully reject valid URLs that use HTML entities for the :, /, or . characters. These URLs would then not be included in the list of extracted URLs. Similarly, the host parts of such URLs would not be extracted. For example, neither the URL https://phishing.example.com nor its host (phishing.example.com) would appear in the parsing result. Impact emlparser is used in email security gateways and SOC pipelines to extract URLs as IOCs. Those URLs are then checked against threat-intel feeds, URL reputation services, and sandboxes. A URL that is not extracted is never checked. Patches Since version 3.0.2 the library unescapes all HTML entities in every URL before deciding to accept or reject it. A test was added to…
Recommended action: Upgrade to 3.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
EmlParser.getrawbodytext() recurses unconditionally for every nested message/rfc822 attachment without any depth limit. An attacker who can supply a badly crafted EML file with approximately 120 nested message/rfc822 parts triggers an unhandled RecursionError and aborts parsing of the message. A 12 KB EML file is enough to crash a worker. Though this causes the parser to crash, it is an unlikely scenario as the suggested EML that crashes the parser would not pass basic RFC compliance tests. Details The vulnerable function is EmlParser.getrawbodytext() in emlparser/parser.py. For every part of type multipart/, the function iterates over its sub-parts; for every sub-part of type message/rfc822, it calls itself recursively on the inner message: There is no depth parameter and no early-abort. CPython's default sys.recursionlimit is 1000. Each level of message/rfc822 nesting adds approximately 8 frames to the stack (parser code + stdlib headervalueparser calls), so roughly 120…
Recommended action: Upgrade to 3.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The official example script examples/recursivelyextractattachments.py contains a path traversal vulnerability that allows arbitrary file write outside the intended output directory. Attachment filenames extracted from parsed emails are directly used to construct output file paths without any sanitization, allowing an attacker-controlled filename to escape the target directory. Details File: examples/recursivelyextractattachments.py Lines: 61–64 The value a['filename'] is attacker-controlled via crafted email attachment headers: No path normalization or boundary validation is performed before writing. PoC 1. Create a malicious .eml file: 2. Run the example script: 3. Expected: ./safe/pwned.txt 4. Actual: ./outside/pwned.txt ← written outside the intended directory Verified on Kali Linux with emlparser installed via pip in a virtual environment. Impact This vulnerability is limited to the example script only and does not affect the core emlparser library. However, as the script…
Recommended action: Upgrade to 2.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.