CVE-2026-114471 in hMailServer
Summary
by MITRE • 10/21/2026
Insertion of sensitive information into a log file in the SMTP server of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a local user who can read the server's log, or anyone given a copy of it, to obtain credentials. With SMTP logging enabled, the server hid the credential of an AUTH PLAIN command only when it was sent after EHLO in one exact form, and wrote the rest of the SASL exchange as the client sent it: a PLAIN password sent before EHLO or with extra spacing, the OAuth 2.0 bearer token of AUTH XOAUTH2 and AUTH OAUTHBEARER (from 6.2.0), the SCRAM-SHA-256 client proof (from 6.2.0), which with the logged salt and iteration count allows offline password guessing, and the GSSAPI authenticator (from 6.3.2). SMTP logging is off by default; on Windows before 6.3.6 the log folder was readable by every local user.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.6 represents a critical flaw in how authentication credentials are handled during Simple Mail Transfer Protocol sessions, specifically when logging is enabled. This issue falls under the category of sensitive information exposure within log files, which corresponds to CWE-532 in standard vulnerability classification systems. The core technical failure lies in an inconsistent implementation of credential masking for SASL (Simple Authentication and Security Layer) mechanisms. While the server attempts to obscure passwords sent via AUTH PLAIN commands that follow a specific sequence immediately after EHLO, it fails to apply this protection in numerous other common scenarios. Consequently, plaintext credentials are written directly to log files whenever authentication does not adhere strictly to that single protected pattern or when alternative SASL methods are utilized.
The operational impact of this flaw is severe because SMTP logging was disabled by default, meaning many administrators may have been unaware that their servers were recording sensitive data until an incident occurred. However, for those who had enabled logging, the risk was compounded by inadequate file system permissions on Windows systems prior to version 6.3.6. In these earlier versions, the log directory possessed world-readable permissions, allowing any local user with access to the operating system to view the contents of the log files without requiring elevated privileges or administrative rights. This configuration effectively turned a standard operational artifact into an open repository for harvested credentials, facilitating unauthorized access to mail accounts and potentially leading to broader network compromise if those credentials are reused across other services.
The scope of exposed data extends beyond simple plaintext passwords due to the handling of various authentication mechanisms. For AUTH PLAIN commands sent before EHLO or containing extra spacing, the password is logged in clear text. Furthermore, starting from version 6.2.0, the server logs OAuth 2.0 bearer tokens for both AUTH XOAUTH2 and AUTH OAUTHBEARER methods without masking. These tokens can be intercepted and replayed to gain unauthorized access to mail services. Additionally, SCRAM-SHA-256 client proofs are logged alongside their associated salt and iteration counts from version 6.2.0 onwards. Although SCRAM is designed for secure password verification, the exposure of these components allows attackers to perform offline brute-force attacks against user passwords using standard cryptographic cracking tools. Similarly, GSSAPI authenticators introduced in version 6.3.2 are also logged without sufficient obfuscation, exposing Kerberos tickets or other security context data that could be exploited for privilege escalation or lateral movement within a domain environment.
From an offensive security perspective, this vulnerability aligns with ATT&CK technique T1078, which involves valid accounts being used to gain access, and specifically relates to the collection of credentials from local system logs as described in sub-techniques related to log harvesting. The ability for any local user to read these files facilitates initial access or credential dumping phases of an attack chain. To mitigate this risk, administrators must immediately upgrade hMailServer to version 6.3.7 or later, where the file permissions have been corrected and logging behaviors improved. For systems that cannot be upgraded instantly, it is imperative to disable SMTP logging entirely if not strictly required for compliance or debugging purposes. If logging remains necessary, strict access controls should be applied to the log directory to ensure only authorized service accounts can read them, and administrators must audit existing logs for any previously exposed credentials and force password resets for affected users.