CVE-2026-104660 in hMailServer
Summary
by MITRE • 10/08/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability in hMailServer versions 6.0.0 through 6.3.5 represents a critical failure in component object model security configuration, specifically involving missing authorization checks for COM objects exposed by the mail server service. This flaw allows any local interactive user with no prior credentials to interact directly with internal service components as if they were authenticated administrators or system-level entities. The root cause lies in how the hMailServer service registers its COM classes and initializes its security context. By registering COM classes without setting appropriate DCOM access or launch permissions, the service inadvertently exposes these interfaces to all local users. Furthermore, the invocation of CoInitializeSecurity with no specific security descriptor means that default Windows security policies apply, which typically permit broad interaction capabilities for authenticated local users on the console or via Remote Desktop sessions. This configuration error effectively bypasses the intended authentication boundaries of the application, allowing unauthenticated actors to instantiate critical server-side objects.
Once a user successfully activates these COM classes, they obtain instances of hMailServer.Message, its associated Attachments and Attachment objects, as well as FetchAccount objects that carry credentials which have never been validated by the mail server's internal authentication mechanisms. The operational impact is severe because subsequent method calls on these objects perform no authorization checks to verify if the caller has permission to execute them. For instance, calling Add on an Attachments object allows the attacker to read any file accessible to the service account and attach it to a message, leading to arbitrary data exfiltration. Similarly, invoking SaveAs on an Attachment object enables writing arbitrary bytes to any file path that the service account possesses write permissions for. In environments where hMailServer runs under the LocalSystem account, this capability translates directly into remote code execution with SYSTEM-level privileges, as the attacker can overwrite critical system files or execute malicious scripts through supported attachment formats.
Beyond data theft and potential code execution, the vulnerability facilitates significant abuse of mail services. The Message.Save and Copy methods allow an unauthenticated user to queue outbound email messages that appear to originate from any sender address, effectively bypassing SMTP authentication checks designed to prevent spoofing. This can be leveraged for phishing campaigns or spam distribution while masking the true originator. Additionally, the FetchAccount object allows attackers to attach mail-fetch jobs to any mailbox on the server, potentially leading to unauthorized access to email contents stored within those accounts. A particularly insidious aspect of this flaw is that even if an attacker later attempts to authenticate using a valid Application interface but fails, the previously created objects retain their elevated privileges and continue to function as if they were authenticated by the server's event-script host logic in versions 6.3.4 and above, or simply operate without checks in earlier versions up to 6.3.3.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to properly verify identity before granting access to resources. It also relates closely to CWE-915 Improper Control of Dynamically-Identified Variables, where objects are instantiated and manipulated without proper validation of their state or permissions. In terms of attack vectors, this falls under MITRE ATT&CK technique T1021 Remote Services, specifically leveraging COM interfaces for lateral movement or privilege escalation within the local environment. The lack of impersonation means that all actions performed through these COM objects are executed with the full privileges of the hMailServer service account rather than the calling user's identity, compounding the severity of the impact.
Mitigation strategies must focus on restricting access to the vulnerable components and updating software where possible. Immediate remediation involves upgrading hMailServer to a version beyond 6.3.5 where these authorization gaps have been addressed by the vendor. For systems that cannot be immediately updated, administrators should restrict COM launch and activation permissions for the specific CLSIDs associated with hMailServer objects using DCOMCNFG or PowerShell commands, ensuring only authorized service accounts can interact with them. Additionally, running the hMailServer service under a dedicated low-privilege account rather than LocalSystem significantly reduces the impact of file write operations, preventing arbitrary code execution even if an attacker gains control over attachment saving functions. Regular auditing of COM security descriptors and enforcing strict authentication requirements for all API calls are essential practices to prevent similar vulnerabilities in enterprise mail infrastructure.