High · CVSS 7.3CVE-2026-126624

Unverified Ownership in hMailServerCVE-2026-126624

Answer in brief

CVE-2026-126624 records a High severity (CVSS 7.3) vulnerability in Unverified Ownership 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 Nov 11, 2026Updated Nov 11, 2026Source checked Nov 11, 2026First seen by HOL Nov 11, 2026Material review Nov 11, 2026

Upstream Advisory

Key facts

Risk: High · CVSS 7.3
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.3. 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.3.7	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.8, whose setup looks, before it stops the service and again once the folders are hardened, at everything in Bin and ControlPanel, on the program folder's own level, and in Addons, Events, DBScripts, WebAdmin, Languages and MySQL, and refuses with exit code 7 to install where a program, a library, a script, a settings file or a folder there is owned by anybody but SYSTEM, the Administrators or TrustedInstaller, has an owner that cannot be read, or has an entry of its own that lets another account change it, naming each with the icacls that deals with it and a restart of Windows before setup runs again. Until then, install hMailServer under Program Files, or into a new folder inside one that only administrators may change. Before running setup into or over a program folder that other accounts could write, list the owners from an elevated Command Prompt - dir /q /a "<program folder>" and dir /q /s /a over its Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons, Languages and MySQL, as the hMailServer documentation, ServiceAccount.md, "Before upgrading an installation at a drive's root", gives them for all but MySQL - and the entries of their own, with icacls "<program folder>" and icacls "<folder>" /T over the same folders, where an entry not marked (I) that gives anybody but SYSTEM, the Administrators or TrustedInstaller a right to change the item is another account's (the service's own Modify on hMailServerApiKeys.ini in Bin apart); where anybody but those owns anything there, or has such an entry, do not install over it: reinstall into a new folder as that page's "Reinstalling into a new folder" says.

Evidence timeline and material changes

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

Sources and claim methodology

Upstream source description

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.

Quoted source text, attributed separately from HOL analysis.

Package

Affected range

Fixed version

Progressive Robot Ltd/hMailServergeneric

6.3.7

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.8, whose setup looks, before it stops the service and again once the folders are hardened, at everything in Bin and ControlPanel, on the program folder's own level, and in Addons, Events, DBScripts, WebAdmin, Languages and MySQL, and refuses with exit code 7 to install where a program, a library, a script, a settings file or a folder there is owned by anybody but SYSTEM, the Administrators or TrustedInstaller, has an owner that cannot be read, or has an entry of its own that lets another account change it, naming each with the icacls that deals with it and a restart of Windows before setup runs again. Until then, install hMailServer under Program Files, or into a new folder inside one that only administrators may change. Before running setup into or over a program folder that other accounts could write, list the owners from an elevated Command Prompt - dir /q /a "<program folder>" and dir /q /s /a over its Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons, Languages and MySQL, as the hMailServer documentation, ServiceAccount.md, "Before upgrading an installation at a drive's root", gives them for all but MySQL - and the entries of their own, with icacls "<program folder>" and icacls "<folder>" /T over the same folders, where an entry not marked (I) that gives anybody but SYSTEM, the Administrators or TrustedInstaller a right to change the item is another account's (the service's own Modify on hMailServerApiKeys.ini in Bin apart); where anybody but those owns anything there, or has such an entry, do not install over it: reinstall into a new folder as that page's "Reinstalling into a new folder" says.

Sources and claim methodology

Upstream source description

Quoted source text, attributed separately from HOL analysis.

Unverified Ownership in hMailServerCVE-2026-126624

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

Related CVEs

Unverified Ownership in hMailServerCVE-2026-126624

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

Related CVEs