Allocation of Resources Without Limits or Throttling in hMailServer
Summary
| CVE | CVE-2026-126613 |
|---|---|
| State | PUBLISHED |
| Assigner | GitLab |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-11-11 09:17:13 UTC |
| Updated | 2026-11-11 09:17:13 UTC |
| Description | Allocation of resources without limits in the JSON reader of Progressive Robot hMailServer 6.3.2 through 6.3.7 allows a remote attacker to exhaust the server's memory and hold its threads, making mail delivery, the REST API and the webmail unavailable. The reader built a tree of values far larger than the text it read, copying each value into every level above it, and set no bound on the number of values, so a single JSON document of many small values, within the 16 MB the server reads, raised the service's memory by about 2 GB and held one thread for seconds to minutes. From 6.3.4 a remote unauthenticated attacker reaches the reader by mailing such a document as a TLS-RPT report, up to 16 MB once decompressed, to a hosted domain's report mailbox, where an administrator has set one; it is read on a mail delivery thread (ten by default), and those threads deliver all mail, local and outbound. From 6.3.4 it is also reached without an account through the reply to a password-protected message, with the message's link alone, where the REST API is on (it is off by default) and a public base URL for such links is set; and by any account, from 6.3.2 through the webmail's send and draft routes and from 6.3.4 through its other routes granted 16 MB and the send API; the webmail's send, draft and settings routes parsed the body again for each member read. The REST API serves every request on four worker threads, in the process that also serves SMTP, IMAP and POP3, so a few such documents at once make it unavailable and can exhaust the machine's memory and end the whole service. This is a separate defect from CVE-2026-107574, the reader's handling of duplicate member names, fixed in 6.3.6. |
Risk And Classification
Primary CVSS: v3.1 7.5 HIGH from [email protected]
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Problem Types: CWE-770 | CWE-770 CWE-770: Allocation of Resources Without Limits or Throttling
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 7.5 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| 3.1 | CNA | CVSS | 7.5 | HIGH | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
CVSS v3.1 Breakdown
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Progressive Robot Ltd | HMailServer | affected 6.3.2 6.3.7 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 | [email protected] | gitlab.com | |
| gitlab.com/hmailserver/hmailserver/-/work_items/110 | [email protected] | gitlab.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Found by the hMailServer project (Progressive Robot Ltd) (en)
Additional Advisory Data
Solutions
CNA: Upgrade to hMailServer 6.3.8, whose JSON reader moves each value into its place rather than copying it, and in which a REST request body is parsed within the bounds before any handler reads it, and the shared member readers read that one parse; a REST request body is held to 100,000 values, 10,000 members in an object and 32 levels, and a mailed TLS-RPT report to 200,000 values, 10,000 members in an object and 32 levels, each refused at the first value past a bound; the reply to a password-protected message is held to 2 MB. Until then, on 6.3.4 to 6.3.7, clear each domain's report mailbox, or move it off the domains the server hosts, so that no report is read by the server; and switch OpenPGP in the webmail off (portal_enabled under /api/v1/settings/openpgp), and off for any domain or account that holds openpgp_portal_enabled on, which refuses the reply to a password-protected message before its body is parsed; clearing the public base URL is not enough, since links already made stay usable. For the routes that take an account or an API key, only limiting who can reach the REST API avoids it (RestApiPort 0, the default, turns it off), or a reverse proxy in front of it that holds request bodies well below 16 MB. Restarting the service ends a busy thread.