Vulnerability-Lookup

GHSA-68QJ-R5Q8-PVM5

Vulnerability from github – Published: 2026-11-11 09:31 – Updated: 2026-11-11 09:31

Details

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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-126613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-11-11T09:17:13Z",
    "severity": "HIGH"
  },
  "details": "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\u0027s 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\u0027s 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\u0027s 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\u0027s 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\u0027s send and draft routes and from 6.3.4 through its other routes granted 16 MB and the send API; the webmail\u0027s 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\u0027s memory and end the whole service. This is a separate defect from CVE-2026-107574, the reader\u0027s handling of duplicate member names, fixed in 6.3.6.",
  "id": "GHSA-68qj-r5q8-pvm5",
  "modified": "2026-11-11T09:31:29Z",
  "published": "2026-11-11T09:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-126613"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/110"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-126613 (GCVE-0-2026-126613)

Vulnerability from cvelistv5 – Published: 2026-11-11 08:31 – Updated: 2026-11-11 08:31

Title

Allocation of Resources Without Limits or Throttling in hMailServer

Summary

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitLab CNA under the mitre root

CNA scorecard C 74/100 over 303 records in the last 180 days details

References

2 references

URL	Tags
https://gitlab.com/hmailserver/hmailserver/-/work…
https://gitlab.com/hmailserver/hmailserver/-/rele…

Impacted products

1 product

Vendor	Product	Version
Progressive Robot Ltd	hMailServer	Affected: 6.3.2 , ≤ 6.3.7 (semver)

Credits

Found by the hMailServer project (Progressive Robot Ltd)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "hMailServer",
          "repo": "https://gitlab.com/hmailserver/hmailserver",
          "vendor": "Progressive Robot Ltd",
          "versions": [
            {
              "lessThanOrEqual": "6.3.7",
              "status": "affected",
              "version": "6.3.2",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Found by the hMailServer project (Progressive Robot Ltd)"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s 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\u0027s 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\u0027s 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\u0027s send and draft routes and from 6.3.4 through its other routes granted 16 MB and the send API; the webmail\u0027s 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\u0027s memory and end the whole service. This is a separate defect from CVE-2026-107574, the reader\u0027s handling of duplicate member names, fixed in 6.3.6."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-11T08:31:12.127Z",
        "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
        "shortName": "GitLab"
      },
      "references": [
        {
          "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/110"
        },
        {
          "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "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\u0027s 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."
        }
      ],
      "title": "Allocation of Resources Without Limits or Throttling in hMailServer"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a",
    "assignerShortName": "GitLab",
    "cveId": "CVE-2026-126613",
    "datePublished": "2026-11-11T08:31:12.127Z",
    "dateReserved": "2026-11-11T08:04:44.444Z",
    "dateUpdated": "2026-11-11T08:31:12.127Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted