Skip to main content

CVE-2026-126615Progressive Robot Ltd hMailServer vulnerability

Low priorityMedium5.3EPSS not scored yet

CVE-2026-126615 is a vulnerability in Progressive Robot Ltd hMailServer, rated medium (5.3 on CVSS 3.1).

Why this priority: Medium severity, with no exploitation signal.

Published · Updated · NVD status: Received

What it is

The record does not classify the weakness yet; the description below says what the reporter found.

How it is reached

An attacker can exploit it over the network, without an account, and nobody has to click anything.

What an attacker gains

The direct impact is limited: partial access to data or a partial outage.

Is it being exploited?

There is no public report of exploitation yet.

What to do

  1. 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.
  2. While there is no fix, keep it off the internet or behind a VPN, allowlist or authenticating proxy.

Description from NVD

The sign-in of Progressive Robot hMailServer 6.2.22-pre2 through 6.3.7 takes for an account names that are not its address but under which the database's own comparison finds it, while the per-name lockout and the compromised-account hold are kept by the name as the client gave it. This allows a remote unauthenticated attacker to go on guessing an account's password beyond the lockout's threshold, and anyone who has the password of an account held for review to sign in to it. The per-name lockout (from 6.2.22-pre2; AccountLockoutThreshold in hMailServer.ini, 0, off, by default) locks a name after repeated failed sign-ins. The hold (from 6.3.4, where the compromised-account detection is set to enforce, which is not the default) refuses an account judged to have been taken over. Both are asked, before the password, of the name the client gave: trimmed, in lower case and with a domain alias or the default domain applied. The account whose password the sign-in then checks is whichever one the database finds under that name. The databases find an account under spellings that this key counts apart. MySQL and MariaDB find it under one with accented letters in place of plain ones, and MariaDB 11.8, in a database made before 6.3.4, also under one with full-width letters, with a single letter in place of a pair of plain ones, or with characters its comparison ignores in any number. SQL Server and SQL Server Compact find it under one with full-width letters or with characters their comparison ignores in any number, and SQL Server also under one with a single letter in place of a pair of plain ones, with a character of Latin-1 in place of a digit and, for an address holding letters of Latin-1 outside ASCII, under those letters in the other case, and, under an accent-insensitive collation, with accented letters. PostgreSQL finds it under one holding a letter whose lower case under the database's locale is a plain letter, and, for an address holding letters outside ASCII, under those letters in the other case; on the build for musl (from 6.3.6) the server's own lower case folds nearly all of these too. On every database, a domain alias saved with white space at the end of its name gives such a spelling too, and on every database but PostgreSQL so does an account's bare local part where the default domain was saved with spaces at its end and no other white space (neither is the default). Each such spelling has a lockout threshold of its own, so the lockout limits the guesses at an account only to its threshold times the number of the account's spellings. That is far beyond any threshold for most addresses on MySQL and MariaDB, and without limit on SQL Server, on SQL Server Compact, the database the Windows installer uses by default, and before 6.3.4 on MariaDB 11.8. A locked name is got round under another spelling. A held account is signed in to under another spelling with its password over IMAP, POP3 and SMTP AUTH, and, where they are turned on (off by default), over ManageSieve, the REST API and the webmail. IMAP LOGIN, offered as installed, carries such spellings on MySQL, MariaDB and SQL Server Compact, and, on SQL Server and PostgreSQL, for some addresses; the sign-ins that carry a name as UTF-8 carry them for the others on SQL Server, and on PostgreSQL for those holding one of the plain letters another letter lowers to or a letter outside ASCII with another case. The same lookup mapped to accounts the names given by an OAuth 2.0 token, a client certificate, a Kerberos ticket and an OpenID Connect or SAML identity provider, where those are set up (none is by default), so that a name an issuer gave to one party could sign in to another's account; OAuth 2.0 tokens were mapped so from 6.2.0, before the per-name lockout existed. A name holding a NUL character, carried from 6.3.0 on Linux and 6.3.3 on Windows, failed the statement on MySQL, MariaDB and PostgreSQL.

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

  • Progressive Robot Ltd hMailServer. Start from where it runs and what it is connected to.

Trust boundaries in play

  • Internet-facing entry points. No account is needed. Any instance reachable from outside your perimeter, through a load balancer, gateway, VPN or exposed admin port, is in scope.

Questions to answer about your own systems

  • Where does Progressive Robot Ltd hMailServer run in your systems, and at which version?
  • Which of those instances can be reached from the internet or partner networks?
  • 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.