📋 Security Policy

Ground Truth

The authoritative version of this policy lives in the GitHub Security Policy. This page is a summary of its key principles for quick reference. In case of any discrepancy, the GitHub version prevails.

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.

We employ a mixture of automated and manual techniques to keep up with evolving threats, and are continuously improving our approach, including plans to integrate advanced static and dependency analysis tools. Our focus is on proactive risk management and responsible handling of any vulnerabilities reported.

Supported Versions

Version	Supported
main	✅
dev	❌
others	❌

Where and How to Report Security Vulnerabilities

info

Open WebUI's community thrives because of people like you, people who care deeply about making software safer for everyone.

To ensure your findings truly help protect users and are addressed swiftly, please submit all security vulnerability reports only via our official GitHub security page. Any other website, service, or so-called "bounty" platform is not affiliated with us, and your important work will simply not reach those who can make a difference.

We know it can be tempting to trust platforms that make big promises, but only GitHub connects you directly to those safeguarding Open WebUI. Let's ensure your vigilance genuinely benefits the community, report here, where it really matters.

All security vulnerabilities for Open WebUI must be reported exclusively through our official GitHub repository: https://github.com/open-webui/open-webui/security.

All security vulnerability reports are managed exclusively through our official GitHub platform. Handling disclosures centrally on GitHub allows every report to be processed transparently, efficiently, and confidentially by the project maintainers. This approach provides contributors and users with visibility, accountability, and assurance that security-related communications and resolutions are thoroughly documented and reliably managed. Reports submitted through any platform, channel, or third-party service outside of GitHub cannot be incorporated into our official security workflow and, as a result, may not be able to contribute to the safety of Open WebUI.

Why Only GitHub?

Our approach of using a single, central reporting mechanism is rooted in both technical rigor and ethical stewardship:

• Integrity and Traceability: Managing reports solely via GitHub keeps every issue within the open-source ecosystem, where the community can verify the process, outcomes, and accountability of contributors.
• User Safety: Other websites claiming to facilitate vulnerability disclosure, offer rewards, or bounty programs are not affiliated with Open WebUI. Submitting vulnerabilities to such platforms not only fails to make the project safer but can unintentionally place sensitive details at risk of misuse or unauthorized disclosure.
• Protecting the Community: When information bypasses our centralized security workflow, the project becomes more susceptible not just to unfixed exploits, but also to the spread of misleading or exploitative practices. Despite claims by outside sites to act as intermediaries or pay bounties, these entities offer no guarantees to users and may encourage questionable or unsafe behavior under the guise of incentivization. Disclosures made via our GitHub are the only way your expertise can reliably benefit the entire ecosystem.

Zero Tolerance for External Platforms

We refuse to engage with, join, or monitor any platforms outside of GitHub for vulnerability reporting. Any reports or solicitations arriving from sources other than our designated GitHub repository will be dismissed without consideration. This policy is non-negotiable and understands no exceptions.

Foreign CNAs and Vendor Disposition

When a report is filed via GitHub Security Advisories and the maintainers close it as out-of-scope per this policy, that closure is the vendor's disposition of the issue. A CVE Numbering Authority (CNA) that mints a CVE for such an issue without reflecting that vendor disposition in the resulting record is acting against vendor disposition.

We respond to such records by:

1. Filing a REJECT request with the CVE Program (with DISPUTED as fallback)
2. Cataloging the record publicly in our Vendor Dispositions, naming the issuing CNA
3. Refusing to provide vendor statements, version mappings, fix references, or any other coordination that would lend authority to the record
4. Escalating repeated patterns from a single CNA to the CVE Program Root

Channel compliance does not entitle a CNA to override vendor disposition. Reporters who escalate a closed-as-out-of-scope report to a third-party CNA after vendor disposition has been issued will be permanently barred from future submissions.

Reporting Guidelines

You can find the latest version of the security guidelines here.

To ensure constructive, actionable reports that genuinely improve security, all submissions must meet the following requirements:

1. Report MUST be a vulnerability: A security vulnerability is an exploitable weakness where the system behaves in an unintended way, allowing attackers to bypass security controls, gain unauthorized access, execute arbitrary code, or escalate privileges. Configuration options, missing features, and expected protocol behavior are not vulnerabilities. A vulnerability must cross at least one security boundary (Confidentiality, Integrity, Availability, Authenticity, Non-repudiation). These boundaries are interpreted broadly; equivalent concepts in other security frameworks fall within them.

