Progressive Robot hMailServer up to 6.3.7 Database Layer sql injection

Summaryinfo

A vulnerability was found in Progressive Robot hMailServer up to 6.3.7. It has been rated as critical. Impacted is an unknown function of the component Database Layer. This manipulation causes sql injection. This vulnerability is registered as CVE-2026-126619. Remote exploitation of the attack is possible. No exploit is available.

Detailsinfo

A vulnerability was found in Progressive Robot hMailServer up to 6.3.7. It has been declared as critical. Affected by this vulnerability is an unknown function of the component Database Layer. The manipulation with an unknown input leads to a sql injection vulnerability. The CWE definition for the vulnerability is CWE-89. The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at gitlab.com. This vulnerability is known as CVE-2026-126619 since 11/11/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. The technical details are unknown and an exploit is not publicly available. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 11/11/2026). The attack technique deployed by this issue is T1505 according to MITRE ATT&CK.

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Mail Server Software

Vendor

• Progressive Robot

Name

• hMailServer

Version

• 6.3.0
• 6.3.1
• 6.3.2
• 6.3.3
• 6.3.4
• 6.3.5
• 6.3.6
• 6.3.7

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion