Security
How Open WebUI approaches security, and how to report vulnerabilities responsibly.
Open WebUI takes the security and confidentiality of user data seriously. Our technical architecture and development processes are designed to minimize vulnerabilities and uphold the trust our stakeholders place in us. Regular assessments, codebase vetting, and systematic adoption of best practice methodologies help keep security a central part of our project lifecycle.
Security Policy
Rules of engagement for vulnerability reporting, disclosure, and resolution.
Everything you need to know before submitting a security report: supported versions, reporting guidelines, expected response times, confidential disclosure requirements, and what is (and isn't) considered a vulnerability.
| Reporting guidelines | What qualifies, what doesn't, and how to submit |
| Response timeframe | What to expect after submitting a report |
| Confidential disclosure | Rules around public disclosure timing |
| Plugin security | Security implications of Tools, Functions, and Pipelines |
| Production hardening | Key considerations for production deployments |
Supply Chain and Security Scanners
Our position on automated supply-chain scanner flags (socket.dev and similar tools).
Automated scanners flag Open WebUI's packages with behavioral risk indicators and unconfirmed classifications. This page explains why none of them represent a named vulnerability or malicious code, and answers the common "code execution without sandboxing" question directly: the default is sandboxed.
| Heuristics, not findings | Why capability flags are not vulnerabilities |
| Unconfirmed classifications | The "potential malware" banner, explained |
| Sandboxed by default | Pyodide WASM default; server-side execution is opt-in |
Read Supply Chain and Security Scanners →
Rejected CVEs in Vulnerability Databases
Several vulnerability databases and endpoint-security products do not reprocess CVE withdrawals, so identifiers the issuing CNA has formally rejected keep displaying as active findings against Open WebUI. This page records which databases are affected, every contact attempt and its outcome, and how to check any record against the authoritative state at cve.org in seconds.
Read Rejected CVEs in Vulnerability Databases →
Chat Data Privacy & Encryption
How Open WebUI stores chat data and which controls reduce exposure.
This guide lists concrete controls for reducing chat-data exposure, including database encryption, admin access toggles, temporary chats, private models, logging choices, and separate deployments for sensitive teams.
| Encryption status | What is protected in transit and at rest |
| Admin visibility | What product toggles reduce and where infrastructure trust begins |
| Enterprise guidance | Recommended settings for sensitive internal deployments |
| Practical controls | Concrete configuration measures to reduce access and retention |
Read Chat Data Privacy & Encryption →
Vendor Dispositions
Our formal assessments of externally reported CVEs and security claims.
When a CVE is filed against Open WebUI that we believe is inaccurate, mischaracterized, or does not represent a genuine vulnerability within our threat model, we publish a detailed vendor disposition. Each disposition explains our assessment, the reasoning behind it, and, where applicable, any actions taken.
| Formal assessments | Detailed analysis of each disputed report |
| Threat model context | How claims map to Open WebUI's architecture |
| Resolution status | Whether a report was accepted, disputed, or rejected |
Known & Accepted Risks
Residual risks we have mitigated as far as is technically possible, then formally accepted.
Some weaknesses cannot be fully eliminated in application code, because they are bounded by the language, runtime, operating system, CPU or network rather than by a defect we can patch. We shrink the exploitable portion as far as possible and document the remainder here, with the reasoning and how it fits our threat model.
| Mitigated as far as possible | What we changed to reduce each risk |
| Why the residual stays | The language, OS, CPU or network limits that prevent a full fix |
| Threat-model context | Why the residual is accepted rather than treated as a defect |