Progressive Robot hMailServer: Unzureichende Zertifikatsprüfung in der Datenbank-TLS-Verbindung

Zusammenfassung

Unter Windows kann hMailServer dazu gebracht werden, einer falschen Zertifizierungsstelle zu vertrauen, wenn für eine PostgreSQL-Datenbankverbindung eine Root-Zertifikatsdatei konfiguriert ist, oder für TlsCaFile mit einer Oracle-MySQL-Clientbibliothek. Der Dateiname der Root-Zertifikatsdatei enthält Nicht-ASCII-Zeichen, die auch als gültiges UTF-8 gelesen werden, sodass der Datenbankclient das Serverzertifikat gegen eine andere Datei prüft. Ein lokaler Angreifer, der diese Datei erstellen kann und die Verbindung zum Datenbankserver abfangen oder den Server vortäuschen kann, kann den Datenverkehr zwischen hMailServer und der Datenbank lesen und verändern, einschliesslich des Datenbankpassworts. Die Konfiguration ist nicht die Standardeinstellung.

Betroffen

• Progressive Robot hMailServer 6.2.25 bis 6.3.7 unter Windows mit einer PostgreSQL-Datenbank, sslmode require, verify-ca oder verify-full, und einer Root-Zertifikatsdatei in PostgreSQLSslRootCert (ab 6.2.25) oder TlsCaFile mit TlsMode=verify-full (ab 6.3.4)
• hMailServer 6.3.4 bis 6.3.7 unter Windows mit TlsCaFile und einer Oracle-MySQL-Clientbibliothek anstelle des mitgelieferten MariaDB Connector/C
• Nicht betroffen: Standardkonfiguration (keine Root-Zertifikatsdatei angegeben), mitgelieferter MariaDB Connector/C, Linux-Versionen

Behoben in

• Behoben in hMailServer 6.3.8

Umgehung

• Die Root-Zertifikatsdatei über einen Pfad angeben, der nur ASCII-Zeichen enthält, zum Beispiel C:\ProgramData\hMailServer\database-ca.pem, und diesen Pfad in PostgreSQLSslRootCert oder TlsCaFile eintragen
• Falls ein Name mit Nicht-ASCII-Zeichen beibehalten werden muss, sicherstellen, dass kein anderer Benutzer die Datei oder den Ordner erstellen kann, auf den die UTF-8-Lesart des Namens verweist
• Schreibzugriff auf die Ordner einschränken, in denen die Zertifikatsdatei liegt, einschliesslich ProgramData und eines eingeschränkten Ordners direkt im Stammverzeichnis des Systemlaufwerks

Ausnutzung

• Gemäss OffSeq und VulDB nicht bekanntermassen ausgenutzt
• Während der Recherche wurde kein öffentlicher Proof of Concept oder Exploit gefunden
• Der Hersteller hat das Problem gemeldet; eine Ausnutzung setzt lokalen Zugriff sowie die Möglichkeit voraus, die Datenbankverbindung abzufangen oder den Datenbankserver vorzutäuschen

Unsere Empfehlung

• Hi nweis entfernen
• Auf hMailServer-Instanzen unter Windows mit PostgreSQL oder TlsCaFile prüfen und in hMailServer.ini nach PostgreSQLSslRootCert oder TlsCaFile suchen
• Auf hMailServer 6.3.8 aktualisieren; vor dem Update Pfade mit Nicht-ASCII-Zeichen gemäss den Versionshinweisen umbenennen
• Falls ein Update nicht möglich ist, einen Pfad mit reinen ASCII-Zeichen für die Root-Zertifikatsdatei verwenden oder den Schreibzugriff auf deren Ordner einschränken
• Prüfen, welche Benutzer lokale Konten auf dem Server besitzen, und diese auf das Nötigste beschrä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 6.3.8 release notes (GitLab) gitlab.com
• Vendor issue #114: Database TLS on Windows gitlab.com
• hMailServer 6.3.8 download page (Progressive Robot) www.progressiverobot.com
• VulDB entry CVE-2026-126609 vuldb.com
• CVE-2026-126609 record (threatint) cve.threatint.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 10:26.