CVE-2026-59218 Open WebUI User Enumeration Vulnerability

Technical summary

The /api/v1/auths/signin endpoint in Open WebUI prior to version 0.10.0 performs user lookup by email address before validating the password. Because bcrypt verification only runs when a matching user record exists, the authentication logic exhibits a timing side-channel: registered accounts incur the computational cost of password hashing and comparison, while requests for non-existent emails skip that step entirely. An unauthenticated attacker can exploit this measurable latency difference to enumerate valid email addresses in the system. CWE-208 (Observable Timing Discrepancy) classifies this category of flaw. The vulnerability is resolved in version 0.10.0, which implements constant-time comparison or similar mitigations.

Business impact

User enumeration undermines the confidentiality of your user base. An attacker can systematically discover which email addresses are registered, enabling targeted phishing campaigns, password spray attacks, or social engineering. While this vulnerability does not grant direct system access or data exfiltration, it significantly reduces the attacker's reconnaissance effort and increases the surface for downstream attacks. Organizations hosting Open WebUI as an internal or customer-facing platform should consider the sensitivity of their user roster when prioritizing remediation.

Affected systems

Open WebUI open_webui versions prior to 0.10.0 are affected. Self-hosted deployments of Open WebUI running older versions are at risk. The vulnerability is network-accessible and requires no authentication, making it exploitable by any remote actor. Verify your installed version via the application version string or deployment logs.

Exploitability

Exploitation is straightforward and requires only network access to the /api/v1/auths/signin endpoint. An attacker can craft repeated sign-in requests with candidate email addresses and measure response latencies to infer user existence. No authentication, complex interaction, or user interaction is required. Reliable exploitation depends on network conditions and server load, but under normal circumstances the timing difference should be discernible. This vulnerability is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog, but the low barrier to exploitation means defensive measures should not be delayed pending evidence of active attacks.

Remediation

Upgrade to Open WebUI version 0.10.0 or later. Verify the upgrade by checking the application version in the UI or deployment artifacts. For organizations unable to upgrade immediately, consider network-level mitigations: restrict access to the /api/v1/auths/signin endpoint to known IP ranges or behind a VPN, implement rate limiting on authentication requests, or deploy a Web Application Firewall (WAF) to detect and throttle repeated authentication attempts from the same source.

Patch guidance

Upgrade Open WebUI to version 0.10.0 or later. Review your deployment method (Docker, Kubernetes, package manager, etc.) and follow the official Open WebUI upgrade documentation to ensure a smooth transition. Test the upgrade in a non-production environment first if feasible. After upgrading, verify the new version is running by checking the application version string and confirming the sign-in endpoint behavior has changed.

Detection guidance

Monitor authentication logs for patterns consistent with user enumeration: repeated rapid requests to /api/v1/auths/signin from a single source IP with varying email addresses. Implement timing-based detection at the network level by tracking response time distribution for sign-in requests; legitimate users will show variable latencies, whereas enumeration attempts often exhibit systematic timing patterns. Consider deploying a SIEM rule that flags bulk failed authentication attempts grouped by source IP. Analyze access logs for sign-in endpoint activity, particularly sequences of requests with different email addresses over short time windows.

Why prioritize this

Although this is a MEDIUM-severity vulnerability (CVSS 5.3), it should be prioritized for rapid remediation because user enumeration is a precursor to account compromise and social engineering. The fix is contained in a single version bump with no expected breaking changes. The exploitability is trivial, and the vulnerability is network-accessible without authentication barriers. In environments where user identity confidentiality is important (customer-facing platforms, internal systems with sensitive user roles), upgrade urgency increases.

Risk score, explained

CVSS 5.3 (MEDIUM) reflects the vulnerability's limited direct impact: it discloses user existence but does not enable data breaches, code execution, or denial of service. The score factors in network accessibility (AV:N) and low attack complexity (AC:L), indicating ease of exploitation, but gives lower weight to the confidentiality impact (C:L) because exposure is limited to email address presence. Integrity and availability are unaffected (I:N, A:N). Organizations should not underestimate this score in their risk calculations; timing-based enumeration often serves as the opening move in multi-stage attacks.

Frequently asked questions