CVE-2026-0767
| CVE ID | CVE-2026-0767 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2026-01-23 |
| Issuing CNA | Zero Day Initiative (ZDI-26-033) |
| Claimed Severity | Medium (CVSS 5.3, CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) |
The claim is that credentials sent over plain HTTP are not encrypted. That is what plain HTTP means. It is true of every application that has ever exposed an HTTP interface, and it is not a property of this software.
Open WebUI is a backend that speaks HTTP. Whether TLS terminates at a reverse proxy, a load balancer or a managed platform is the operator's deployment decision, exactly as it is for every other backend. The record is functionally the statement "if an operator runs a web server without HTTPS, credentials travel in cleartext", which describes the operator's configuration rather than a defect in anything they installed.
Nothing in the record is specific to Open WebUI, and the identical sentence could be filed against any HTTP server in existence. It was nonetheless minted, scored as a confidentiality impact against this project, and published, where it still stands.
Timeline
This CVE has been withdrawn. The issuing CNA reviewed Open WebUI's analysis, agreed with its disposition, and set the record to REJECTED on 2026-09-02. The dispute is closed. The assessment below is the analysis the withdrawal rests on, kept published so that anyone still served this identifier by a downstream database can see why it no longer stands.
| Date | Event |
|---|---|
| 2025-10 | ZDI submits the underlying report through Open WebUI's security channel. Open WebUI closes it as out of scope and not a vulnerability under its published security policy, but does so without giving the reporter a written explanation at the time, which was a mistake on Open WebUI's part. |
| 2026-01-23 | ZDI publishes the CVE (ZDI-26-033). |
| 2026-05-04 | Open WebUI files a formal dispute with the CVE Program and notifies ZDI directly. Neither ZDI nor the CVE Program responds. |
| 2026-06-15 | Open WebUI files another dispute with the CVE Program; the Secretariat directs it to the issuing CNA (ZDI), which owns the record. The request is subsequently closed. |
| 2026-07-02 | With the CNA non-responsive, Open WebUI escalates the dispute a third time, to the CVE Program's Root / Top-Level Root under the CVE Record Dispute Policy (v2.0.0). |
| 2026-07-06 | Under the CVE Program's record-dispute procedure, the Program forwards the dispute to the issuing CNA (ZDI) for its determination. |
| 2026-07-08 | ZDI reviews Open WebUI's analysis and agrees with its disposition on this finding, and agrees to note the CVE as disputed/rejected with a reference to this page. |
| 2026-07-15 | Open WebUI follows up. The record still shows as PUBLISHED with no annotation. |
| 2026-07-21 | Open WebUI follows up again and asks the CVE Program to help bring the record to closure. ZDI replies the same day that it will respond and coordinate the record update later that week. |
| 2026-08-03 | Open WebUI follows up again. The record is unchanged. |
| 2026-08-08 | With no further movement from ZDI for over a month, Open WebUI returns to the CVE Program Root and asks it for closure. |
| 2026-08-14 | With no response to that request either, Open WebUI files a fresh request with the CVE Program for this record, asking it to carry out the update the CNA has already agreed to rather than reopening the dispute itself. |
| 2026-08-14 | The CVE Program follows up with the issuing CNA, asking whether it still intends to mark the record disputed or rejected. |
| 2026-08-18 | ZDI confirms it will update the record and reference this page in its advisory. |
| 2026-08-19 | ZDI asks what should change in the record. Open WebUI asks for the state set to REJECTED, a rejection reason naming plain HTTP rather than a product defect, and this page referenced on the record itself. |
| 2026-09-02 | ZDI sets the record to REJECTED, recording the behaviour being that of plain HTTP rather than a defect in the product as the reason and citing this page. |
The record now carries the REJECTED state at cve.org and at NVD, and its rejection reason states the basis and links to this page. Nothing further is outstanding with the issuing CNA or the CVE Program.
Downstream databases copy records at different times and some do not track state changes at all, so this identifier may still be presented as a live finding elsewhere. See Rejected CVEs in Vulnerability Databases for how to check any record yourself.
What the CVE Claims
User credentials (email and password) submitted to Open WebUI's login endpoint are transmitted in cleartext if the application is deployed over plain HTTP rather than HTTPS, allowing a network-adjacent attacker to intercept them.
Why This Is Not a Vulnerability
Nothing below rests on how Open WebUI draws its threat model or on where a security boundary is placed. It follows from what an unencrypted transport is, and it is equally true of every web application ever deployed without TLS.
This describes a property of the HTTP protocol, not a defect in Open WebUI. An unencrypted HTTP request is, by definition, not encrypted. This applies to every web application ever built.
Open WebUI is a backend application that exposes an HTTP interface. Whether that interface is exposed directly, behind a TLS-terminating reverse proxy, behind a load balancer with TLS, or via a managed platform, is the operator's deployment decision. The application does not, and is not expected to, mandate transport-layer configuration. The description is functionally equivalent to stating "if the operator deploys Apache HTTPD without HTTPS, login credentials are sent in cleartext", a true statement that does not constitute a vulnerability in Apache.
Severity
This is not scored as an Open WebUI vulnerability, because the exposure is a property of the operator's transport choice rather than of the application. The reporter's own vector reflects that: AV:A (adjacent network) and AC:H (high attack complexity) describe a scenario that requires both a plain-HTTP deployment and a network-adjacent interceptor, which does not arise behind conventional TLS termination. NVD's later enrichment re-scored the record to 6.5 with AC:L, but the determining condition is unchanged: the traffic is interceptable only if the operator runs Open WebUI over plain HTTP, a deployment choice rather than an Open WebUI defect.
GitHub Reached the Same Conclusion Independently
GitHub mirrors CVE records into its own advisory database, and reviews them before they drive Dependabot alerts. This record was looked at and deliberately not marked reviewed.
A maintainer of the GitHub Advisory Database put it plainly on 2026-09-02: this advisory and two others mirroring CVEs against Open WebUI were left unreviewed "due to concerns by teammates and I had about the validity of the vulnerabilities described in the CVE records". Unreviewed advisories raise no Dependabot alerts, so the record never reached anyone's dependency scan through that route.
Nobody at GitHub was asked to do that, and the decision was taken before the record was withdrawn. The other two cover CVEs from two different issuing CNAs, so the three span every CNA that has filed against Open WebUI. See Vendor Dispositions for all three.
Applicable Security Policy Rules
- Rule 1: Expected protocol behavior is not a vulnerability. HTTP's cleartext property is the textbook example.
- Rule 6: The scenario manifests only when the operator deploys without TLS, not a property of Open WebUI's default configuration.
- Rule 7: The report mischaracterizes a deployment-layer property as an application-layer defect.
Impact to Users
No action required, provided your deployment uses TLS. If you are running Open WebUI over plain HTTP in production, configure TLS termination via a reverse proxy, standard deployment hygiene for any web application, not a response to this CVE. See our HTTPS and Reverse Proxy Configuration guide.