Incorrect Default Permissions in hMailServer
Summary
| CVE | CVE-2026-107571 |
|---|---|
| State | PUBLISHED |
| Assigner | GitLab |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-10-19 16:17:01 UTC |
| Updated | 2026-10-19 21:14:14 UTC |
| Description | 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. |
Risk And Classification
Primary CVSS: v3.1 7.8 HIGH from [email protected]
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Problem Types: CWE-276 | CWE-276 CWE-276: Incorrect Default Permissions
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 3.1 | [email protected] | Secondary | 7.8 | HIGH | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | CNA | CVSS | 7.8 | HIGH | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
CVSS v3.1 Breakdown
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Progressive Robot Ltd | HMailServer | affected 6.0.0 6.3.6 semver | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| gitlab.com/hmailserver/hmailserver/-/work_items/78 | [email protected] | gitlab.com | |
| gitlab.com/hmailserver/hmailserver/-/releases/v6.3.7 | [email protected] | gitlab.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Found in the hMailServer project's own security review (Progressive Robot Ltd) (en)
Additional Advisory Data
Solutions
CNA: Upgrade to hMailServer 6.3.7. Its hMailServer.exe /ProtectFolders, which setup runs at the end of every server installation and upgrade, gives the program folder, Bin and ControlPanel SYSTEM and the Administrators full control and Users read and execute (where every user could read the folder), nothing inherited, and, where another account owned one of them, makes the Administrators its owner and takes away that folder's own entries that let others change it; setup also gives a program folder it creates those permissions before it copies anything into it, and hardens, before its files, the existing folder of an installation of the Control Panel alone. 6.3.7 does not yet create a new program folder with those permissions already in place, harden the folder before setup's own steps on an upgrade, a repair or a server installation into a folder that already existed, refuse a link or junction on the program folder's path (it is logged), or list the files in Bin and ControlPanel by owner. Before upgrading an affected installation, or until it is upgraded, follow from an elevated Command Prompt the steps in the hMailServer documentation, ServiceAccount.md, "Before upgrading an installation at a drive's root": first note who owns the program folder and what is directly in it (dir /q /a "<folder>") and everything in Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons and Languages (dir /q /s /a); then, for the program folder, then Bin, then ControlPanel, make the Administrators its owner (icacls "<folder>" /setowner *S-1-5-32-544, the folder alone, without /T); take away every entry of the folder's own but SYSTEM's, the Administrators' and deny entries, one account a line (icacls "<folder>" /remove:g: the Users' and the service's by their SIDs, the service's only where the server is installed; the two application package groups by theirs, *S-1-15-2-1 and *S-1-15-2-2; anybody else's by the name icacls lists; and an entry icacls lists by a SID that names no account with the documentation's PowerShell line); replace what it inherits (icacls "<folder>" /inheritance:r /grant:r *S-1-5-18:(OI)(CI)F *S-1-5-32-544:(OI)(CI)F *S-1-5-32-545:(OI)(CI)RX); and on Bin and ControlPanel, where the server is installed, give the service account back its read and execute - each icacls line reporting "Successfully processed 1 files"; or move the installation under Program Files. Reinstall the programs into a new folder that only the administrators may change, not over the installation, where accounts that are not administrators could sign in while the installation was exposed, where another account made the program folder or could change it before the installation, where anybody but SYSTEM, the Administrators or TrustedInstaller owned the program folder, a file directly in it, or Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons or Languages or anything in them, or where one of the three folders had an entry of its own that let another account change it, or one the steps could not take away: setup leaves in place every file it does not ship, and puts the event script, which the service runs, and the scripts in Addons only where none is there, so read the old event script before copying it. Setup run into a folder without a settings file sets up a new, empty server there, so the settings file and the data go into the new folder first (ServiceAccount.md, "Reinstalling into a new folder"): stop the service and run nothing from the old folder, its uninstaller included; copy, not move, the mail, the built-in database's folder and the settings file into the new folder, the copies kept private; read the copy of the settings file, deleting its AdministratorPassword and each [Directories] line with a path in the old folder; then, with a 32-bit installation's uninstall entry taken away, run the release's setup with the new folder; read in the new Control Panel the programs the database's settings name, make the REST API's keys again, change each path the database holds into the old folder, and, once nothing names it, delete the old folder by hand.