Inefficient Algorithmic Complexity in hMailServer

Summary

Progressive Robot hMailServer 6.0.0 through 6.3.5 processes several IMAP commands from a signed-in account in time quadratic in the command's length or in the number of elements it names, and can be made to hold memory out of proportion to a command. The FETCH data-item parser normalised a BODY[] section with a case-insensitive string replacement that copied the whole item per occurrence and split the item list by repeatedly copying the remainder of the command; the server's case-insensitive search compared a needle afresh at every position, so a long SEARCH TEXT key over a message cost the product of the two lengths; SEARCH message sets and the saved-result marker ($), SORT criteria, HEADER.FIELDS name lists and UID ranges were each read once per message rather than once per command; and a FETCH naming a message's sections very many times read and held every section in memory before sending any. An IMAP command may continue past one line through non-synchronizing literals, so one command can reach about eleven megabytes. The IMAP worker threads are a small pool shared with SMTP and POP3, so a signed-in user sending such commands can make the IMAP, SMTP and POP3 services stop responding (CWE-407) and can consume excessive memory (CWE-400).

Timeline

1. Oct 8, 2026, 11:47 AM UTCCVE published
2. Oct 8, 2026, 2:18 PM UTCCISA SSVC assessment

   Exploitation: none · Automatable: no · Technical impact: partial

3. Oct 8, 2026, 2:19 PM UTCRecord last updated

Affected versions

• Progressive Robot Ltd hMailServer

  From 6.0.0 · fixed in 6.3.6

References 2