Security Policy

Ground Truth

This page is the authoritative version of the Open WebUI security policy. The GitHub Security Policy points here.

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	Yes
dev	No
others	No

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 (see table above) 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, and they in turn forfeit 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'd have to close as already-fixed.

Good-Faith Reports That Aren't Vulnerabilities

We truly appreciate every report made in good faith, even when it turns out not to be a vulnerability under our guidelines. Thank you for taking the time. A good-faith report that we close as out of scope never counts against you.

If you've found something that you know is not strictly a vulnerability under our policy, but where public disclosure would still be irresponsible (e.g. an urgent dependency bump needed because of a downstream vuln, or similar), 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 (e.g. ship the bump) and keep the report confidential until handled. Where a fix lands as a result of your report and you'd like credit, we'll try to acknowledge you (e.g. as a co-author on the change).

What a Valid Report Gets You

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

• Credit on the advisory. You're 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 won't publish out from under you while you're 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 ~2 weeks after the patched release so administrators can update before details are public.

What we can't offer is a bounty or a guaranteed turnaround. What you get is a serious fix, honest credit, and a process that treats your work as the contribution it is.

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.

Our security process is built around the same transparency as the rest of our work, and GitHub Security Advisories is the single authoritative channel where that process lives. We do not and cannot 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 for determining who filed first.

Reporting Guidelines

We appreciate the community's interest in identifying potential vulnerabilities! If you want to report something that does not fulfill our rules and guidelines laid out here, you can still report it and we will handle it, see our good faith reporting section for more information.

We do not accept low-effort vulnerability reports. Ensure that submissions are constructive, actionable, reproducible, well documented and adhere to the following guidelines:

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: Reports must reflect a clear understanding of the codebase, 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 (PoC) that demonstrates the vulnerability. 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.

note

A PoC (Proof of Concept) is a demonstration of exploitation of a vulnerability. Your PoC must show:

1. Exactly which security boundary was crossed
2. How this vulnerability is triggered/abused (inputs, endpoints, UI actions, etc.)
3. What actions the attacker can now perform
4. Exact steps and commands to reproduce (copy/paste runnable where possible), expected result vs. actual result

5. Remediation is required:

Along with the PoC, you must provide either:

1. a remediation plan (i.e. "actionable steps" that a maintainer can apply), or
2. 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.)
• 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, unless they are covered by the following exception:

note

If you believe you have found a security issue that

1. affects default configurations, or
2. represents a genuine bypass of intended security controls, or
3. 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 in your report. If you leave the CVSS section empty, we will fill it out for you prior to publishing. If you include a CVSS score with your report, it must accurately reflect the vulnerability according to CVSS methodology. In case of inaccurate CVSS, we will adjust the CVSS score of your report. 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, apps, functions), pasting untrusted code into Functions/Tools, or intentionally weakening security settings. Reports requiring admin negligence or social engineering of admins may be rejected.

note

Similar to rule "Default Configuration Testing": 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, malicious plugins being deployed by admins and similar malicious actions, not to discourage legitimate security research.

10. Tools & Functions Code Execution Is Intended Behavior: Tools and Functions execute user-provided Python code on the server with the same access as the Open WebUI backend. This is core, intended functionality (see 'Threat Model Understanding'). Only administrators can create Functions. Creating Tools needs the workspace.tools permission, which is off by default for non-admin users. Granting it is equivalent to giving shell access to the server, so granting it to an untrusted user is a misconfiguration covered by 'Admin Actions Are Out of Scope'. Reports describing any attack chain through Tools or Functions (code execution, file access, network requests, environment variable access, frontmatter pip install and the like) are closed as intended behavior. Deployments that do not need them can switch them off with ENABLE_PLUGINS and the related switches.

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. The supported replacement is the migration target, and security and functional work happens on the 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.

note

If you find a security issue that:

1. exists on a legacy code path and also on the supported modern replacement, OR
2. exists on a legacy code path and the legacy path is the only documented way to achieve a given function (no migration target exists yet)

we still want to hear about it. This rule is intended to filter reports that target deprecated paths with a documented modern alternative, not to discourage finding real bugs in paths users are still on.

12. AI report transparency: Tell us if AI helped in any way: finding the vulnerability, writing the report or building the PoC. AI-assisted reports are handled exactly like every other report; we just want to know.

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.

note

This rule is about who is harmed, not about severity. A user modifying or deleting their own data, impairing their own session, observing their own configuration, or disabling security controls on their own account is out of scope under this rule, regardless of impact.

If the same action also affects another user, the operator, the host system, or shared resources, identify that second party clearly in the PoC, and we want to hear about it.

Submissions that do not follow these guidelines may be closed. Only reporters who repeatedly or deliberately ignore them may be barred from submitting reports; honest mistakes and good-faith reports never count toward this. Our goal is to foster a constructive reporting environment where quality submissions promote better security for all users. If you want to report something that does not fulfill our rules and guidelines laid out here, you can still report it and we will handle it, see our good faith reporting section for more information.

Expected Timeframe

Security reports are prioritized alongside all other project work, and report volume is very high. Expect several weeks before a report is seen, analyzed, triaged and fixed, with stretches of silence along the way. Silence does not mean your report was ignored; it has not been picked up yet. If you think it was lost, feel free to post a follow-up comment on the advisory.

Once the fix is released, we request the CVE ID from GitHub and publish the advisory as soon as it is assigned. GitHub currently takes about four weeks or longer to assign an ID; see CVE Assignment Before Publication for why we wait. For findings with broad or severe real-world impact (regardless of CVSS score), we may hold publication until about two weeks after the patched release so administrators can update.

