Skip to main content

Security Policy

Ground Truth

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

Our goal is to protect Open WebUI's users and their data, and to handle security reports with a clear, consistent, and publicly documented process. We want to operate a transparent security process, in which accepted vulnerabilities are published openly as advisories so anyone can see what was found, how it was resolved and most importantly, which version contains a patch for it.

Our stance: a visible advisory history is evidence of active scrutiny and a disclosure process that works, not a measure of how fragile the software is.

Our technical architecture and development processes are designed to minimize vulnerabilities and uphold the trust our stakeholders place in us. We employ a mixture of automated and manual techniques to keep up with evolving threats, with a focus on proactive risk management and responsible handling of any vulnerabilities reported.

Supported Versions​

Version (Branch)Supported
main✅
dev❌
others❌

If an issue is already fixed, or already being fixed in the open, at the time you file, the report will not be accepted. It did not contribute to discovering or remediating the issue, and we will not publish an advisory for it. A fix counts as already-existing regardless of which branch it lives on (including dev) and regardless of whether it was silently resolved in an earlier version. Branch support status governs where a vulnerability must be reproducible, not whether a fix already exists: a bug live in a supported branch but already fixed in dev is still an already-fixed issue under this rule.

Two specific patterns this covers, both of which we reject:

  • Filing a report for a bug found in an older version that was already resolved by the time of the current supported version.
  • Monitoring our public commits or pull requests and filing a report for an issue they already address or fix. We have observed automated monitoring of our public commits and PRs that produced reports against fixes others had already authored; this rule exists to reject that pattern.

We need not decide whether you discovered the issue independently. We cannot, and it makes no difference. On the provable facts your report duplicates work that is already public and already fixed or being fixed; you filed strictly last, and there is no way to distinguish independent discovery from scraping. Credit for the issue belongs to whoever found or fixed it, who in turn forfeits their own claim to it by disclosing publicly instead of reporting it to us confidentially first. A publicly-disclosed fix therefore earns no advisory, and no credit for anyone.

tip

Before reporting, check whether your finding still reproduces on the dev branch (and any other active development branch). We develop in the open, and a fix may already be committed there ahead of a release. Confirming this first saves you the effort of writing up a report we would have to close as already-fixed.

Good-Faith Reports That Aren't Vulnerabilities​

If you have found something that you know is not strictly a vulnerability under this policy, but where public disclosure would still be irresponsible (for example, an urgent dependency bump needed because of a downstream vulnerability), you may still report it privately via GitHub Security Advisories. We will handle it responsibly.

In line with the CVE rules, we will not publish an advisory or mint a CVE for these, but we will act on them (for example, ship the bump) and keep the report confidential until it is handled. Where a fix lands as a result of your report and you would like credit, we will try to acknowledge you (for example, as a co-author on the change).

What a Valid Report Gets You​

If your report describes a real vulnerability under this policy, here is what you can expect from us:

  • Credit on the advisory. You are named as the reporter on the published advisory. Where multiple reporters each demonstrated a distinct vector, every one of you is credited (see Report Handling).
  • Coordinated disclosure. We will not publish out from under you while you are still working the issue with us. Status moves visibly on the advisory itself, including the CVE request, and GitHub notifies you of those updates, so you can follow it through to publication.
  • A real fix, handled responsibly. For findings with broad or severe real-world impact, we may hold publication for up to roughly two weeks after the patched release so administrators can update before details are public.

Open WebUI is led by a small core team with clear ownership of the security process. Valid reports receive serious review, real fixes, appropriate credit, and coordinated handling through the GitHub advisory record.

Alignment with the CVE Program​

The CVE Program rules (and CNA operational rules) are the baseline for all CVE handling here, and this policy operates within them. Under those rules, the determination of whether a report constitutes a security vulnerability in Open WebUI is the vendor's to make; this policy documents the criteria by which we exercise that determination. Where the rules are silent, they still apply; where this policy specifies how we apply them to Open WebUI, it does so as the vendor's published disposition criteria, not as a replacement for or exception to the program rules.

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 accept vulnerability reports only through GitHub Security Advisories. Reports submitted through any other platform, including but not limited to third-party vulnerability reporting platforms, vulnerability brokers, social media, email, Discord, or Reddit, will not be processed.

This is not a procedural preference. As a project led by a small core team, Open WebUI uses a single, authoritative reporting channel for security work, and GitHub Security Advisories is where that process lives. We do not monitor or engage with external reporting platforms, and reports arriving through them will be closed without review.

