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 |
📄 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 |