<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-14T19:24:23.315851+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-126615</id>
    <title>CVE-2026-126615 — Authentication Bypass by Alternate Name in hMailServer</title>
    <updated>2026-11-14T19:24:23.319008+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Progressive Robot Ltd hMailServer</p>
<p>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 com…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-126615"/>
  </entry>
</feed>
