# CVE-2026-126619: Misinterpretation of Input in hMailServer

Status: published. Published: 2026-11-11. Updated: 2026-11-11.

Misinterpretation of SQL statement text in the database layer of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 allows a remote unauthenticated attacker to have a failed database write reported to the server as successful. The layer answers a failed statement as a success when it finds the marker [IGNORE-ERRORS], which is meant only for the server's own schema statements (its upgrade scripts and the database log's tables), and statements carry values from outside - an envelope address, the user name of a failed logon, a message's headers - in their text on MySQL/MariaDB and PostgreSQL, and in the batches of the database log on every engine. Up to 6.2.18 the marker was honoured anywhere in a statement, a value included, on MySQL/MariaDB and PostgreSQL. From 6.2.19 it was honoured only inside a comment, but the layer read a backslash inside a string literal as an escape, which SQL Server, SQL Server Compact and PostgreSQL with standard_conforming_strings on (its default) do not, so that on those engines a value holding a backslash could make the layer take part of the statement's literals for statement text and find the marker there: on PostgreSQL from 6.3.3 for every statement carrying an outside value that holds a backslash, with no setting changed for a message delivered into a local mailbox (through an internationalised (SMTPUTF8) envelope sender) and for the IP range an auto-ban writes (named after the user name of the failed logon), and on SQL Server and SQL Server Compact for the database log, when the server logs to the database (logging is off, and the log device is files, by default). A statement run outside a transaction that then failed - a constraint, a deadlock, a lock or statement timeout, a full disk, and up to 6.2.18 a lost connection - was answered as a success, and its caller went on as if the row had been written: a message delivered into a local mailbox could be counted as delivered with no row to show it and no failure notice to its sender, and a message accepted with 250 could be left with no queue row and never delivered (up to 6.2.18, and on PostgreSQL from 6.3.3 when every recipient's address carries the marker too, which needs an address that takes any local part); an auto-ban whose IP range was not written could be logged and counted as applied, with no error reported, while the address stayed unbanned; and message metadata (written only when message indexing is on), entries of the database log and rows of features an administrator turns on could be lost without an error. On MySQL/MariaDB up to 6.2.18 the caller was handed whatever identifier the client library still held for the connection - 0, or that of an insert its last successful statement made, in whatever table - under which a queued message's recipients were then written, so that another message still in the queue could be delivered to them as well. This flaw gives a value no way to change what a statement does, and no privilege is gained.

## Remediation

- fix: Upgrade to hMailServer 6.3.8, which reads each string literal as the database engine reads it - a backslash as an escape only on MySQL/MariaDB, on PostgreSQL with standard_conforming_strings off and in PostgreSQL's E'...' strings - when it looks for the marker, so that no value can reach the comment where the marker is honoured, and which reads literals the same way when it masks them in the slow-query log line and the trace. Until then, on SQL Server and SQL Server Compact keep logging off or the log device on files (the defaults); on PostgreSQL 6.3.3 to 6.3.7, and on MySQL/MariaDB and PostgreSQL before 6.2.19, no setting of the server avoids it. (source: CNA: GitLab)

## Affected products and versions

- Progressive Robot Ltd / hMailServer: ≥ 6.0.0-B1; ≤ 6.3.7 (affected, semver). Source: CNA: GitLab

## Severity and prioritization

- CVSS 3.1: 4.8 (medium); CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N; source: CNA: GitLab

- CISA KEV: No listing in collected sources

- EPSS: Not available

- SSVC: Not available

- Weaknesses: CWE-115

## Exploit evidence

No exploit evidence in collected sources. This is not proof of no exploitation.

## References

- https://gitlab.com/hmailserver/hmailserver/-/work_items/100 (CNA: GitLab)

- https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 (CNA: GitLab)

## Provenance

- CNA: GitLab: https://www.cve.org/CVERecord?id=CVE-2026-126619; retrieved 2026-11-11; source updated 2026-11-11

Revision: fcdf63dc99a6a84e1c1934140670d3890cdb67f27553bc957d9419a9ff155b2f

Canonical: https://y2.dev/cve/CVE-2026-126619

## Agent and API access

Public CVE pages, Markdown, and JSON are free to read without an account or API key.

- Public catalog: https://y2.dev/cve/index.json. Follow nextCursor with the same search, filters, sort, and limit (1–100). A null cursor marks the end.

- WebMCP: search_cve_disclosures, get_cve_disclosure, get_cve_page_markdown, get_y2_cve_access. Available in compatible browsers.

- Cyber API: https://api.y2.dev/api/v2/cyber/cves and https://api.y2.dev/api/v2/cyber/cves/{cveId}.

- Y2 Pro or Elite: create a workspace API key with the intel:cyber scope and send Authorization: Bearer <Y2_API_KEY>. Setup: https://y2.dev/docs/api/create-key.

- x402: Pay per request without an account or API key. Omit Authorization, read the HTTP 402 PAYMENT-REQUIRED challenge, validate its current requirements, and retry with PAYMENT-SIGNATURE through an authorized payment client. These browser tools never make payments. Guide: https://y2.dev/docs/api/x402.

- OpenAPI: https://y2.dev/api/openapi.yaml. Agent access metadata: https://y2.dev/cve/agent.json.

Collected public records only. Check source status for coverage and freshness.