Description
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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Progressive Robot Ltd | hMailServer | unaffected |
|
No data.
No data.
No data available yet.
Remediation
Vendor Solution
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.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Wed, 11 Nov 2026 08:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Misinterpretation of Input in hMailServer | |
| Weaknesses | CWE-115 | |
| References |
| |
| Metrics |
cvssV3_1
|
Subscriptions
No data.
MITRE
Status: PUBLISHED
Assigner: GitLab
Published:
Updated: 2026-11-11T08:33:47.151Z
Reserved: 2026-11-11T08:05:14.382Z
Link: CVE-2026-126619
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-11-11T09:17:14.133
Modified: 2026-11-11T09:17:14.133
Link: CVE-2026-126619
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses
-
CWE-115
Misinterpretation of Input