CVE-2026-107587 in hMailServer
Summary
by MITRE • 10/08/2026
Improper certificate validation in the webmail of Progressive Robot hMailServer 6.3.2 through 6.3.5 allows a remote unauthenticated attacker to have S/MIME-encrypted mail that the account later sends to another correspondent also encrypted to the attacker's key. When its recipient opened a signed message, the webmail kept the signer's certificate for encrypting replies whether or not the server found its chain trusted, under the first e-mail address the certificate listed rather than the message's From address, and beside any certificate already held for that address. Encrypted mail later sent from the webmail to that address was encrypted to every certificate held for it, so a holder of the kept certificate's key who obtains a copy of such a message can read it.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.3.2 through 6.3.5 represents a critical failure in cryptographic validation and key management within its webmail interface, specifically concerning the handling of S/MIME encrypted communications. This flaw allows for a sophisticated man-in-the-middle style attack where an unauthenticated remote attacker can manipulate the encryption parameters of messages sent by legitimate users without their knowledge or consent. The core issue stems from how the server processes incoming signed and encrypted emails to determine which certificates should be stored in its local trust store for future outbound communications. Instead of strictly validating the certificate chain against a trusted root authority before accepting it, the system retains the signer's certificate based on superficial attributes rather than cryptographic validity. This behavior fundamentally undermines the integrity of public key infrastructure operations within the application, creating a pathway for unauthorized decryption of sensitive data.
The technical mechanism of this vulnerability relies on two distinct but related flaws in the webmail client logic. First, when a user receives an S/MIME signed message, the system extracts the signer's certificate and stores it to facilitate encrypted replies. However, this storage occurs regardless of whether the server successfully validated the certificate chain or determined that the issuer was trusted. This lack of strict validation means that certificates from untrusted or self-signed sources are treated with the same authority as those from recognized Certificate Authorities. Second, the system exhibits a logic error in address matching by associating the stored certificate with the first email address listed within the certificate itself rather than the actual From header field of the incoming message. This discrepancy creates a mismatch between the intended recipient and the cryptographic key used for encryption, allowing an attacker to inject their own public key into the victim's local store under a different identity or alias that matches the certificate subject.
The operational impact of this vulnerability is severe, as it enables a remote unauthenticated attacker to decrypt messages sent by victims to third parties. Once the attacker has successfully injected their public key into the victim's webmail client via the aforementioned mechanism, any subsequent encrypted email composed and sent from that account will be encrypted using all certificates held for the recipient address, including the maliciously inserted one. Consequently, if an attacker possesses the private key corresponding to the injected certificate, they can intercept and decrypt these messages even though the intended recipient also holds a valid copy of the message. This effectively breaks confidentiality guarantees provided by S/MIME encryption, allowing sensitive information such as personal data, business secrets, or credentials to be exposed to unauthorized parties without any indication that the communication has been compromised.
This vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-384 Session Fixation in terms of its impact on session integrity and trust establishment, although it is more accurately categorized under CWE-617 Reachable Assertion or CWE-20 Processing of Incorrectly-Sized Input if viewed through the lens of logic errors. In the context of the MITRE ATT&CK framework, this behavior facilitates Initial Access via Spearphishing Attachment or Drive-by Compromise depending on delivery method, but more critically it enables Credential Access and Data Exfiltration by allowing an attacker to read intercepted communications. The attack vector is classified as Remote Unauthenticated, meaning no prior access credentials are required to exploit the flaw, which significantly increases its risk profile in internet-facing deployments of hMailServer webmail interfaces.
Mitigation strategies must focus on immediate remediation through software updates and configuration hardening until patches are available from Progressive Robot. Administrators should upgrade hMailServer to a version that addresses this certificate validation logic error as soon as possible. In the interim, disabling S/MIME functionality within the webmail interface can prevent exploitation by removing the attack surface entirely. Organizations relying on encrypted email communications must also implement out-of-band verification processes for critical keys and consider using alternative mail clients or servers with more robust cryptographic implementations that strictly enforce certificate chain validation before storing public keys for future encryption operations. Regular auditing of stored certificates within the webmail client can help identify any unauthorized entries resulting from previous exploitation attempts, although complete remediation requires patching the underlying software defect.