Vulnerabilities

A local low privileged attacker or process can access I/O ports via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices.

A local low privileged attacker can access arbitrary physical memory or define its mapping via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices.

A local low privileged attacker can move arbitrary physical memory content via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices.

The auto-ban of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker who can connect from two or more addresses to go on guessing account passwords - over SMTP AUTH, IMAP and POP3, and over ManageSieve, CalDAV/CardDAV and the REST API where those are turned on (off by default) - without being banned. When the failed logons counted from one address reach MaxInvalidLogonAttempts (3 by default), the server clears that address's count, saves an IP range that refuses the address for AutoBanMinutes (60 by default) and drops the connection. The range is named "Auto-ban: " followed by the user name of the logon that reached the limit, and no two ranges may have the same name. The server chooses the name by checking candidates as written - the name, then the name with a number, a random suffix or a GUID added - and only then cuts it to the 100 characters the database column holds, so that with a user name of 90 characters or more every candidate is the same once cut. While one range named after such a user name stands, every later ban named after a user name with the same first 90 characters therefore fails at the database: no range is saved, the address is not refused, and, its count having already been cleared, it is given the next full set of attempts. A user name of 78 to 89 characters makes later bans fail in the same way: from the second, the third or the twelfth on, depending on its length and the database, or, from 78 to 85 characters, by chance. An attacker who has once had an address banned under such a name can in this way keep guessing passwords from any other address, ending each set of attempts with a logon under a name of that kind; each failed save is reported in the server's error log (as the database error HM5032, and from 6.2.19 also as HM6099). On SQL Server a user name holding characters outside the database's code page has the same effect at any length, because the check compared names in that code page; that save is refused by the server's own check of the name, with no database error, and is reported only from 6.2.19 (HM6099). A user name holding a NUL character, which the web services listener's HTTP Basic sign-in (off by default) carries from 6.3.3 and, on the Linux builds, IMAP LOGIN, offered as installed, from 6.3.0, makes bans fail at any length: on MySQL, MariaDB and PostgreSQL the statements that check the name and save the range end at the character, so that every ban named after such a name fails, from the first and from a single address, and, its count having already been cleared, the address is given the next full set of attempts; on SQL Server and SQL Server Compact the name is bound only as far as the character, so that while one range under the part before it stands, every later ban named after such a name fails. On SQL Server, and on MySQL and MariaDB for an account whose local part has nine characters or more, a guess at the account can itself carry a name of that kind, since those databases find an account under its address followed by spaces (and SQL Server also under one holding characters its comparison ignores), so that not even a MaxInvalidLogonAttempts of 1, which bans each failed logon under the name it gave, avoids it there.

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.

Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 on Windows hands OpenSSL the names of its own TLS files - the listeners' certificates, chains, private keys and Diffie-Hellman parameters, a port's client-certificate CA file (from 6.2.19), the object store's CA file (from 6.3.4) and the ACME client's keys and certificates - as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF, and OpenSSL's file opening on Windows reads a name as UTF-8 first and opens the file at that reading when it is there, or creates it there when its folder is. When every byte of a configured name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9, which are U+00E9 in UTF-8 - the server used the file at that other name whenever one was there, which allows a local attacker who can create that file or its folder but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, to have a port that logs on by client certificate (from 6.2.25) accept certificates from a certificate authority of the attacker's own and so sign in over the network as any mailbox without its password; to have the server trust such an authority for its object store and, intercepting that connection, read and modify the messages it stores; to receive the private keys the ACME client writes, the key of a certificate issued for the server's names among them; or to keep TLS ports from starting. The configuration is not the default: by default these files have names in ASCII, client certificates are off on every port, and the object store and ACME are off. The Linux builds are not affected.

Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.3.7 allow a local authenticated user to run code as the administrator who runs setup, when the server is installed into a program folder that is already there and that accounts other than the administrators could write, such as a folder made beforehand at the root of a drive, or when such an installation is upgraded or repaired. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but for a folder that is already there it does so only at the end of setup: setup first copies the programs into Bin, which every user may still write, and runs programs from Bin with the administrator's elevated rights, registering the service among them, before that hardening, so that a library another account places in Bin meanwhile is loaded in place of the system's. A handle an account opened on such a folder while it could write it keeps that access after the hardening. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected.

