CVE-2026-107572 in hMailServerinfo

Summary

by MITRE • 10/08/2026

Inefficient complexity in the Sieve filter evaluation of Progressive Robot hMailServer 6.2.24 through 6.3.5 allows an authenticated account holder to make the mail services unavailable with their own filter. A ':matches' pattern was matched by a backtracking descent whose time grew with the matched value's length raised to the number of wildcards, so a pattern such as '*a*a*a*b' over 800 characters took 44 seconds; and 'deleteheader' erased the fields it removed one at a time, so removing many fields of one name over a message's header cost O(N^2) (80,000 fields took 18.8 seconds). Sieve filters run on the small, shared delivery thread pool, so an account holder whose active script does this, fed a few messages they can send themselves, empties the pool and stops delivery for the whole server. The script is the account holder's own and cannot be set for another user.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/08/2026

The vulnerability identified in hMailServer versions 6.2.24 through 6.3.5 represents a significant denial of service risk stemming from inefficient complexity within the Sieve filter evaluation engine. This flaw allows an authenticated account holder to render mail services unavailable for the entire server by exploiting resource exhaustion mechanisms inherent in the script processing logic. The core issue lies not in a traditional buffer overflow or injection attack, but rather in algorithmic inefficiencies that lead to catastrophic performance degradation under specific conditions. Because Sieve filters are executed on a small, shared delivery thread pool within hMailServer architecture, any single account consuming excessive computational resources directly impacts the availability of mail services for all users on the system. This architectural dependency amplifies the impact of local resource exhaustion into a global service outage.

The first vector of exploitation involves regular expression matching inefficiencies in the Sieve :matches command. The underlying implementation utilizes a backtracking descent algorithm to evaluate patterns, which exhibits exponential time complexity relative to the length of the matched value and the number of wildcards present in the pattern. For instance, a crafted pattern such as 'aaab' applied against an input string exceeding 800 characters can require up to forty-four seconds to complete evaluation. This quadratic or worse-than-linear growth in processing time means that relatively small inputs can trigger disproportionately long execution periods. An attacker with valid credentials can create a filter containing such optimized malicious patterns and configure it to activate upon receipt of specific messages, thereby forcing the server to spend excessive CPU cycles on regex evaluation rather than actual mail delivery tasks.

The second vector exploits an inefficiency in the deleteheader action within Sieve scripts. When multiple headers sharing the same name are removed from a message, the implementation processes them one at a time rather than in bulk or with optimized data structure manipulation. This results in O(N squared) complexity relative to the number of header fields being processed. In practical terms, removing eighty thousand identical header fields can take nearly nineteen seconds to complete. By crafting messages that contain an abnormally large number of duplicate headers and configuring their account filters to delete these specific headers upon arrival, an authenticated user can trigger this quadratic performance penalty repeatedly. This further contributes to the saturation of the delivery thread pool, as each message processing cycle becomes significantly longer than intended by design specifications.

The operational impact of these vulnerabilities is severe due to the shared nature of the hMailServer delivery infrastructure. The server relies on a limited number of threads to handle incoming and outgoing mail transactions for all users simultaneously. When one or more accounts execute filters that consume excessive CPU time through inefficient regex matching or header manipulation, those threads remain occupied for extended durations. This effectively starves other legitimate mail processing tasks, leading to a backlog of undelivered messages and eventual unresponsiveness of the SMTP service. Since the attack requires only authenticated access and self-sent messages, it is relatively easy to execute without needing elevated privileges or external network exposure beyond standard email submission ports. The fact that scripts are confined to their own account does not mitigate the risk because the resource consumption occurs on shared system resources rather than isolated user spaces.

From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting as a Denial of Service through algorithmic complexity attacks. It also maps to MITRE ATT&CK technique T1496, Host-Based DoS, where an adversary uses local resources to disrupt service availability. The lack of input validation or length limits on Sieve script patterns and header counts allows for the construction of inputs that trigger these worst-case scenarios in the underlying C++ implementation of hMailServer.

Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary recommendation is to upgrade hMailServer to a version where this vulnerability has been patched, as developers typically address such issues by implementing stricter limits on regex complexity or optimizing header manipulation algorithms. In the interim, administrators should enforce strict Sieve script policies that limit the length of patterns used in :matches commands and restrict the number of headers that can be manipulated per message. Implementing rate limiting for filter execution could also help prevent a single account from monopolizing delivery threads. Additionally, monitoring CPU usage on mail servers for anomalies associated with specific user accounts can aid in early detection of such abuse before it results in complete service outage. Regular audits of Sieve scripts deployed across the organization should include checks for potentially malicious or inefficient patterns to ensure compliance with security best practices and maintain system stability.

Responsible

GitLab

Reservation

10/08/2026

Disclosure

10/08/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you need the next level of professionalism?

Upgrade your account now!