A Wrong Password Could Run Code Inside hMailServer
A wrong password can become code before the login succeeds. Progressive Robot’s hMailServer 6.3.4 release on 27 September fixes that risk in its Windows 6.x project. The issue should not be generalised to every original hMailServer 5.x installation.
The vulnerability record identifies CVE-2026-100741. The affected range is 6.0.0 through 6.3.3. The remote password path needs an existing active account, event scripting enabled, JScript selected and an OnClientValidatePassword handler. Event scripting is off by default, and its default language is VBScript. The password itself need not be correct. This password-injection path does not affect Linux builds or VBScript event scripts.
Check the script configuration before judging exposure
The vendor fix addresses string construction that mishandled a backslash before an apostrophe. Injected JScript runs within the service; operating-system command execution depends on the permitted script objects and the service account’s rights. Before 6.2.25, the injected script could create any COM object. From 6.2.25, the shipped wildcard value of ScriptAllowedObjects still permits that access, including WScript.Shell. Restricting the service account’s rights therefore matters alongside the code fix.
The release notes also identify remote POP3 UID and SMTP error-text paths through OnExternalAccountDownload and OnDeliveryFailed, respectively. Interim mitigation is to disable event scripting, or remove OnClientValidatePassword, OnExternalAccountDownload and OnDeliveryFailed from EventHandlers.js and reload scripts. Restrict Run function rule editing to server administrators too, because that separate path can affect VBScript.
The update needs a maintenance plan
The vendor requires manual installation of 6.3.4 and warns of 64 one-way database steps, advancing the schema from 6040 to 6104. Database size and backend requirements can affect the maintenance window. Back up the database and data directory and read the upgrade notes before installation.
Separate the immediate exposure decision from the maintenance window. Record which scripts are enabled, who depends on them and what happens if they are switched off. A temporary mitigation that silently breaks mail handling can be reversed under pressure unless the service owner understands the reason for it.
For the upgrade, nominate an operator and an independent verifier. Test the restored backup as well as the new release. Define which checks establish successful mail delivery, authentication and script behaviour, then capture their results. A service restart alone is not an acceptance test.
Look beyond the patch result
Review the service account’s access to local files, network shares and other credentials. Preserve useful authentication, application and process-creation logs before retention removes them. Failed logins and script errors are investigation leads, not proof of an intrusion; absence of those events is not a clean bill of health either.
The reviewed vendor release does not report in-the-wild exploitation. For a related but separate mail-security case, see BlackTree’s OWAReaper analysis.
Update, 28 September 2026: distinguish assessment from observed attacks
A CISA enrichment recorded in NVD, timestamped 28 September at 12:55:48 UTC, marks exploitation as none. That is a dated assessment from that source, not proof that no attack occurred. It was not available when this article was originally published on 27 September.
Sources
- hMailServer 6.3.4 release notes, released 27 September 2026 at 02:37:56 UTC, 04:37:56 CEST. The page carries the security description, manual-upgrade warning and temporary mitigation.
- Vendor fix commit, linked by the public vulnerability record.
- NVD record, published 27 September 2026 at 08:16:26 UTC, 10:16:26 CEST.
