CVE-2026-126618

MEDIUMPre-NVD 5.35.3
EchelonGraph scoreHIGH confidence

“—” beside the score: it is equal to the CVSS score beside it.

Score 5.3 from GitHub Security Advisory (severity: MODERATE) published 2026-11-11. A secondary CVSS source baseline 5.3; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: EPSS, GitHub Security Advisory, a secondary CVSS source

Also known asEUVD-2026-123334 (ENISA EUVD) · GHSA-2wjf-5hp3-227w (GitHub Security Advisories)Source: ENISA EUVD

5.3EG
EchelonGraph verdictMonitorRemediate within your standard update timelines (the SSVC decision on this page).
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS PROB: 0.4%CVSS: 5.3Exploit: None knownExposed services: Not assessed

Upgrade to hMailServer 6.3.8, which chooses an auto-ban's range name as the database will store it, keeping the part that makes it unique within the column's 100 characters, checks that exact name through a bound parame… (from the CVE record's solution, GitLab Inc.) — apply it.

The auto-ban of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker who can connect from two or more addresses to go on guessing account passwords - over SMTP AUTH, IMAP and POP3, and over ManageSieve, CalDAV/CardDAV and the REST API where those are turned on (off by default) - without being banned. When the failed logons counted from one address reach MaxInvalidLogonAttempts (3 by default), the server clears that address's count, saves an IP range that refuses the address for AutoBanMinutes (60 by default) and drops the connection. The range is named "Auto-ban: " followed by the user name of the logon that reached the limit, and no two ranges may have the same name. The server chooses the name by checking candidates as written - the name, then the name with a number, a random suffix or a GUID added - and only then cuts it to the 100 characters the database column holds, so that with a user name of 90 characters or more every candidate is the same once cut. While one range named after such a user name stands, every later ban named after a user name with the same first 90 characters therefore fails at the database: no range is saved, the address is not refused, and, its count having already been cleared, it is given the next full set of attempts. A user name of 78 to 89 characters makes later bans fail in the same way: from the second, the third or the twelfth on, depending on its length and the database, or, from 78 to 85 characters, by chance. An attacker who has once had an address banned under such a name can in this way keep guessing passwords from any other address, ending each set of attempts with a logon under a name of that kind; each failed save is reported in the server's error log (as the database error HM5032, and from 6.2.19 also as HM6099). On SQL Server a user name holding characters outside the database's code page has the same effect at any length, because the check compared names in that code page; that save is refused by the server's own check of the name, with no database error, and is reported only from 6.2.19 (HM6099). A user name holding a NUL character, which the web services listener's HTTP Basic sign-in (off by default) carries from 6.3.3 and, on the Linux builds, IMAP LOGIN, offered as installed, from 6.3.0, makes bans fail at any length: on MySQL, MariaDB and PostgreSQL the statements that check the name and save the range end at the character, so that every ban named after such a name fails, from the first and from a single address, and, its count having already been cleared, the address is given the next full set of attempts; on SQL Server and SQL Server Compact the name is bound only as far as the character, so that while one range under the part before it stands, every later ban named after such a name fails. On SQL Server, and on MySQL and MariaDB for an account whose local part has nine characters or more, a guess at the account can itself carry a name of that kind, since those databases find an account under its address followed by spaces (and SQL Server also under one holding characters its comparison ignores), so that not even a MaxInvalidLogonAttempts of 1, which bans each failed logon under the name it gave, avoids it there.

CVSS v3
5.3
EG Score
5.3MEDIUMhigh confidence
EG Risk
24
EG Risk 24/100

EG Risk is EchelonGraph's 0–100 priority score. It fuses impact severity (EG Severity, the CVSS base score, never the KEV-floored or EPSS-lifted EG Score) with real-world exploitation and automatability, under weights EchelonGraph set by hand, so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner.

How it’s computed (value × EchelonGraph’s weight)
Severity53% × 45%
Impact severity (EG Severity): CVSS 5.3 of 10. Never the KEV-floored or EPSS-lifted EG Score.
Exploitation0.4% × 40%
FIRST EPSS: the 30-day exploitation probability when EchelonGraph scored this CVE.
Automatability0% × 15%
CISA's BOD 26-04 default: no one has published Automatable for this CVE, and CISA treats it as “no” for a CVE not in KEV.
SSVC (CISA's decision table, applied by EchelonGraph): Track at low or medium mission impact; Track* at high (mission-essential systems).
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE.
Action: Upgrade to hMailServer 6.3.8, which chooses an auto-ban's range name as the database will store it, keeping the part that makes it unique within the column's 100 characters, checks that exact name through a bound parame… (from the CVE record's solution, GitLab Inc.). Apply it within your standard update timelines.
EPSS PROB
0.4%
EPSS %ILE
38th
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

The EG score (5.3): severity, escalated by confirmed exploitation. This CVE's 5.3 is its impact severity (EG Severity), not escalated.

EG Severity
5.3 MEDIUMCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.GitHub Security Advisory CVSS
EG Likelihood
0.4% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-11-12). FIRST's exploitation probability, not an EchelonGraph model.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
SSVC Track at medium mission impactTrack at low or medium mission impact; Track* at high (mission-essential systems).CISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.

SSVC (CISA's decision table, applied by EchelonGraph)Track at low or medium mission impact; Track* at high (mission-essential systems).

Upgrade to hMailServer 6.3.8, which chooses an auto-ban's range name as the database will store it, keeping the part that makes it unique within the column's 100 characters, checks that exact name through a bound parame… (from the CVE record's solution, GitLab Inc.). Apply it within your standard update timelines.

Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

November 11, 2026

Last Modified

November 12, 2026

Vendor Advisories for CVE-2026-126618(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 6× in last 7d / 6× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed its CVE.org record (CNA or CISA ADP). An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). "EchelonGraph re-scored" is our own recompute of this CVE's score, not an update from a source, and is not counted in the refreshes above. Most recent first.

  1. 2026-11-12 19:09 UTCEchelonGraph re-scored
  2. 2026-11-12 19:09 UTCGHSA enrichmentGHSA-2wjf-5hp3-227w · GitHub severity MODERATE · GitHub CVSS 5.3
  3. 2026-11-12 16:33 UTCEPSS rescoreEPSS 0.4% · 38th percentile
  4. 2026-11-11 16:38 UTCEPSS rescoreEPSS 0.4% · 38th percentile
  5. 2026-11-11 09:46 UTCEchelonGraph re-scored
  6. 2026-11-11 09:46 UTCGHSA enrichmentGHSA-2wjf-5hp3-227w · GitHub severity MODERATE · GitHub CVSS 5.3
  7. 2026-11-11 09:27 UTCEchelonGraph re-scored
  8. 2026-11-11 09:00 UTCENISA EUVD ID recordedEUVD-2026-123334 · Source: ENISA EUVD
  9. 2026-11-11 08:39 UTCEchelonGraph re-scoredFirst assessed: 5.3 MEDIUM
  10. 2026-11-11 08:39 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-126618?
CVE-2026-126618 is a medium-severity vulnerability; its CVE record was published on November 11, 2026. The auto-ban of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker who can connect from two or more addresses to go on guessing account passwords - over SMTP AUTH, IMAP and POP3, and…
When was the CVE record for CVE-2026-126618 published?
The CVE record for CVE-2026-126618 was published on November 11, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of November 12, 2026; the record at its source may have been updated since.
Is CVE-2026-126618 actively exploited?
CVE-2026-126618 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.4% probability of exploitation in the next 30 days (38th percentile of EPSS-scored CVEs).
What is the CVSS score of CVE-2026-126618?
CVE-2026-126618 has a CVSS base score of 5.3 (a secondary CVSS source that NVD displays; NVD's own analysis pending).
How do I remediate CVE-2026-126618?
The CVE record's solution for CVE-2026-126618, written by its CNA GitLab Inc., names the fix: "Upgrade to hMailServer 6.3.8, which chooses an auto-ban's range name as the database will store it, keeping the part that makes it unique within the column's 100 characters, checks that exact name through a bound parame…" The vendor advisories EchelonGraph has for CVE-2026-126618 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-126618

Explore →

Is Your Infrastructure Affected by CVE-2026-126618?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.