CVE-2026-103649: Synchronous Access of Remote Resource without Timeout in hMailServer
Missing network timeouts in the Linux builds of Progressive Robot hMailServer 6.3.0 through 6.3.5 allow a remote attacker to hold server threads indefinitely and so stop outbound mail delivery (denial of service). The server set its socket timeouts in the form Windows takes, which Linux refuses, and its HTTPS clients read without a deadline, so a peer that accepts a connection and then sends nothing held the waiting thread for as long as the connection stayed open. The MTA-STS policy fetch, enabled by default, is made during outbound delivery to mta-sts.<recipient domain>, so anyone who can make the server deliver mail to a domain they control - for example as the envelope sender of a message that bounces - can hold delivery threads until outbound delivery stops. The same flaw affects the DANE TLSA query, the OAuth2 token request, the ACME client, and the ManageSieve and metrics listeners, which a silent client stops from serving anyone else. Windows builds are not affected.
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
On Linux, set MtaStsEnabled to 0 if outbound delivery stalls.
hMailServer MtaStsEnabled = 0 - Configuration
Keep the ManageSieve and metrics listeners off, or make them reachable only from trusted networks.
hMailServer ManageSieve and metrics listeners = off - Operational
Restart the hMailServer service to release held threads.
Event History
Frequently Asked Questions
Which deployments are affected?
Linux builds of hMailServer 6.3.0 through 6.3.5 are affected. Windows builds are not affected.
How can an unauthenticated remote attacker disrupt outbound delivery?
The attacker needs to cause the server to attempt delivery to a domain they control, such as by acting as the envelope sender of a message that generates a bounce. They can then accept the MTA-STS connection and send no data, leaving delivery threads blocked indefinitely.
Is the outbound-delivery attack path enabled by default?
Yes. MTA-STS policy fetching is enabled by default and occurs during outbound delivery to mta-sts.<recipient domain>.
What other components can be stalled by a silent peer?
The DANE TLSA query, OAuth2 token request, and ACME client are affected. Silent clients can also stop the ManageSieve and metrics listeners from serving other users.
How can I assess whether a server is exposed or already experiencing this issue?
A Linux deployment running version 6.3.0 through 6.3.5 is exposed. Indicators include outbound delivery stopping or ManageSieve or metrics listeners no longer serving clients after a peer connects but does not send data.