CVE-2026-104659 in hMailServer
Summary
by MITRE • 10/08/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in Progressive Robot hMailServer versions 6.0.0 through 6.3.5 represents a critical security flaw rooted in insufficient input validation and inadequate access controls within its REST API listener component. This specific service, which is disabled by default but becomes active when enabled, binds to the loopback interface at address 127.0.0.1. The core technical deficiency lies in the server's failure to validate the Host header of incoming HTTP requests against expected values or configured domains. Consequently, the listener accepts and processes authentication attempts regardless of the source domain specified in the request headers. This lack of strict host validation creates a significant attack surface when combined with other misconfigurations regarding session management and rate limiting mechanisms for administrative accounts.
The operational impact is severe due to the interaction between this flaw and DNS rebinding attacks, which exploit browser same-origin policies by tricking them into treating an attacker-controlled domain as if it were part of the local network or loopback interface. An adversary can craft a malicious web page that utilizes JavaScript to send HTTP requests directly to 127.0.0.1 where hMailServer is listening. By leveraging DNS rebinding, the attacker ensures that these cross-origin requests are not blocked by modern browser security models because they appear to originate from localhost during execution within the victim's browser environment on the mail server itself. This allows an unauthenticated remote actor to bypass standard network-based access controls and interact directly with administrative endpoints as if they were a local user.
Compounding this issue is the absence of throttling or auto-banning mechanisms for failed administrator sign-in attempts originating from the loopback interface. In secure implementations, repeated authentication failures should trigger temporary account lockouts or exponential backoff delays to mitigate brute-force attacks. However, in affected versions of hMailServer, there are no such safeguards applied to requests coming through this specific listener when accessed via localhost. This allows an attacker to automate password guessing at full speed without fear of being locked out after a few incorrect attempts. The combination of unrestricted Host header acceptance and unlimited retry rates effectively neutralizes the protective barrier provided by binding the service to 127.0.0.1, as network-level isolation is bypassed via client-side browser execution techniques.
From an industry standard perspective, this vulnerability aligns with CWE-346, which describes the origin of a claim being misinterpreted or not validated properly, specifically relating to host header validation failures. It also maps closely to CWE-798, involving the use of hardcoded credentials or weak authentication controls that allow brute-forcing due to lack of rate limiting. Furthermore, in terms of offensive security frameworks like MITRE ATT&CK, this scenario illustrates techniques associated with T1052, specifically sub-technique 003 for Exfiltration Over Alternative Protocol if data is stolen after access, but more critically it demonstrates aspects of privilege escalation and lateral movement enabled by weak authentication controls. The attack vector relies heavily on browser-based exploitation which falls under the broader category of client-side attacks that abuse trust relationships between local services and web browsers.
To mitigate this risk, administrators must ensure that the REST API listener remains disabled unless absolutely necessary for specific integrations requiring external access. If enabling the service is required, it should be bound to a non-loopback interface only if strictly needed, though binding to loopback with proper validation is safer than exposing it externally without controls. Crucially, developers and administrators must implement strict Host header validation to ensure that requests are rejected unless they match expected domain names or IP addresses. Additionally, robust rate-limiting policies must be enforced for all administrative authentication endpoints, including those accessed via the local interface, to prevent brute-force attacks regardless of their origin point. Regular security audits should verify that no services expose sensitive management interfaces without comprehensive input validation and account lockout mechanisms in place.