CVE-2026-107572: Inefficient Regular Expression Complexity in hMailServer
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 'aaab' 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.6 - Configuration
Lower the maximum message size.
hMailServer maximum message size = lower - Compensating control
Review active Sieve scripts for ':matches' patterns with several wildcards and for 'deleteheader'.
Event History
Frequently Asked Questions
Which deployments are exposed to service disruption?
Servers running hMailServer 6.2.24 through 6.3.5 are exposed when an authenticated account holder can use an active Sieve filter. The impact is server-wide mail-delivery disruption because Sieve evaluation uses a small shared delivery thread pool.
What access does an attacker need?
The attacker needs a valid hMailServer account and must be able to configure their own active Sieve script. They do not need to modify another user's filter, and cannot set the vulnerable script for another user.
How can exploitation disrupt delivery?
An account holder can use costly ':matches' patterns or 'deleteheader' operations in their own filter, then send a few messages to themselves. Long-running filter evaluations can exhaust the shared delivery threads and stop delivery for the whole server.
What can be done if an update cannot be applied immediately?
The provided information identifies active Sieve scripts as the exploitation path. Restricting or disabling use of active Sieve filters for untrusted accounts would remove that path, though no specific interim mitigation is provided.