CVE-2026-104659: Origin Validation Error in hMailServer
Missing Host header validation and missing throttling of failed administrator sign-ins in the REST API listener of Progressive Robot hMailServer 6.0.0 through 6.3.5 allow a remote attacker to brute-force the server administrator's password through the administrator's own browser by DNS rebinding. The listener, which is off by default and bound to the loopback when enabled, answered requests whatever their Host header named, and a failed sign-in with the administrator's password from the loopback was neither auto-banned nor delayed. A web page whose host name the attacker rebinds to 127.0.0.1, opened in a browser on the server, can therefore send authenticated requests to the listener, read the answers and try administrator passwords at full speed until one is accepted, giving the attacker full administrative control of the mail server.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Progressive Robot hMailServerto a version that resolves this vulnerability.Fixed in 6.3.6 - Configuration
Keep the REST API off by setting RestApiPort to 0.
hMailServer REST API listener RestApiPort = 0 - Compensating control
Give the server administrator a long random password and enroll a second factor.
- Compensating control
Do not browse the web from the server.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems running hMailServer 6.0.0 through 6.3.5 are exposed only if the REST API listener has been enabled. The listener is off by default and binds to loopback, but exploitation also requires a browser to open an attacker-controlled page on the server itself.
What does an attacker need to exploit it?
The attacker needs to cause a browser on the hMailServer host to visit a web page under a hostname they can DNS-rebind to 127.0.0.1. They can then brute-force the server administrator password because failed REST API sign-ins are not automatically banned or delayed.
How can I tell whether my deployment is affected?
Check whether the REST API listener is enabled and whether the installation is running a version from 6.0.0 through 6.3.5. An enabled listener on an affected version accepts requests regardless of the Host header and does not throttle or auto-ban failed administrator sign-ins from loopback.
What can be done if updating is not immediately possible?
Disable the REST API listener if it is not required. If it must remain enabled, prevent browsers on the server from visiting untrusted or attacker-controlled web pages, since the described attack depends on browser access on that host.