CVE-2026-107567 in hMailServer
Zusammenfassung
von VulDB • 19.10.2026
Die Verwendung einer weniger vertrauenswürdigen Quelle bei der DKIM-Signierung von Progressive Robot hMailServer 6.0.0 bis 6.3.6 ermöglicht es einem entfernten, nicht authentifizierten Angreifer, E-Mails, die er verfasst hat, mit dem DKIM-Schlüssel einer Domain zu signieren, die vom Server gehostet wird, sodass diese bei anderen Empfängern für diese Domain sowohl DKIM- als auch DMARC-Prüfungen bestehen. Wenn die DKIM-Signierung für eine gehostete Domain aktiviert ist, signierte der Server jede Nachricht beim ersten Zustellungsdurchlauf als die in ihrem From-Header genannte Domain, vor der lokalen Zustellung, unabhängig vom Ursprung der Nachricht und ohne zu prüfen, ob ihr Absender authentifiziert war. Ein beliebiger Absender konnte dem Server daher eine E-Mail als gewöhnliche eingehende Mail senden, deren From-Adresse einer solchen Domain zugeordnet ist, und der Server signierte sie mit dem Schlüssel dieser Domain. Jede Kopie, die der Server anschließend an eine Adresse außerhalb sendete, trug eine gültige Signatur, die mit der gefälschten From-Adresse übereinstimmte, unabhängig von der DMARC-Richtlinie der Domain: ein Konto-Forwarding, ein E-Mail-Regel-Weiterleitungs- oder Kopierziel, eine Sieve-Umleitung, ein Alias oder eine Verteilerliste mit einem externen Mitglied, die Spiegelkopie, eine verwaltete Liste oder Journal-Kopie oder eine aus Quarantäne freigegebene Nachricht. Eine signierte Kopie kann auch erneut an andere Empfänger gesendet werden, solange der Schlüssel der Domain unverändert bleibt. Für die Ausnutzung muss die DKIM-Signierung für die gehostete Domain aktiviert sein (sie ist standardmäßig deaktiviert), und damit die Fälschung den Server verlässt, muss ein Forwarding-, Alias-, Listen- oder Regelziel vorhanden sein, das die Mail der Domain an eine externe Adresse weiterleitet. Der Signierer signierte ebenfalls Nachrichten, die über authentifiziertes SMTP eingereicht wurden, als jede beliebige gehostete Domain, die in ihrem From-Header genannt wurde; ein Header von authentifiziertem SMTP hält sich nicht an das einreichende Konto, sodass ein Konto einer gehosteten Domain E-Mails im Namen einer anderen gehosteten Domain verfasst und mit dem Schlüssel dieser Domain signieren lassen konnte. Dies war relevant, wo der Server bei angemeldeten Absendern deren eigene Envelope-Adressen durchsetzt (SmtpAuthenticatedSenderCheck, standardmäßig deaktiviert), da die Signatur dann der einzige verbleibende Weg war, damit solche Nachrichten die DMARC-Richtlinie der anderen Domain bestehen konnten.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.