**Confidential until the fixed release is published.** ## Summary Since 6.3.4 a new Windows installation runs the hMailServer service as the low-privilege virtual account `NT SERVICE\hMailServer`, which `/GrantServiceAccess` gives Modify on the program folder's `Logs`, `Data`, `Temp` and `Database` folders. The same `hMailServer.exe` is also the command line administrators use, and in 6.3.4 and 6.3.5 those commands - run elevated by Setup, DBSetup and the Control Panel (`/Register`, `/GrantServiceAccess`, `--apply-new-install-defaults`, `--apply-profile`, `--create-stored-secrets-key`) or from an elevated prompt (`--upgrade-database`, the stored-secrets, store and object-store commands, `--apply-environment`, `--check-database`) - wrote into those folders by path: every reported error to the error log in `Logs` (and the Application log and the `OnError` event script), the crash oracle's record and dump to `Logs`, the new installation's self-signed certificate and private key to `Data\Certificates` (deleting a file of the key's name first, and setting the key's permissions by path), and rewritten, renamed and deleted message and blob files under `Data`. A program that already runs as the service's account - through some other compromise of the service - can make a junction or a mount point of a folder it may write and so have the administrator's process create, append to, delete or change the permissions of a file of its choosing: an escalation from the service's account to the administrator's. On Linux the packages run the service as `hmailserver`, which owns the data directory and the log directory `/var/log/hmailserver`: in 6.3.4 and 6.3.5 the store commands run as root followed a symbolic link that account planted in the data folder, reading, rewriting or removing what it led to, and in every release with Linux packages, from 6.3.0, every command run as root - `--set-admin-password`, and from 6.3.4 also `--set-setting` and the stored-secrets key commands - wrote its error reports into the log directory by name, following a symbolic link planted there, so that root appended its line to, or created, a file of that account's choosing. Affected releases: on Windows, 6.3.4 and 6.3.5, in their default configuration for a new installation (an upgrade keeps LocalSystem unless the move is chosen). Releases since 6.2.0 with an administrator-chosen non-LocalSystem account that was given write access to these folders are affected the same way; the default LocalSystem service gains nothing. On Linux, 6.3.0 through 6.3.5 in their packaged configuration: the error reports from 6.3.0, the store commands in 6.3.4 and 6.3.5. Exploitation needs code already running as the service's account and an administrator who then runs one of the commands. Found in the project's own review of 6.3.6's installer fixes and the sweep after it, 3 October 2026. ## Fix (6.3.6) batch42 dda3ffcc0 made `/GrantServiceAccess` and the new `--grant-database-login` forbid the logger's writes first; batch42 1408acf3b and 4f03f9f03 do the rest. Every command line but the service's own (`RunAsService`) and the two a developer runs (`/Debug`, `/Test`) now forbids every log, Application log, event script and SQL log write of its process before anything else, arms no crash oracle, and - on Windows 11 22H2, Windows Server 2025 and later - follows no junction a non-administrator made (`ProcessRedirectionTrustPolicy`). Each command says what it did and why it failed on its own output, which Setup, DBSetup and the Control Panel keep in their logs. The certificate and its key are made through folders held open from the drive's root down, none of them a link, relative to the held `Certificates` folder, with the key's permissions given at creation and each file checked by its handle to be in that folder before a byte is written. The store commands that change the data folder hold it and list it first, and stop - naming them - when a junction, a mount point or a symbolic link is anywhere in it. `build/check-elevated-verbs.py` holds all of it, with a self-test that breaks each rule. Proven on a Windows Server 2025 bench with a junction planted in `Logs` and in `Data` against 6.3.6's previous build and the fix: the previous build wrote its error log through a junction planted in `Logs` for nine of eleven commands tried, and its installer wrote the new installation's private key and certificate through a junction planted at `Data\Certificates`; the fix wrote nothing through either, and refused the store rewrites naming the junction. On Linux no command line but the server itself writes in the log directory as root: the store commands, the object-store copies, `--sample-domain`, the profiles and `--apply-environment` run as root become the data directory's owner before they open anything, and every other command line run as root writes nothing there. Where the way to the data directory is not root's and its owner's alone they are refused. Over a data directory root owns they run on as root, writing nothing there either, only where it, the log, temporary, event and database folders, the configuration and the ways to them are root's alone, and are refused otherwise (batch42 7b95962d4). ## Until then Keep the service on LocalSystem (`hMailServer.exe --service-account localsystem /Register` from an elevated prompt), where its account is not less privileged than an administrator's. Where it must run as `NT SERVICE\hMailServer`, stop the service and check that the program folder's `Logs`, `Data` (and everything below it), `Temp` and `Database` hold no junction, mount point or symbolic link (`dir /AL /S`) before running Setup, DBSetup or any `hMailServer.exe` command. On Linux, run the store commands only as the service's account (`sudo -u hmailserver hmailserver ...`), never as root, and run any other `hmailserver` command as root (`--set-admin-password`, and from 6.3.4 `--set-setting` and the stored-secrets key commands) only with the service stopped, no process of its account running and no symbolic link in the log directory (`/var/log/hmailserver` unless `LogFolder` names another; `find /var/log/hmailserver -type l` lists one).