CVE-2026-107574 in hMailServer
Summary
by MITRE • 10/08/2026
Inefficient algorithmic complexity in the JSON reader of Progressive Robot hMailServer allows a remote unauthenticated attacker to make the mail services unavailable. Reading a JSON object kept the first of each duplicated member name by searching the members already read, so an object of N distinct member names cost O(N^2): 1 MB took 8.9 seconds and 4 MB took 300 seconds against the affected code. A remote attacker reaches the reader without an account by mailing a crafted TLS-RPT report (up to 16 MB after decompression) to a hosted domain's published report mailbox, which is read on a delivery thread; a few such reports hold every delivery thread (ten by default), so the server delivers no mail, local or outbound, for over an hour per report. A signed-in account reaches the same 16 MB body through the webmail's own REST routes, holding the REST API's own worker threads. Where no report mailbox is configured, the unauthenticated REST sign-in routes that read a JSON body are capped at 64 KB and are not affected.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in hMailServer involves an inefficient algorithmic complexity within its JSON parsing logic, specifically affecting the handling of TLS-RPT reports and webmail API requests. This flaw allows for a Denial of Service (DoS) condition by exploiting quadratic time complexity during object member deduplication. The core technical issue stems from how the internal JSON reader processes duplicate keys in an object; rather than using a hash map or similar data structure that offers constant-time lookups, it iterates through previously read members to determine if a key has already been encountered. Consequently, processing an object with N distinct member names results in O(N^2) computational cost. This inefficiency becomes critical when attackers supply large JSON payloads containing many duplicate keys, causing the server's CPU resources to be consumed excessively during parsing operations.
From an operational perspective, this vulnerability enables remote unauthenticated attackers to disrupt mail services significantly. An attacker can send a crafted TLS-RPT report with up to 16 MB of data after decompression to a hosted domain’s published report mailbox. Because hMailServer processes these reports on delivery threads, and the server typically maintains only ten such threads by default, submitting just a few maliciously constructed reports is sufficient to exhaust all available delivery threads. This results in a complete inability to deliver mail, both locally and outbound, for over an hour per attack vector. The impact is severe as it effectively halts critical communication infrastructure without requiring any authentication credentials.
Additionally, authenticated users can exploit this flaw through the webmail interface’s REST API routes. By signing into the webmail portal, a user can submit requests with JSON bodies up to 16 MB in size via specific REST endpoints. This action consumes worker threads dedicated to handling REST API traffic, leading to similar service degradation for other users relying on those resources. It is important to note that if no report mailbox is configured, unauthenticated access through certain REST sign-in routes is capped at a smaller payload limit of 64 KB, which mitigates the risk in those specific configurations but does not address the broader vulnerability present in TLS-RPT processing and authenticated API usage.
This issue aligns with CWE-789: Memory or Resource Leak by Incorrect Quantity Control, as well as CWE-1325: Improper Verification of Digest Signature if signature validation is bypassed due to resource exhaustion before completion. In terms of the MITRE ATT&CK framework, this vulnerability facilitates an Impact category attack known as Service Exhaustion (T1499), where the attacker aims to make a specific service or system unavailable by consuming its resources. The exploitation relies on algorithmic complexity rather than buffer overflows or injection techniques, highlighting the importance of efficient data structure selection in security-critical parsing components.
Mitigation strategies should prioritize updating hMailServer to versions that have patched this JSON parsing logic, ensuring that duplicate key handling utilizes more efficient algorithms such as hash-based lookups with O(1) complexity. Administrators who cannot immediately patch their systems should consider configuring rate limiting on TLS-RPT report submissions and REST API endpoints to restrict the size of incoming payloads below the threshold that triggers significant resource exhaustion. Furthermore, increasing the number of delivery threads may provide temporary relief but does not resolve the underlying computational inefficiency; therefore, software updates remain the primary remediation path. Monitoring for unusually large JSON payloads in mail headers or API requests can also aid in early detection and blocking of such attacks before they impact service availability.