CVE-2025-29446
| CVE ID | CVE-2025-29446 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2025-04-21 |
| Issuing CNA | MITRE, from a public disclosure |
| Claimed Severity | Low (CVSS 3.3, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) |
The issuing CNA has withdrawn the record, so the official CVE entry now carries the REJECTED state and NVD and downstream feeds inherit it. The public record now matches Open WebUI's vendor disposition below, confirming our assessment that this was not a genuine vulnerability. There is no advisory and no affected Open WebUI release.
Timeline
| Date | Event |
|---|---|
| 2025-04-21 | CVE-2025-29446 published by MITRE, derived from a public disclosure. |
| 2026-05-04 | Open WebUI files a formal dispute with the CVE Program. The dispute goes unanswered. |
| 2026-05-05 | Open WebUI publishes this disposition, rejecting the report as not a vulnerability. |
| 2026-06-13 | Open WebUI files a dispute with NVD; NVD declines to adjudicate and directs the dispute to the CVE Program. |
| 2026-06-15 | Open WebUI files another dispute with the CVE Program; MITRE, as the issuing CNA, reaches out to the original researcher. |
| 2026-06-29 | The issuing CNA withdraws the record. The official CVE record state becomes REJECTED. |
Our disposition rejected this report on 2026-05-05. The issuing CNA followed later: on 2026-06-29 the record was formally withdrawn, so the official CVE record now carries the REJECTED state, which NVD and downstream feeds inherit. The public record now matches the position we had already taken, and there is no advisory or affected Open WebUI release. The CNA's published rejection reads:
DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
Disclosure Pathway
No report corresponding to this CVE was filed through the project's official reporting channel (GitHub Security Advisories). The issue was instead published publicly, with a proof-of-concept, on 2025-03-01, roughly seven weeks before the CVE was assigned on 2025-04-21.
Our Confidential Disclosure policy asks reporters not to publish vulnerability details before a fix and advisory are available. This exists to protect users and deployments: releasing a working proof-of-concept before operators have a fix to apply opens a window in which live instances are exposed with no remedy available, which is precisely the harm coordinated disclosure is meant to prevent. A report that had already been published in full before reaching us would not be accepted through our process for that reason. This is a point about disclosure conduct, not about the validity of the CVE: this record is rejected on the substance above, an admin-only endpoint behaving as designed, and the disclosure pathway is noted only to record that the project's coordinated process was never engaged.
What the CVE Claims
The verify_connection function in backend/open_webui/routers/ollama.py performs an outbound HTTP request using a URL string supplied by the caller, without sufficient URL validation, allowing the URL parameter to point to internal services (SSRF). The reported PoC sends POST /ollama/verify with a body such as {"url":"http://attacker/?id=1' or 1=1 -- #","key":""}, where the trailing # truncates the appended /api/version path, causing the server to make an arbitrary GET request to the attacker-supplied URL.
Why This Is Not a Vulnerability
The endpoint POST /ollama/verify is gated by a Depends(get_admin_user) authentication dependency. It is reachable only by administrators. Its sole purpose is to allow the administrator to verify that an Ollama model server URL, which the administrator themselves has just configured, responds correctly.
The "Attacker" Is the Administrator
The "attacker" in the cited scenario is the administrator entering a URL into a settings field that they own. The administrator can, of course, point the URL at internal services (that is the entire purpose of configuring a model server URL) but doing so does not constitute crossing a privilege boundary. There is no path by which an unprivileged user can reach this endpoint.
The same pattern (admin-authenticated outbound URL probe to verify a configured integration endpoint) is present in analogous router files for other model-provider integrations. None of these are reachable by unprivileged users.
Applicable Security Policy Rules
- Rule 9: "Vulnerabilities that require an administrator to actively perform unsafe actions are not considered valid vulnerabilities. Admins have full system control and are expected to understand the security implications of their actions and configurations."
Impact to Users
No action required. The cited endpoint is accessible only to administrators and serves its intended purpose of verifying admin-configured model server URLs.