CVE-2026-59218: Open WebUI timing leak enables

Q: Is CVE-2026-59218 actively exploited?

No confirmed active exploitation of CVE-2026-59218 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-59218?

Upgrade to Open WebUI 0.10.0 or later, which fixes the timing side-channel per GHSA-7rw5-9f7q-xj36 (commit 993e749). If immediate upgrade isn't possible: (1) add rate limiting/throttling in front of /api/v1/auths/signin (reverse proxy or WAF) to blunt automated enumeration sweeps; (2) enforce a consistent response-time floor at the proxy layer (e.g., artificial delay) as a stopgap; (3) monitor auth logs for high-volume sign-in attempts against many distinct emails from a single IP/session — a signature of enumeration; (4) if the instance is internet-facing without a business need, restrict it behind VPN or IP allowlisting.

Q: What systems are affected by CVE-2026-59218?

This vulnerability affects the following AI/ML architecture patterns: self-hosted LLM chat UI platforms, model serving front-ends.

Q: What is the CVSS score for CVE-2026-59218?

CVE-2026-59218 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.41%.

CISO Take

Open WebUI's sign-in endpoint ran bcrypt verification only when the submitted email matched a registered account, making valid emails respond measurably slower than invalid ones and letting an unauthenticated attacker enumerate which accounts exist on a self-hosted deployment. This doesn't grant access, leak passwords, or execute code — the blast radius is reconnaissance, not compromise — and exploitation likelihood is low: EPSS sits at 0.24% (top 84th percentile of scored CVEs, but a small absolute number), with no public exploit, no Nuclei template, and no CISA KEV listing. The practical danger is that confirmed usernames/emails become fuel for downstream credential stuffing, targeted phishing, or password-guessing against instances lacking login rate limits — a meaningful concern given Open WebUI fronts LLM chat access for teams and individuals. Patch to Open WebUI 0.10.0, which normalizes response timing regardless of account existence; until upgraded, put rate limiting or a WAF rule in front of /api/v1/auths/signin and alert on bursts of sign-in attempts cycling through different emails from one source.

Sources: NVD GitHub Advisory EPSS

What is the risk?

Low-to-medium risk in practice despite CVSS 5.3 (network, low complexity, no privileges/UI needed). Impact is confidentiality-only (C:L, no integrity/availability effect) and limited to disclosing account existence, not credentials or session data. Exploitability is trivial (basic timing measurement, no special tooling), but the EPSS score (0.24%, ~84th percentile) reflects that few attackers prioritize enumeration bugs absent a chained credential-stuffing campaign. No KEV listing, no public exploit code, and no scanner template further reduce urgency. Exposure is proportional to how many Open WebUI instances are internet-facing without login throttling — self-hosted deployments run by smaller teams are more likely to lack that control.

How does the attack unfold?

Reconnaissance

Attacker identifies an internet-facing Open WebUI instance and prepares a list of candidate email addresses to test.

AML.T0003

Enumeration

Attacker sends repeated sign-in requests with fixed bogus passwords, measuring response latency to distinguish registered emails (slower, bcrypt runs) from unregistered ones (faster, no bcrypt).

AML.T0012

Target list compilation

Attacker compiles a confirmed list of valid user accounts on the instance without triggering per-user failed-login alerts.

Follow-on attack

Attacker uses the confirmed account list to run targeted credential stuffing, password spraying, or spear-phishing against real users of the AI platform.

Reconnaissance

Attacker identifies an internet-facing Open WebUI instance and prepares a list of candidate email addresses to test.

AML.T0003

Enumeration

Attacker sends repeated sign-in requests with fixed bogus passwords, measuring response latency to distinguish registered emails (slower, bcrypt runs) from unregistered ones (faster, no bcrypt).

AML.T0012

Target list compilation

Attacker compiles a confirmed list of valid user accounts on the instance without triggering per-user failed-login alerts.

Follow-on attack

Attacker uses the confirmed account list to run targeted credential stuffing, password spraying, or spear-phishing against real users of the AI platform.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	< 0.10.0	`0.10.0`
149.6K 4 dependents Pushed 3d ago 81% patched ~6d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 34% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C Low

I None

A None

