High · CVSS 7.8CVE-2026-107571

Incorrect Default Permissions in hMailServerCVE-2026-107571

Answer in brief

CVE-2026-107571 records a High severity (CVSS 7.8) vulnerability in Incorrect Default Permissions in hMailServer. The current sources do not mark it as known exploited. The current feed maps Progressive Robot Ltd/hMailServer (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Oct 19, 2026Updated Oct 19, 2026Source checked Oct 19, 2026First seen by HOL Oct 19, 2026Material review Oct 19, 2026

Upstream Advisory

Key facts

Risk: High · CVSS 7.8
Exploitation: Not marked as known exploited
Affected software: 1 mapped package or product
Fix availability: Not reported

Why this deserves its current priority

CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Progressive Robot Ltd/hMailServer (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Progressive Robot Ltd/hMailServergeneric	>=6.0.0 <=6.3.6	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Progressive Robot Ltd/hMailServer.
Review the reported fix. Source-reported 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.

Evidence timeline and material changes

Published upstream
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Oct 19, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Oct 19, 2026

Sources and claim methodology

Upstream source 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.

Quoted source text, attributed separately from HOL analysis.

Package

Affected range

Fixed version

Progressive Robot Ltd/hMailServergeneric

>=6.0.0 <=6.3.6

Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Progressive Robot Ltd/hMailServer.

Review the reported fix. Source-reported 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.

Sources and claim methodology

Upstream source description

Quoted source text, attributed separately from HOL analysis.