2. No Vague Reports: Submissions such as "I found a vulnerability" without any details will be treated as spam and will not be accepted.

3. In-Depth Understanding Required: Reports must reflect a clear understanding of the codebase and provide specific details about the vulnerability, including the affected components and potential impacts.

4. Proof of Concept (PoC) is Mandatory: Each submission must include a well-documented proof of concept that demonstrates the vulnerability. A PoC must show what security boundary was crossed (Confidentiality, Integrity, Availability, Authenticity, Non-repudiation), how this vulnerability was abused, and what actions the attacker can now perform. Valid PoCs include step-by-step reproduction instructions with exact commands, complete exploit code with detailed execution instructions, or screenshots/videos demonstrating the exploit (supplementary to written steps). If confidentiality is a concern, reporters are encouraged to create a private fork of the repository and share access with the maintainers. Reports lacking valid evidence may be disregarded. We will notify you if we struggle to reproduce the exploit using your PoC, but if we repeatedly cannot reproduce it, the report may be closed.

5. Remediation is required: Along with the PoC, you must provide either a patch/PR or a remediation plan (actionable steps) that a maintainer can apply without guesswork. Your remediation guidance can include, for example: the likely root cause (what's wrong and where), the location(s) to change (file/module/function names if known), the recommended fix approach (validation/sanitization rules, auth checks, safe defaults, etc.), and any security tradeoffs or potential regressions to watch for.

6. Default Configuration Testing: All vulnerability reports must be tested and reproducible using Open WebUI's out-of-the-box default configuration. Claims of vulnerabilities that only manifest with explicitly weakened security settings may be discarded. However, if you believe you have found a security issue that affects default configurations, represents a genuine bypass of intended security controls, or works only with non-default configurations but the configuration in question is likely to be used by production deployments, then we absolutely want to hear about it. This policy is intended to filter configuration issues and deployment problems, not to discourage legitimate security research.

7. Threat Model Understanding Required: Reports must demonstrate understanding of Open WebUI's self-hosted, authenticated, extensible, role-based access control architecture. Comparing Open WebUI to services with fundamentally different security models without acknowledging the architectural differences may result in report rejection.

8. CVSS Scoring Accuracy: If you include a CVSS score with your report, it must accurately reflect the vulnerability according to CVSS methodology. Common errors include rating PR:N (None) when authentication is required, scoring hypothetical attack chains instead of the actual vulnerability, or inflating severity without evidence. We will adjust inaccurate CVSS scores. Intentionally inflated scores may result in report rejection. If you cite other CVEs to support your report, ensure they are genuinely comparable in vulnerability type, threat model, and attack vector. Citing CVEs from different product categories, different vulnerability classes, or different deployment models will lead us to suspect the use of AI in your report.

9. Admin Actions Are Out of Scope: 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. This includes but is not limited to adding malicious external servers (models, tools, webhooks, functions), pasting untrusted code into Functions/Tools, or intentionally weakening security settings. Reports requiring admin negligence or social engineering of admins may be rejected. However, if you believe you have found a vulnerability that affects admins and is not caused by admin negligence or intentionally malicious actions, then we absolutely want to hear about it. This policy is intended to filter social engineering attacks on admins and similar malicious actions, not to discourage legitimate security research.

10. Tools & Functions Code Execution Is Intended Behavior: Open WebUI's Tools and Functions feature is designed to execute user-provided Python code on the server. This is core, intentional functionality — not a vulnerability. Function creation is restricted to administrators only. Tool creation is controlled by the workspace.tools permission, which is disabled by default for non-admin users and should only be granted to fully trusted users who are equivalent to system administrators in terms of trust. Granting a user the ability to create Tools is equivalent to giving them shell access to the server. More generally, reports describing ANY attack chain that involves Tools or Functions — including but not limited to code execution, file access, network requests, or environment variable access — will be closed as not a vulnerability / intended behavior. This applies to both direct code execution and frontmatter-based package installation (pip install).

11. Legacy Code Paths Are Out of Scope: Open WebUI maintains some code paths that are explicitly marked as legacy in the official documentation. Legacy paths remain available — sometimes still the default — purely for backwards-compatibility reasons, not because they are the supported or maintained surface. Security and functional work happens on the supported replacement, not the legacy path. Reports describing a security boundary issue on a legacy code path that does not also reproduce on the supported replacement are out of scope under this rule. We still want to hear about it if the issue reproduces on both the legacy path and the supported modern replacement, or if the legacy path is the only documented way to achieve a given function (no migration target exists yet).

12. AI Report Transparency: Due to an extreme spike in AI-aided vulnerability reports, you must disclose if AI was used in any capacity — whether for writing the report, generating the PoC, or identifying the vulnerability. AI-aided vulnerability reports will not be rejected by default. However, if we suspect you used AI but did not disclose it to us, we will be asking tough follow-up questions to validate your understanding of the reported vulnerability and Open WebUI itself. If we suspect you used AI but you did not disclose it and your report ends up being invalid, not a vulnerability, or not reproducible, then you may be banned from reporting future vulnerabilities. This measure was necessary due to the extreme rise in clearly AI-written vulnerability reports where the vast majority were not vulnerabilities, were faulty configurations rather than real vulnerabilities, did not provide a PoC, violated the rules outlined here, had a clear lack of understanding of Open WebUI, wrote comments with conflicting information, or used illogical arguments.

13. Self-Affecting Issues Are Not Vulnerabilities: A vulnerability requires crossing a security boundary that affects a party other than the reporter. Crossing one of the five recognized security boundaries only against the reporter's own data, account, session, or environment is not a vulnerability — it is a bug, and belongs in the Issue Tracker, not in a security report. If the same action also affects another user, the operator, the host system, or shared resources, identify that second party clearly in the PoC.

Non-compliant submissions will be closed, and repeat extreme violators may be banned. Our goal is to foster a constructive reporting environment where quality submissions promote better security for all users. Contributors who not only identify a vulnerability but also present a robust, ready-to-merge fix help accelerate our response and strengthen the community.

If you feel like you are not able to follow all outlined requirements for vulnerability-specific reasons, still do report it — we will check every report either way.

Expected Timeframe

Open WebUI receives a very high volume of vulnerability reports, issues, discussions, and pull requests — lately compounded by an unbelievably high number of AI-generated reports (see AI Report Transparency). The project is maintained by a small team, and security reports are handled alongside all other project responsibilities.

Please expect several weeks for your report to be triaged, investigated, fixed, and published. Periods of silence lasting weeks are normal and do not mean your report has been ignored — only that we have not yet had the capacity to address it. You will receive an acknowledgement once your report has been reviewed, followed by updates as the investigation progresses. If your report has been open without a response and you would like a status update, you are welcome to leave a comment on the advisory.

For findings we judge to have broad or severe real-world impact — regardless of CVSS score — we may hold off on publishing for 1–2 weeks after the patched version is released, to give administrators time to update their instances.

Report Handling

If you report a valid vulnerability that somebody else reported before you, we will close your report as a duplicate. The earliest filing of the vulnerability is the one we will handle going forward. We will not publish multiple advisories for the same vulnerability.

When multiple independent reporters describe the same vulnerability class but each demonstrates a distinct and separate exploitation vector — for example, the same missing authorization check reached through different endpoints — we will consolidate them into the earliest filing and credit every reporter who demonstrated a distinct path. Only one CVE will be issued for the consolidated advisory.

Why duplicate reports don't receive credit

We credit only the earliest filer of a given vulnerability:

1. The first report did the work. By the time a later report arrives, triage and fix are already in motion. Later reports don't change the outcome or timeline; crediting them would misrepresent what moved the fix.
2. Credit-for-duplicates incentivizes flooding. If similar-but-later filings earn credit, the rational play is to skim open advisories and file variations. We already see this pressure — the first-filer rule is what limits it.
3. Co-discovery is different from duplication. Multiple reporters are credited on one advisory when each contributes a distinct finding — different vector, different affected component, different sub-path the earlier filing does not cover. That is the consolidation rule above. Filing a duplicate of an existing report is not co-discovery.

Confidential Disclosure

Vulnerability reports submitted through GitHub Security Advisories are private and confidential. Public disclosure of ANY details related to a submitted vulnerability report is STRICTLY PROHIBITED until the advisory has been fully published — not merely when a CVE ID has been assigned, but when the advisory itself is publicly visible.

This prohibition applies to all channels, including but not limited to:

• Comments on pull requests, issues, or discussions (on GitHub or elsewhere)
• Social media, blogs, forums, or any other website
• Discord, Reddit, or any other platform, website or service

Premature disclosure undermines the security of all Open WebUI users and violates the trust inherent in the responsible disclosure process. Reporters who prematurely publicly disclose vulnerability details before official publication WILL BE PERMANENTLY BANNED from future reporting.

For Non-Vulnerability Related Security Concerns

If your concern does not meet the vulnerability requirements outlined above, is not a vulnerability, but is still related to security concerns, then use the following channels instead:

• Documentation issues/improvement ideas: Open an issue in our Documentation Repository
• Feature requests: Create a discussion in GitHub Discussions - Ideas to discuss with the community if this feature request is wanted by multiple people
• Configuration help: Ask the community for help and guidance on our Discord Server or on Reddit
• General issues: Use our Issue Tracker

Examples of non-vulnerability, still security-related concerns include suggestions for better default configuration values, security hardening recommendations, deployment best practices guidance, unclear configuration instructions, need for additional security documentation, feature requests for optional security enhancements (2FA, audit logging, etc.), and general security questions about production deployment. Please use the adequate channel for your specific issue.

Tools, Functions, and Pipelines Security

Open WebUI provides powerful extensibility through Tools, Functions (including Pipes, Filters, and Actions), and Pipelines. These features allow you to extend Open WebUI's capabilities with custom Python code. However, this power comes with security responsibilities. Each of the following documentation pages contains its own security warnings — review them for the full picture:

• Plugin Security Overview — critical security warning, trust model, and Workspace access restrictions
• Tools — security warnings for Tool creation, import, and workspace.tools permissions
• Functions — admin-only creation, code execution warnings
• Pipelines — arbitrary code execution warning for the Pipeline plugin system

warning

Tools, Functions, and Pipelines execute arbitrary Python code on your server. This is intentional — it's what makes them powerful. However, this means they have the same level of access as the Open WebUI backend process itself.

Security Implications

When you install a Tool, Function, or Pipeline, you are granting it the ability to:

• Access the file system — read or write any files the backend process can access
• Make network requests — connect to external services, potentially exfiltrating data
• Execute system commands — run shell commands via subprocess
• Access environment variables — read API keys, secrets, and configuration
• Modify the database — access or alter stored data
• Consume compute resources — run CPU-intensive operations

Best Practices

Practice	Description
Only install from trusted sources	Only use Tools/Functions from the official community library or sources you trust
Review code before installing	Read and understand what a Tool/Function does before importing it
Restrict Workspace access	Only grant Workspace permissions to trusted administrators
Audit installed plugins	Regularly review installed Tools (Workspace → Tools) and Functions (Admin Panel → Functions)
Protect your data directory	The /app/backend/data directory contains your database and cached plugins — protect it from unauthorized access
Monitor resource usage	Watch for unexpected CPU spikes that could indicate cryptomining or other abuse
Use official Docker images	Only pull from ghcr.io/open-webui/open-webui or openwebui/open-webui (Docker Hub) — unofficial images may be compromised

What Is NOT a Vulnerability

The following scenarios are not considered vulnerabilities because they require administrator action (see also Admin Actions Are Out of Scope and Threat Model Understanding in the reporting guidelines above):

• An admin installing a malicious Tool or Function
• An admin granting Workspace access to an untrusted user
• An admin importing code from an untrusted source
• An attacker with write access to the data volume injecting malicious plugins

More generally, reports describing ANY attack chain that involves Tools or Functions — including but not limited to code execution, file access, network requests, or environment variable access — will be closed as not a vulnerability / intended behavior. If an administrator grants Tool permissions to untrusted users, this constitutes intentional misconfiguration.

These scenarios represent admin negligence or environment compromise, not vulnerabilities in Open WebUI itself. See our Security Policy and the Plugin Security documentation for details.

Production Deployment Security

Open WebUI is designed for private, trusted networks and ships with defaults optimized for ease of setup. Production deployments handling sensitive data should review the Hardening Guide for a comprehensive checklist.

A key consideration: without Redis, signing out and password changes do not revoke existing JWT tokens — they remain valid until they expire (default: 4 weeks). This means compromised tokens cannot be invalidated, and admin-initiated account deactivation does not immediately block access. For production deployments, either configure Redis or shorten JWT_EXPIRES_IN to limit the window of exposure. See Token Revocation for details.

Product Security Process

• Internal and periodic external reviews of our architecture and pipelines
• Automated and manual testing for both front-end and back-end
• Proactive risk management and code reviews as part of ongoing development
• Continuous improvements and integration of advanced tooling for static/dynamic analysis

If you have an immediate and actionable security concern, please create a report in our security advisory portal or issue tracker.