A report filed on another platform has no standing here: it confers no priority, establishes no filing date, and creates no obligation for us to triage, publish, or otherwise consider it. Only the GitHub Security Advisory record exists for the purposes of this policy, including determining who filed first.

Foreign CNAs and Vendor Disposition​

Based on multiple precedents of foreign CNAs minting CVEs without communicating the report to us prior to publication, and/or minting CVEs that do not withstand scrutiny, this rule was established.

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/not-a-vulnerability GHSA report to a third-party CNA after vendor disposition has been issued are likewise considered to have acted against vendor disposition, and may be barred from future GHSA submissions.

Reporting Guidelines​

You can find the authoritative version of these guidelines here.

We appreciate the community's interest in identifying potential vulnerabilities. If you want to report something that does not fulfill the rules and guidelines laid out here, you can still report it and we will handle it (see Good-Faith Reports That Aren't Vulnerabilities above). However, we will not accept low-effort vulnerability reports. Ensure that submissions are constructive, actionable, reproducible, well documented, and adhere to the following requirements:

Security boundaries: Throughout this policy, "the security boundaries" means the five we recognize: Confidentiality, Integrity, Availability, Authenticity, and Non-repudiation. We interpret these broadly: equivalent concepts from other security frameworks fall within them. A valid vulnerability must cross at least one of them against a party other than the reporter.

  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 of the security boundaries (defined above).

  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 how Open WebUI is used, 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 (1) exactly which security boundary was crossed, (2) how the vulnerability is triggered or abused (inputs, endpoints, UI actions, etc.), (3) what actions the attacker can now perform, and (4) exact steps and commands to reproduce (copy/paste runnable where possible), with expected result versus actual result. 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.

  5. Remediation is required: Along with the PoC, you must provide either a remediation plan (actionable steps a maintainer can apply) or a patch/PR. 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: 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, single-tenant, 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: You do not have to include a CVSS score. If you leave the CVSS section empty, we will fill it out for you prior to publishing. If you do include a CVSS score, it must accurately reflect the vulnerability according to CVSS methodology; we will adjust inaccurate scores. If you cite other CVEs to support your report, ensure they are genuinely comparable in vulnerability type, threat model, and attack vector.

  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, which is authoritative as to what is legacy. 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 usually 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 a spike in 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, but reports that do not declare AI use yet appear AI-aided will undergo severely more scrutiny.

  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 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 may be closed, and repeat or extreme violators may be banned. Our goal is to foster a constructive reporting environment where quality submissions promote better security for all users.

Expected Timeframe​

We aim to triage new reports, ship fixes, and publish advisories promptly. Reports are prioritized by validity, severity, reproducibility, and user impact, alongside releases and core project maintenance. Open WebUI is led by a small core team, and security reports are handled through that core process.

Please expect several weeks for your report to be triaged, investigated, fixed, and published. Status updates are posted on the advisory when there is material progress to report. The advisory remains the source of truth throughout triage, investigation, remediation, and publication.

We do not accept reporter-imposed publishing deadlines. Open WebUI sets disclosure timing based on validation, remediation, release coordination, and user impact. Externally imposed hard timelines do not change report priority, advisory timing, or release coordination. A deadline attached to your report will not change when or how fast it is handled.

For findings we judge to have broad or severe real-world impact, regardless of CVSS score, we may hold off on publishing for a couple of days, up to roughly two weeks after the patched version is released, to give administrators time to update their instances.

Report Handling​

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 on the consolidated advisory. Only one CVE will be issued for the consolidated advisory.

The other case: if you report a valid vulnerability that somebody else reported before you (identical vulnerability, identical exploitation vector), we will close your report as a duplicate. The earliest filing is the one we will handle going forward, and we will not publish multiple advisories for the same vulnerability.

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 (Discord, Reddit, or any other platform), blogs, forums, or any other 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.

If your concern is not a vulnerability but is still related to security, use the following channels instead:

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​

PracticeDescription
Only install from trusted sourcesOnly use Tools/Functions from the official community library or sources you trust
Review code before installingRead and understand what a Tool/Function does before importing it
Restrict Workspace accessOnly grant Workspace permissions to trusted administrators
Audit installed pluginsRegularly review installed Tools (Workspace → Tools) and Functions (Admin Panel → Functions)
Protect your data directoryThe /app/backend/data directory contains your database and cached plugins (protect it from unauthorized access)
Monitor resource usageWatch for unexpected CPU spikes that could indicate cryptomining or other abuse
Use official Docker imagesOnly 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.

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.