Description

Inefficient algorithmic complexity in the bounce and complaint processing of Progressive Robot hMailServer 6.3.4 and 6.3.5 allows a remote unauthenticated attacker to stop mail delivery by sending messages, when bounce processing or complaint processing is enabled or a mailing list is managed by the server (none is by default). The readers of incoming delivery status notifications (RFC 3464) and abuse feedback reports (RFC 5965) removed the blank lines at the start of the returned headers part two bytes at a time, copying the rest of the part each time, so their work grew with the square of the number of blank lines. A message shaped like such a report, whose headers part begins with a very large number of blank lines within the reader's 2 MB limit, keeps a delivery thread busy for over a minute while it is delivered, and a few such messages a minute keep every delivery thread busy.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-08T12:17:15.940Z",
  "pubdate": "2026-10-08T12:17:15.940Z",
  "executiveSummary": "A critical vulnerability exists in Progressive Robot hMailServer versions 6.3.4 and 6.3.5, characterized by inefficient algorithmic complexity during the processing of bounce messages and complaint reports. This flaw allows a remote, unauthenticated attacker to induce a Denial of Service (DoS) condition by exhausting the mail server's delivery threads.\nThe vulnerability stems from a performance bottleneck within the logic responsible for parsing RFC 3464 delivery status notifications and RFC 5965 abuse feedback reports. By sending specifically crafted emails containing a large number of leading blank lines, an attacker can trigger a quadratic-time memory manipulation operation.\nSuccessful exploitation results in the complete cessation of legitimate mail delivery, as available threads become tied up in expensive, recursive data handling tasks. Given that the attack requires no authentication and can be executed over the network, it poses a significant risk to mail server availability. The impact is maximized when bounce processing, complaint processing, or mailing list management features are enabled.",
  "technicalDetails": "The vulnerability resides in the header parsing logic utilized by hMailServer when handling bounce messages (RFC 3464) and complaint feedback reports (RFC 5965). The root cause is an inefficient memory manipulation routine that exhibits quadratic time complexity, O(n^2), relative to the number of blank lines present at the beginning of the returned headers segment of an incoming email.\nWhen the server processes these specific report types, the parsing mechanism attempts to remove leading blank lines from the headers section. The implementation performs this removal two bytes at a time, triggering a memory copy of the entire remainder of the header section for every two-byte removal iteration. If an attacker constructs an email containing a massive sequence of blank lines—while remaining within the server's 2 MB limit—the workload imposed on the processor increases exponentially as the number of blank lines grows.\nThe attack flow is as follows: 1) The attacker crafts an email masquerading as a delivery status notification or abuse feedback report. 2) The attacker inserts a high density of blank lines at the start of the message header structure. 3) The malicious message is transmitted to the hMailServer via SMTP. 4) Upon receipt, if the server is configured for bounce or complaint processing, the parsing function attempts to sanitize the headers. 5) The inefficient removal logic triggers, keeping the delivery thread pinned at high CPU utilization for over a minute per message. 6) By delivering a small number of such messages concurrently, an attacker can saturate all available delivery threads, effectively blocking the server from processing or relaying any legitimate email traffic.\nThis vulnerability is particularly dangerous as it is remotely exploitable without authentication, requiring only network reachability to the SMTP port. Because the parsing happens during the processing stage, the server consumes substantial computational resources before the message is fully validated or discarded, leading to effective resource exhaustion."
}