All durations on this page are estimates. A report can move faster when things line up, or slower when something gets in the way.

We do not accept reporter-imposed publishing deadlines. We coordinate disclosure on our own schedule, and we will triage, fix, and publish as fast as we reasonably can. Externally-imposed hard timelines do not speed this up. They do the opposite: they pull our time away from actually fixing issues and toward managing a clock, at the expense of every other report (even ones that might be more serious) in the queue and the project as a whole. A deadline attached to your report will not change when or how fast it is handled.

CVE Assignment Before Publication

We publish a security advisory only after GitHub has assigned its CVE ID. GitHub is the CVE Numbering Authority (CNA) for the CVEs we request through GitHub Security Advisories. Once an advisory is fixed and ready, we request its CVE, and the advisory stays unpublished until the ID is assigned. At GitHub's current assignment speed, this delays the publication of every Open WebUI advisory by about four weeks or longer.

Before this rule we requested the CVE and published the advisory right away. The issue was already fixed in a release, and publishing is what tells administrators which versions are affected: the advisory feeds the GitHub Advisory Database and Dependabot alerts. GitHub attached the CVE ID later.

What happened. On 27 and 28 September 2026 we published 19 advisories this way, and the CVE requests sat pending at GitHub for weeks. On 2026-10-12 VulnCheck, another CNA, published its own CVE records for all 19, and GitHub then declined our requests as duplicates. We read a CVE requested by the code owner through GitHub Security Advisories as within GitHub's scope; GitHub and VulnCheck read GitHub's scope as covering it only when no other CNA's scope does. Either way, nobody contacted us before the records were assigned. Coordinated disclosure depends on a CNA contacting the vendor before it assigns, and VulnCheck did not. Its records replaced the titles of our advisories with VulnCheck's own, which they still carry, and listed the wrong credits on 16 of the 19 and wrong weakness types or scores on several until VulnCheck corrected them after we disputed them. The copies that entered the GitHub Advisory Database were worse: unreviewed entries whose title is the description cut off mid-sentence, with no ecosystem, no affected package and no affected or patched versions. A month after publication not one of them had triggered a Dependabot alert, so administrators running an affected version had not been warned at all.

We do not accept other CNAs minting CVEs for Open WebUI, because we cannot rely on them to get the records right: our Vendor Dispositions list the records other CNAs minted that had to be rejected, and VulnCheck's 19 records were wrong as described above. A CVE assigned by GitHub is built from the advisory we wrote and enters the GitHub Advisory Database as a reviewed entry with the affected package and versions, so Dependabot can warn every affected deployment from the day the advisory is published. Holding publication until GitHub has assigned the ID leaves no window for another CNA to mint first. An advisory reaches administrators a few weeks later, but complete, with no missing information and with correct data and metadata, written and verified by us, the reporter and GitHub as the CNA.

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, and the first-filer rule is what limits it.
3. A distinct finding DOES earn shared credit. If your report adds something the earlier filing does not cover (a different vector, a different affected component or a different sub-path), you are credited on the same advisory next to the first reporter, as the consolidation rule above describes. Only a report of the identical issue counts as a duplicate.

Confidential Disclosure

Vulnerability reports submitted through GitHub Security Advisories are private and confidential. Generally: Public disclosure of ANY details is STRICTLY PROHIBITED until an advisory for the vulnerability has been fully published, meaning the advisory itself is publicly visible. A CVE ID being assigned is not enough.

This prohibition applies to every channel and every third party, including but not limited to:

• comments on pull requests, issues or discussions, on GitHub or elsewhere;
• social media, chat servers and forums (Discord, Reddit, X or any other platform);
• blogs, write-ups, talks, papers and newsletters;
• mailing lists, vulnerability databases, bug bounty platforms and vulnerability brokers;
• any other organization, including requests to it for a CVE ID or any other identifier for the issue;
• any other website or service.

This confidential, responsible disclosure process exists to give us time to fix bugs, publish fixes and alert users once a fix is ready. The entire premise of responsible disclosure is to protect users from vulnerabilities. Therefore, 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.

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 any 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.

This rule exists because the cost of these escalations is not symmetric. An identifier can be minted in days, and removing an inaccurate one takes months of correspondence across the issuing CNA, the CVE Program and every downstream database that mirrored it, with none of that effort falling on the party that created the record. For the full reasoning, and the record of what these escalations have actually cost, see The CVE System and Why This Page Exists.

For Non-Vulnerability Related Security Concerns

You can use the following channels:

• Documentation issues/improvement ideas: Open an issue on 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
• Bugs: Report bugs to our Issue Tracker
• Best-practice guidance: Help expand the Documentation.

We regularly audit our internal processes and system architecture for vulnerabilities using a combination of automated and manual testing techniques.

For any other immediate concerns and questions, please create an issue in our issue tracker or contact our team on Discord.

Tools, Functions, and Pipelines Security

Tools, Functions and Pipelines execute arbitrary Python code on your server with the same access as the Open WebUI backend: files, network, subprocesses, environment variables and the database. This is intentional. Reports about them are handled under rule 10 of the Reporting Guidelines. An attacker who can already write to the data volume, where installed plugins are stored, is outside the threat model too. For safe use, see the Plugin Security warning and the Hardening Guide.

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 does not revoke the JWT token of that session. It remains valid until it expires (default: 4 weeks). Password changes and an administrator's Sign out all devices end every session of an account with or without Redis. 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.

---

Last updated on 2026-11-07.