CVE-2026-126607Progressive Robot Ltd hMailServer uncontrolled search path
CVE-2026-126607 is a uncontrolled search path in Progressive Robot Ltd hMailServer, rated high (7.8 on CVSS 3.1).
Why this priority: High severity, with no exploitation signal yet.
Published · Updated · NVD status: Received
What it is
The software loads libraries or programs from a location an attacker can write to.
How it is reached
An attacker can exploit it by someone who can already run code or sign in on the machine, with an ordinary user account, and nobody has to click anything.
What an attacker gains
A successful attack can read the data it protects, change data or behaviour and take it offline. In practice, this kind of flaw lets an attacker run their code inside your build or your running service.
Is it being exploited?
There is no public report of exploitation yet.
What to do
- No fixed version is listed yet. Find every place Progressive Robot Ltd hMailServer runs, watch the references for a fix, and plan a replacement if it is no longer supported.
- Limit who can run code or sign in on the hosts that run it.
Description from NVD
Progressive Robot hMailServer 6.2.3 through 6.3.7 on Windows, with a MySQL or MariaDB database, hands the bundled MariaDB Connector/C the folder of its authentication plugins (the plugin folder in the installation's Bin folder) as Latin-1 bytes, which the client reads in the system's ANSI code page when it builds a plugin's path and loads the plugin with LoadLibraryExA, which allows a local authenticated user to execute code as the hMailServer service's account (LocalSystem, or the service's virtual account for a new installation from 6.3.4) by creating the folder those bytes name in the code page and placing in it a DLL with a plugin's name, when the installation folder's path holds a character between U+0080 and U+00FF whose byte the code page reads as another character, and none above U+00FF, and the user can create that other folder (by default any authenticated user may create a folder directly under the root of the system drive). The server converted the path with the C runtime's wcstombs_s in the C locale, which writes each character up to U+00FF as the byte of the same value: on code page 1252 those bytes are the same letters, while on another code page, such as 1251, or on a UTF-8 code page, they name another folder. The client loads the plugin the database server names in its greeting, unless it is built in, and any plugin the server names in an authentication switch, and tries again at each connection while a load fails, so with a MySQL 8.0 or later server, whose greeting names caching_sha2_password by default, the DLL is loaded at the next connection the service makes, whatever plugin the database account uses; a DLL's entry point runs when it is loaded. A path holding any character above U+00FF was handed over as an empty string, whatever the code page, from which the client makes a plugin's name at the root of the current drive: for the service, whose current folder is System32, that is the root of the system drive, where by default only administrators can create a file, but the server's own database commands (hMailServer.exe --check-database, --upgrade-database and the others from 6.3.4, and the /Debug and /Test console modes from 6.2.3) run in the folder they are started from - the product tells administrators to run them from an elevated prompt in the Bin folder, and the setup of 6.3.4 and 6.3.5 ran two or three of them itself with the Bin folder as their working folder for a new installation with an external database - so a DLL that a local authenticated user placed under a plugin's name at the root of a drive other users may write, such as a FAT or exFAT volume, was loaded into the administrator's process at the command's first connection to a MySQL 8.0 or later server. 6.3.8 fixes both cases: it hands the folder in the code page's bytes or by its short (8.3) name, and where neither can be written, a folder under the Windows system folder that holds no plugin and that only administrators can create, or else refuses the connection before attempting it; it never hands the empty value or a folder the current drive completes. The configuration is not the default: the default installation folder, under Program Files, is ASCII. Linux builds set no plugin folder and are not affected.
What this means for your architecture.
A CVE names a product. Whether it matters depends on where that product sits in your systems: what reaches it, which trust boundary it guards and what it can reach once compromised. Veriom maps your components, their relationships and your trust boundaries from your code, cloud and delivery evidence, so you can see where a component like this sits. The radar itself does not look at your systems.
Components it touches
- Build pipelines, dependencies and plugins. The flaw sits between third-party code and your build or runtime.
- Update channels. The flaw sits between third-party code and your build or runtime.
Trust boundaries in play
- Host boundary. The attacker needs a foothold on the machine first; the flaw turns a small foothold into a bigger one.
- Between third-party code and your build or runtime. An attacker who crosses it can run their code inside your build or your running service.
Questions to answer about your own systems
- Where does Progressive Robot Ltd hMailServer run in your systems, and at which version?
- Which of those hosts also run code or users you do not fully trust?
- What can it reach once compromised: which data stores, secrets and services?
Sources
- CVE records and CVSS scores from the NVD CVE API. This product uses the NVD API but is not endorsed or certified by the NVD.
- Exploitation status from CISA’s Known Exploited Vulnerabilities catalog.
- Exploit likelihood from FIRST’s Exploit Prediction Scoring System (EPSS), refreshed daily.
- Explanations are written by Veriom from fixed templates over each record’s data, not by a person reviewing each CVE. Descriptions are quoted from the records as published.