CVE-2026-104660: Missing Authorization in hMailServer
Missing authorization on COM objects in Progressive Robot hMailServer 6.0.0 through 6.3.5 (Windows only) lets a local interactive user with no hMailServer credential read and write arbitrary files as the service account and queue mail as any sender. The service registers its COM classes with no DCOM access or launch permission and calls CoInitializeSecurity with no security descriptor, so any user logged on at the console or over Remote Desktop can activate the classes in the running service; a hMailServer.Message, its Attachments and Attachment, and a hMailServer.FetchAccount created this way carry a credential that never authenticated. Attachments.Add(path) and Attachment.SaveAs(path) performed no authorization check, and Message.Save/Copy and FetchAccount.AccountID/Save performed none either up to 6.3.3 and from 6.3.4 treated a holder with no credential as the server's own event-script host. Because the service does not impersonate the COM caller, Attachments.Add reads any file the service account can read and returns it, Attachment.SaveAs writes attacker-chosen bytes to any path it can write (on a LocalSystem installation, code execution as SYSTEM), Message.Save queues outbound mail from any address past the SMTP checks, and FetchAccount attaches a mail-fetch job to any mailbox. The objects an Application handed out behave the same once a later Authenticate on that Application fails.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
hMailServerto a version that resolves this vulnerability.Fixed in 6.3.6 - Configuration
Restrict the DCOM AppID launch and access permissions to exclude INTERACTIVE users.
hMailServer DCOM AppID launch/access permission = Exclude INTERACTIVE - Compensating control
Do not allow untrusted users to log on interactively, including through the console or Remote Desktop, to the hMailServer host.
Event History
Frequently Asked Questions
Which systems are realistically exposed?
Only Windows installations of hMailServer 6.0.0 through 6.3.5 are affected. Exploitation requires a user who can log on interactively at the console or through Remote Desktop.
Does an attacker need hMailServer credentials?
No. A local interactive user can activate the service COM classes without hMailServer credentials because the COM configuration does not require DCOM access or launch permission.
What privileges could exploitation provide?
The attacker can read files readable by the hMailServer service account, write attacker-controlled data to locations writable by that account, and queue mail using arbitrary senders. If the service runs as LocalSystem, the arbitrary file-write capability can lead to code execution as SYSTEM.
Are installations running 6.3.4 or 6.3.5 protected by the credential changes?
No. The issue affects versions through 6.3.5; from 6.3.4, an unauthenticated holder is treated as the server's event-script host rather than being denied.