CVE-2026-55620: Algorithmic Complexity Denial of Service in GOVCERT-LU eml_parser

The Python library eml_parser, developed by GOVCERT-LU, parses EML structures to extract elements like headers, attachments, and routing metadata. Downstream components like secure email gateways and malware sandboxes rely heavily on this package to inspect untrusted traffic. Because parsing takes place on incoming message flows, any latency in processing directly impacts the performance of SMTP pipelines.

Prior to version 3.0.2, the library's comment-stripping parser in eml_parser/routing.py is vulnerable to algorithmic complexity exploitation. The noparenthesis() routine removes parenthesized Comment Folding White Space (CFWS) from mail headers. An attacker can weaponize this function by transmitting a relatively small email payload containing pathological nesting depths of parentheses.

This behavior triggers complete CPU core saturation, resulting in a denial of service (DoS) for the processing system. The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-1124 (Excessively Deep Nesting). It can be executed remotely and without authentication, making it a high priority for organizations managing automated mail verification frameworks.

RFC 5322 specifications allow the incorporation of Comment Folding White Space (CFWS) inside standard email headers. These comments are bounded within parentheses and can be nested recursively. To ensure accurate downstream validation, processing components must strip out these comments before attempting to parse hostnames or IP addresses from the headers.

In vulnerable versions of eml_parser, the routine attempts to perform this extraction using an iterative regular expression loop. The configuration utilizes the regular expression pattern \([^()]*\) to identify parenthesized groups. This pattern matches only the innermost parenthesized block that contains no internal parentheses, then substitutes it with an empty string.

The algorithm executes inside a while True loop that runs until the processed string matches the prior state. When evaluating an input containing N nested layers of parentheses, the engine must perform N iterations to strip the entire block. Because each iteration must scan and allocate a modified string of size O(N), the overall complexity scales quadratically as O(N^2) relative to the nesting depth. Processing an input with 5,000 parentheses blocks the execution context for approximately 1.3 seconds, and doubling that depth quadruples the required execution duration.

The vulnerability resides inside the noparenthesis function within the eml_parser/routing.py module. Below is the vulnerable version of the parsing function which implements the iterative regular expression replacement loop:

# Vulnerable implementation in eml_parser/routing.py (< v3.0.2)
def noparenthesis(line: str) -> str:
    if not line:
        return line
 
    line_ = line
 
    while True:
        lline = line_
        # Iteratively matches and replaces the innermost nested parenthesis
        line_ = eml_parser.regexes.noparenthesis_regex.sub('', line_)
        if lline == line_:
            break
 
    return line_

To resolve the quadratic execution scaling, the developers removed the iterative regular expression evaluation. They replaced it with a linear-time, stack-based tracking algorithm that reads characters sequentially inside a single loop:

# Patched implementation in eml_parser/routing.py (v3.0.2)
def noparenthesis(line: str) -> str:
    # Initialize stack elements
    fragments: list[list[str]] = [[]]
    for ch in line:
        if ch == '(':
            # Start a new parenthesized block tracking scope
            fragments.append([ch])
        else:
            # Append characters to the active innermost scope
            fragments[-1].append(ch)
        if ch == ')' and len(fragments) > 1:
            # Discard matching parenthesis group scope
            fragments.pop()
    return ''.join(ch for w in fragments for ch in w)

The upgraded stack-based parser resolves the algorithmic vulnerability by ensuring that each character is inspected exactly once. This shifts the runtime performance metrics from quadratic time O(N^2) to strict linear time O(N), preventing malicious payloads from locking worker processes.

An attack requires no special credentials or active session management. The vector relies entirely on submitting a crafted email payload to an address parsed by the vulnerable target application. The payload is delivered via standard SMTP channels or loaded directly from local directories depending on the target implementation.

The attacker crafts a custom EML file with an affected header, such as Received:, populated with thousands of open parentheses followed by an equivalent count of matching close parentheses. When the vulnerable library attempts to analyze the file structure, the thread running the parser becomes locked inside the re.sub convergence loop, driving CPU usage to maximum limits.

This behavior blocks the executing worker, preventing it from addressing other queued messages. If the host platform runs a synchronous queue or a pool with limited parallel processors, a continuous flow of such payloads can exhaust all available processing power, creating a complete application block.

Beyond the algorithmic correction in the comment-stripping routine, the release of version 3.0.2 incorporated additional security and robustness improvements. One such mechanism addresses recursive stack exhaustion. When parsing specific mail list properties like Cc or To fields, the standard email module can trigger a RecursionError if it processes highly deep or malformed nested lists.

To prevent worker crashes from this error class, the maintainers modified eml_parser/parser.py to capture RecursionError and implement a flat regex extraction fallback. This change ensures that the parsing pipeline continues functioning even when handling pathological input variations that would otherwise terminate the application runtime.

Furthermore, the patch resolves security validation bypasses related to obfuscated links. The parser now applies HTML entity unescaping to URLs to uncover masked targets. This adjustment prevents attackers from dodging blacklist detection filters by hiding malicious domains behind encoded syntax.

The primary remedy for this vulnerability is upgrading the eml_parser dependency to version 3.0.2 or higher. This update replaces the quadratic regular expression parser and adds the exception handling fallback components.

For systems where immediate patching is not possible, operators should configure strict line limits on their Mail Transfer Agents (MTAs). Limiting lines to the standard RFC 5322 limit of 998 characters restricts the maximum nesting potential, neutralizing the threat. Additionally, application wrappers should deploy strict timeouts on parser processes to terminate tasks exceeding acceptable limits.

Security teams can deploy signature-based detection rules on incoming mail flows to monitor for exploitation attempts. Monitoring tools can look for consecutive open parentheses inside header strings. Identifying these patterns allows organizations to drop malicious payloads before they are delivered to the parsing engines.