CVE-2026-107571: Incorrect Default Permissions in hMailServer
Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.6 allow a local authenticated user to run code as the mail server's high-privileged accounts when the product is installed in a folder whose permissions are inherited from a writable parent, such as the root of a drive. The installer places the server's programs in the Bin folder of the program folder and gives neither the program folder nor Bin any permissions of their own, so they inherit the parent's. Under the default location, Program Files, ordinary users receive only read and execute and the configuration is not affected; but the installer accepts any path without warning, and a program folder at the root of an NTFS volume inherits write access for a broad group - Authenticated Users (Modify) on a Windows client, Users (create files and folders) on Windows Server. A local user without administrator rights can then alter or replace the service program, which runs as LocalSystem or as the service's virtual account, or the programs an administrator runs elevated from Bin during setup and maintenance, or place a library in Bin that those programs load in place of the system copy, gaining code execution with those privileges. The default Program Files installation is not affected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.7 - Configuration
Before upgrading, use an elevated Command Prompt to harden the program folder, Bin, and ControlPanel as documented: set Administrators as owner, remove unauthorized and inherited entries, remove inheritance, grant SYSTEM and Administrators full control and Users read/execute, and restore the service account's read/execute permission on Bin and ControlPanel. Alternatively, move the installation under Program Files.
hMailServer program folder, Bin, and ControlPanel Windows folder ownership and ACLs = Administrators owner; SYSTEM and Administrators full control; Users read and execute; inheritance removed; service account read and execute on Bin and ControlPanel - Operational
For an installation exposed to non-administrators or otherwise failing the documented ownership/ACL checks, reinstall into a new folder that only administrators can modify. Stop the service, run nothing from the old folder, copy the mail, built-in database folder, and settings file to the new folder, remove AdministratorPassword and [Directories] paths referencing the old folder from the copied settings, run the release setup in the new folder, recreate REST API keys, update database-held paths, and delete the old folder once nothing references it.
Event History
Frequently Asked Questions
Are installations using the default location affected?
No. When installed under Program Files, ordinary users have only read and execute permissions, so the vulnerable inherited write access is not present.
What conditions must exist for exploitation?
The product must be installed in a location that inherits permissions from a writable parent, such as the root of an NTFS volume. An authenticated local user without administrator rights must be able to modify files in the program folder or its Bin subfolder.
How can I determine whether an existing installation is exposed?
Check the hMailServer program folder and its Bin folder for inherited permissions. An installation at the root of a drive may grant Authenticated Users Modify on Windows client systems, or allow Users to create files and folders on Windows Server, making it exposed.
What could an attacker achieve with write access to Bin?
A local user could alter or replace a service program that runs as LocalSystem or the service virtual account. They could also tamper with programs run elevated by an administrator during setup or maintenance, or place a library in Bin that those programs load.