Progressive Robot hMailServer bis 6.3.7 Authentication hMailServer.ini AccountLockoutThreshold erweiterte Rechte

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.3$0-$5k0.31+

Zusammenfassunginfo

Es wurde eine Schwachstelle mit der Einstufung kritisch in Progressive Robot hMailServer bis 6.3.7 gefunden. Das betrifft eine unbekannte Funktionalität der Datei hMailServer.ini der Komponente Authentisierung. Dank Manipulation des Arguments AccountLockoutThreshold mit unbekannten Daten kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Diese Schwachstelle trägt die Bezeichnung CVE-2026-126615. Der Angriff kann über das Netzwerk angegangen werden. Es gibt keinen verfügbaren Exploit.

Detailsinfo

Es wurde eine kritische Schwachstelle in Progressive Robot hMailServer bis 6.3.7 entdeckt. Dabei betrifft es ein unbekannter Prozess der Datei hMailServer.ini der Komponente Authentication. Durch das Beeinflussen des Arguments AccountLockoutThreshold mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-697 vorgenommen. Mit Auswirkungen muss man rechnen für Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

The sign-in of Progressive Robot hMailServer 6.2.22-pre2 through 6.3.7 takes for an account names that are not its address but under which the database's own comparison finds it, while the per-name lockout and the compromised-account hold are kept by the name as the client gave it. This allows a remote unauthenticated attacker to go on guessing an account's password beyond the lockout's threshold, and anyone who has the password of an account held for review to sign in to it. The per-name lockout (from 6.2.22-pre2; AccountLockoutThreshold in hMailServer.ini, 0, off, by default) locks a name after repeated failed sign-ins. The hold (from 6.3.4, where the compromised-account detection is set to enforce, which is not the default) refuses an account judged to have been taken over. Both are asked, before the password, of the name the client gave: trimmed, in lower case and with a domain alias or the default domain applied. The account whose password the sign-in then checks is whichever one the database finds under that name. The databases find an account under spellings that this key counts apart. MySQL and MariaDB find it under one with accented letters in place of plain ones, and MariaDB 11.8, in a database made before 6.3.4, also under one with full-width letters, with a single letter in place of a pair of plain ones, or with characters its comparison ignores in any number. SQL Server and SQL Server Compact find it under one with full-width letters or with characters their comparison ignores in any number, and SQL Server also under one with a single letter in place of a pair of plain ones, with a character of Latin-1 in place of a digit and, for an address holding letters of Latin-1 outside ASCII, under those letters in the other case, and, under an accent-insensitive collation, with accented letters. PostgreSQL finds it under one holding a letter whose lower case under the database's locale is a plain letter, and, for an address holding letters outside ASCII, under those letters in the other case; on the build for musl (from 6.3.6) the server's own lower case folds nearly all of these too. On every database, a domain alias saved with white space at the end of its name gives such a spelling too, and on every database but PostgreSQL so does an account's bare local part where the default domain was saved with spaces at its end and no other white space (neither is the default). Each such spelling has a lockout threshold of its own, so the lockout limits the guesses at an account only to its threshold times the number of the account's spellings. That is far beyond any threshold for most addresses on MySQL and MariaDB, and without limit on SQL Server, on SQL Server Compact, the database the Windows installer uses by default, and before 6.3.4 on MariaDB 11.8. A locked name is got round under another spelling. A held account is signed in to under another spelling with its password over IMAP, POP3 and SMTP AUTH, and, where they are turned on (off by default), over ManageSieve, the REST API and the webmail. IMAP LOGIN, offered as installed, carries such spellings on MySQL, MariaDB and SQL Server Compact, and, on SQL Server and PostgreSQL, for some addresses; the sign-ins that carry a name as UTF-8 carry them for the others on SQL Server, and on PostgreSQL for those holding one of the plain letters another letter lowers to or a letter outside ASCII with another case. The same lookup mapped to accounts the names given by an OAuth 2.0 token, a client certificate, a Kerberos ticket and an OpenID Connect or SAML identity provider, where those are set up (none is by default), so that a name an issuer gave to one party could sign in to another's account; OAuth 2.0 tokens were mapped so from 6.2.0, before the per-name lockout existed. A name holding a NUL character, carried from 6.3.0 on Linux and 6.3.3 on Windows, failed the statement on MySQL, MariaDB and PostgreSQL.

Das Advisory kann von gitlab.com heruntergeladen werden. Die Verwundbarkeit wird seit dem 11.11.2026 unter CVE-2026-126615 geführt. Sie gilt als leicht auszunutzen. Der Angriff kann über das Netzwerk erfolgen. Zur Ausnutzung ist keine spezifische Authentisierung erforderlich. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt. Es muss davon ausgegangen werden, dass ein Exploit zur Zeit etwa USD $0-$5k kostet (Preisberechnung vom 11.11.2026).

Mittels inurl:hMailServer.ini können durch Google Hacking potentiell verwundbare Systeme gefunden werden.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

Once again VulDB remains the best source for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 6.3
VulDB Meta Temp Score: 6.3

VulDB Base Score: 7.3
VulDB Temp Score: 7.3
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CNA Base Score: 5.3
CNA Vector (GitLab): 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Erweiterte Rechte
CWE: CWE-697
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Nein
Lokal: Nein
Remote: Ja

Verfügbarkeit: 🔒
Status: Nicht definiert
Google Hack: 🔒
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: keine Massnahme bekannt
Status: 🔍

0-Day Time: 🔒

Timelineinfo

11.11.2026 Advisory veröffentlicht
11.11.2026 +0 Tage CVE zugewiesen
11.11.2026 +0 Tage VulDB Eintrag erstellt
11.11.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Advisory: gitlab.com
Status: Nicht definiert

CNA: GitLab
CVE: CVE-2026-126615 (🔒)

GCVE (CVE): GCVE-0-2026-126615
GCVE (VulDB): GCVE-100-435708

Eintraginfo

Erstellt: 11.11.2026 09:52
Anpassungen: 11.11.2026 09:52 (64)
Komplett: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Want to know what is going to be exploited?

We predict KEV entries!