What should I do?

1 step

Upgrade to Open WebUI 0.10.0 or later, which fixes the timing side-channel per GHSA-7rw5-9f7q-xj36 (commit 993e749). If immediate upgrade isn't possible: (1) add rate limiting/throttling in front of /api/v1/auths/signin (reverse proxy or WAF) to blunt automated enumeration sweeps; (2) enforce a consistent response-time floor at the proxy layer (e.g., artificial delay) as a stopgap; (3) monitor auth logs for high-volume sign-in attempts against many distinct emails from a single IP/session — a signature of enumeration; (4) if the instance is internet-facing without a business need, restrict it behind VPN or IP allowlisting.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Privacy Violation Auth Bypass Framework AML.T0012 - Valid Accounts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 (Security) - AI system security controls

NIST AI RMF

MANAGE 4.1 - AI system risk response

Frequently Asked Questions

What is CVE-2026-59218?

Open WebUI's sign-in endpoint ran bcrypt verification only when the submitted email matched a registered account, making valid emails respond measurably slower than invalid ones and letting an unauthenticated attacker enumerate which accounts exist on a self-hosted deployment. This doesn't grant access, leak passwords, or execute code — the blast radius is reconnaissance, not compromise — and exploitation likelihood is low: EPSS sits at 0.24% (top 84th percentile of scored CVEs, but a small absolute number), with no public exploit, no Nuclei template, and no CISA KEV listing. The practical danger is that confirmed usernames/emails become fuel for downstream credential stuffing, targeted phishing, or password-guessing against instances lacking login rate limits — a meaningful concern given Open WebUI fronts LLM chat access for teams and individuals. Patch to Open WebUI 0.10.0, which normalizes response timing regardless of account existence; until upgraded, put rate limiting or a WAF rule in front of /api/v1/auths/signin and alert on bursts of sign-in attempts cycling through different emails from one source.

Is CVE-2026-59218 actively exploited?

No confirmed active exploitation of CVE-2026-59218 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59218?

Upgrade to Open WebUI 0.10.0 or later, which fixes the timing side-channel per GHSA-7rw5-9f7q-xj36 (commit 993e749). If immediate upgrade isn't possible: (1) add rate limiting/throttling in front of /api/v1/auths/signin (reverse proxy or WAF) to blunt automated enumeration sweeps; (2) enforce a consistent response-time floor at the proxy layer (e.g., artificial delay) as a stopgap; (3) monitor auth logs for high-volume sign-in attempts against many distinct emails from a single IP/session — a signature of enumeration; (4) if the instance is internet-facing without a business need, restrict it behind VPN or IP allowlisting.

What systems are affected by CVE-2026-59218?

This vulnerability affects the following AI/ML architecture patterns: self-hosted LLM chat UI platforms, model serving front-ends.

What is the CVSS score for CVE-2026-59218?

CVE-2026-59218 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.41%.

What is the AI security impact?

Affected AI Architectures

self-hosted LLM chat UI platformsmodel serving front-ends

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6 (Security)

NIST AI RMF: MANAGE 4.1

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, the /api/v1/auths/signin endpoint looked users up by email and only ran bcrypt password verification when a credential existed, making registered-account attempts measurably slower than missing-email attempts and allowing unauthenticated account enumeration. This issue is fixed in version 0.10.0.

Exploitation Scenario

An attacker targeting an organization that self-hosts Open WebUI for internal LLM access scripts repeated POST requests to /api/v1/auths/signin, cycling through likely corporate email addresses (harvested from LinkedIn, breach dumps, or naming conventions) with a fixed bogus password. By measuring response latency — slower responses indicate a bcrypt comparison ran, meaning the email is registered — the attacker builds a confirmed list of valid accounts without ever triggering a failed-login alert tied to a real user. That list is then handed off to a credential-stuffing run using leaked password dumps, or used to craft targeted phishing emails referencing the victim's known use of the internal AI platform, significantly improving the success rate of the follow-on attack.

Weaknesses (CWE)

CWE-208 Observable Timing Discrepancy Primary CWE-208 Observable Timing Discrepancy

CWE-208 — Observable Timing Discrepancy: Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.

Source: MITRE CWE corpus.