Progressive Robot hMailServer: Umgehung der automatischen Sperre bei Nicht-BMP-Benutzernamen

Zusammenfassung

hMailServer 6.2.0 bis 6.3.3 mit einer MySQL- oder MariaDB-Datenbank kann daran gehindert werden, eine Adresse nach wiederholten fehlgeschlagenen Anmeldungen automatisch zu sperren. Eine SASL-PLAIN-Anmeldung, deren Benutzername ein Zeichen ausserhalb der Basic Multilingual Plane enthält, führt dazu, dass das Speichern des IP-Bereichs für die Sperre fehlschlägt, sodass die Adresse nicht blockiert wird und eine neue Serie von Versuchen erhält. Ein entfernter, nicht authentifizierter Angreifer kann so von einer einzelnen Adresse aus Passwörter erraten, ohne gesperrt zu werden. Die Datenbankbedingung betrifft Standardinstallationen nicht, doch ist POP3 AUTH PLAIN unter Windows ohne besondere Einstellung erreichbar, und IMAP, SMTP, ManageSieve und CardDAV sind dort erreichbar, wo sie aktiviert sind.

Betroffen

• hMailServer 6.2.0 bis 6.3.3
• Nur mit einer MySQL- oder MariaDB-Datenbank
• Linux: ab 6.3.0, SMTP AUTH PLAIN, sofern Klartext-Authentifizierung erlaubt ist
• Windows: POP3 AUTH PLAIN bei einer Standardinstallation; IMAP AUTHENTICATE PLAIN, sofern IMAP SASL aktiviert ist; SMTP AUTH PLAIN, sofern Klartext-Authentifizierung erlaubt ist; ManageSieve und CardDAV, sofern aktiviert

Behoben in

• Upgrade auf hMailServer 6.3.4 oder neuer und Ausführung des Datenbank-Upgrades (Schema 6102), das die MySQL- und MariaDB-Tabellen auf utf8mb4 umstellt
• Gemäss Hersteller behebt 6.3.8 zusätzlich eine separate Umgehung der automatischen Sperre (GitLab-Issue #104)
• Unbekannt, ob eine neuere Version aktuell ist; die Herstellerseite prüfen

Umgehung

• MaxInvalidLogonAttempts auf 1 setzen (Zwischenmassnahme des Herstellers; ein Erraten eines bestehenden Kontos wird dann unter diesem Namen gesperrt)
• Die IP-Bereichstabelle wie beim Upgrade auf 6.3.4 in utf8mb4 umwandeln (ALTER TABLE hm_securityranges ENGINE=InnoDB, ROW_FORMAT=DYNAMIC, CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci)
• Die Sperre pro Benutzername (AccountLockoutThreshold) ist wegen eines separaten Fehlers (#104) als Massnahme nicht brauchbar

Ausnutzung

• Gemäss OffSeq nicht als ausgenutzt bekannt
• VulDB gibt an, dass technische Details unbekannt sind und kein Exploit verfügbar ist
• Bis 11. November 2026 wurde kein öffentlicher Proof of Concept oder Forschungsbericht gefunden
• Der Hersteller beschreibt den Mechanismus im Detail, daher könnte bald ein Proof of Concept erscheinen
• Es ist keine Authentifizierung erforderlich

Unsere Empfehlung

• Prüfen, ob hMailServer 6.2.0 bis 6.3.3 mit MySQL oder MariaDB läuft und welche Protokolle aktiviert sind
• Backup und Wartungsfenster planen, dann auf 6.3.4 oder neuer aktualisieren und das Datenbank-Upgrade abschliessen; Prüfsummen und Signaturen des Downloads verifizieren
• Bis zur Behebung MaxInvalidLogonAttempts auf 1 setzen und das Fehlerprotokoll auf fehlgeschlagene Speicherungen der automatischen Sperre überwachen (HM5032, HM6099)
• Starke Passwörter erzwingen und externen Schutz vor Brute-Force-Angriffen einsetzen, da sich auf die integrierte Sperre nicht verlassen werden kann
• Zugriff auf POP3, IMAP, SMTP, ManageSieve und CardDAV wo möglich einschränken

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• hMailServer GitLab issue #103 gitlab.com
• hMailServer 6.3.4 release (GitLab) gitlab.com
• VulDB entry 435714 vuldb.com
• OffSeq CVE-2026-126616 radar.offseq.com
• hMailServer 6.3.4 downloads (vendor) www.progressiverobot.com
• hMailServer GitLab issue #104 gitlab.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 11.11.2026 17:56.