Inefficient algorithmic complexity in the JSON reader of Progressive Robot hMailServer 6.3.6 and 6.3.7 allows a remote attacker to hold the server's mail delivery threads or its REST API's worker threads, making mail delivery, the REST API and the webmail unavailable. 6.3.6 fixed CVE-2026-107574, in which reading a JSON object searched the member names already read for each new name, by keeping the names in a hash set; the set uses the standard library's hash, which takes no secret, so member names chosen to fall in one bucket of it still cost time growing with the square of their number. Against the released reader, one such object of 16 MB took about 5 seconds to read in the Linux build, and one of under 6 MB about 23 seconds in the Windows build, where objects of the same sizes with other names took under a tenth of a second. A remote unauthenticated attacker reaches the reader by mailing such an object as a TLS-RPT report, up to 16 MB once decompressed, to a hosted domain's report mailbox, where an administrator has set one; it is read on a mail delivery thread (ten by default), and those threads deliver all mail, local and outbound, so a stream of such reports stops all delivery for as long as it continues. It is also reached without an account through the reply to a password-protected message, with the message's link alone, where the REST API is on (it is off by default) and a public base URL for such links is set; and by any account through the webmail's routes granted 16 MB, and by an application's API key through the send API. Each such request holds one of the REST API's four worker threads, in the process that also serves SMTP, IMAP and POP3.

Unverified ownership in the Windows installer of Progressive Robot hMailServer 6.3.7 allows a local authenticated user to run code as the mail server's service account or as an administrator when setup installs into, or upgrades, a program folder that accounts other than the administrators could write before, such as one made beforehand at the root of a drive. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but setup refused nothing that was already in them, or in the folders that hold the event script, the add-ons and the database scripts: a program, a library, a script or a settings file that another account owns, or whose own permissions let another account change it, is kept with that owner and those permissions, which the hardening of the folders does not take away. Setup then runs programs from Bin with the administrator's elevated rights, and the service, which runs as LocalSystem or as its virtual account, runs them and the event script, so that a library such an account placed in Bin is loaded in place of the system's; the account can still change the file after the installation. The default installation under Program Files is not affected.

Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.3.7 allow a local authenticated user to run code as the administrator who installs the product, when it is installed into a new program folder in a location whose permissions let every user write, such as the root of a drive. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but its setup lets Inno Setup make a new program folder first, with the permissions the folder above hands down, and replaces them only afterwards, tens of milliseconds later (33 to 139 milliseconds in the project's test runs). In that time any local account may make files and folders in the new folder, which keep that account as their owner, among them the Bin folder that setup then copies the programs into. Setup runs programs from Bin with the administrator's elevated rights, registering the service among them, before its hardening at the end of setup takes such a folder back, and those programs load a library placed in Bin in place of the system's. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected.

The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 counts every failed CardDAV, CalDAV or Autodiscover sign-in from a proxy it trusts - one on the same machine, or one named in WebServicesTrustedProxies, whose X-Forwarded-Proto it believes - against the proxy's own address, which allows a remote unauthenticated attacker who can reach the proxy to have that address banned from the server's mail listeners. The listener, off by default (WebServicesHttpPort and WebServicesHttpsPort 0), signs an account in with HTTP Basic over HTTPS for CardDAV from 6.3.3 and for CalDAV and Outlook Autodiscover from 6.3.4. Behind a TLS-terminating proxy, which the server trusts when it is on the same machine or named in WebServicesTrustedProxies, the listener takes the client's HTTPS from the proxy's X-Forwarded-Proto header, but it does not believe X-Forwarded-For and sees the proxy's address for every client. Each failed sign-in counted towards the auto-ban against that address, so that failed sign-ins through the proxy from anybody, under any user name, reaching MaxInvalidLogonAttempts (3 within 30 minutes by default) wrote an IP range that refused the proxy's address at the SMTP, POP3, IMAP and ManageSieve listeners for AutoBanMinutes (60 by default), and could write it again each time it lapsed. For a proxy on the same machine that address is the loopback address, so that a webmail on that machine, local scripts that submit mail and the other local clients of the mail listeners were shut out; for a proxy at another address that also carries mail, every mail client behind it was. Such a proxy forwarding to the listener's HTTPS port, re-encrypting, was counted against in the same way, and listing it in WebServicesTrustedProxies did not spare it. The auto-ban is on by default and AutoBanNeverBan, which spares an address, is empty by default; the listener itself went on serving the proxy.

Improper link resolution in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.7 allows a local authenticated user to run code as the mail server's service account or as an administrator when the path to the program folder passes through a junction, a symbolic link or a mount point that the user controls or that every user may change, such as a junction made at the root of a drive, which takes the root's permissions, or through a folder that every user may rename. Setup installed the programs through any such link without first checking who controls it, or whether a folder above the program folder may be renamed, and the service is registered to run the programs by that path, so the programs are installed where a link another account controls leads, or that account can later make the path lead to a folder it controls; the service, which runs as LocalSystem or as its virtual account, and the programs administrators run from Bin are then started from there. 6.3.7's fix for CVE-2026-107571 does not cover this: its hardening of the program folder, Bin and ControlPanel does not change a folder reached through a link that the administrators do not alone control, and setup does not refuse such a path: it installs through the link and at most reports afterwards that the folders could not be hardened. The default installation under Program Files is not affected.