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.
Published: 2026-10-19
Score: 7.8 High
EPSS: n/a
KEV: No
Impact: Local Privilege Escalation through insecure installer permissions
Action: Immediate Patch
AI Analysis

Impact

The vulnerability arises from the Windows installer for hMailServer versions 6.0.0 through 6.3.6, which creates the program folder and its Bin subfolder without explicit ACLs, allowing the folders to inherit permissions from their parent. If the installation path is a writable location such as a drive root, ordinary users obtain write access to the Bin folder and can replace or modify executable files that run under high‑privilege service accounts. This enables a local authenticated attacker to execute arbitrary code with the permissions of LocalSystem or the mail server service, compromising confidentiality, integrity, and availability of the server and potentially the underlying host. The weakness is an example of improper permission assignment (CWE‑276).

Affected Systems

Progressive Robot Ltd. hMailServer, versions 6.0.0 to 6.3.6, when installed in a non‑default folder that inherits permissive parent permissions, such as the root of a drive. The default installation path of Program Files is not affected.

Risk and Exploitability

The CVSS score is 7.8, reflecting high severity. EPSS data are not available, but there is no record of exploitation in the KEV catalog, indicating that the threat is known but not yet widely abused. The likely attack vector is local and authenticated; any user who can write to the chosen installation folder can trigger the elevation. The absence of hardened permissions during install is the core exploitability factor.

Generated by OpenCVE AI on October 19, 2026 at 16:20 UTC.

Remediation

Vendor Solution

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.

OpenCVE Recommended Actions

  • Apply the 6.3.7 upgrade as soon as possible. The new release omits the insecure program‑folder creation, does not harden new folders after setup, and refuses to allow a junction or link to the program folder path. It also logs the actions, aiding audit.
  • If an upgrade is not immediately feasible, run the manual remediation steps documented in the hMailServer ServiceAccount.md. From an elevated command prompt, identify the current permissions on the program folder and its subfolders, change the owner to Administrators, remove all unnecessary entries (Users, service accounts, and custom SIDs), and set inherited permissions to SYSTEM, Administrators, and Users (read/execute).
  • Alternatively, reinstall hMailServer into a dedicated folder under Program Files or another location with restricted parent permissions. During reinstall, ensure that the installer runs with elevated privileges, the service’s virtual account or LocalSystem is the sole owner of the Bin folder, and no write access is granted to ordinary users.

Generated by OpenCVE AI on October 19, 2026 at 16:20 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 19 Oct 2026 15:45:00 +0000

Type Values Removed Values Added
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.
Title Incorrect Default Permissions in hMailServer
Weaknesses CWE-276
References
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitLab

Published:

Updated: 2026-10-19T15:34:47.493Z

Reserved: 2026-10-08T10:51:20.640Z

Link: CVE-2026-107571

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-19T16:17:01.970

Modified: 2026-10-19T16:17:01.970

Link: CVE-2026-107571

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-19T16:30:13Z

Weaknesses
  • CWE-276

    Incorrect Default Permissions