Open WebUI Has 35 Security Advisories. Is 0.11.1 Enough?

August 4, 2026

Thirty-five Open WebUI advisories cover account takeover, internal-network access, credential forwarding, data disclosure, cross-user actions, denial of service, and permission bypasses.

Yes—Open WebUI operators should move to version 0.11.1 or later after taking a verified backup. Seventeen security advisories published on August 4 include account-takeover paths, ways to reach internal services, cross-user file disclosure and deletion, permanent chat deletion, denial-of-service paths, and authorization failures. Eighteen more advisories reviewed on September 9 and 10 add three same-origin or OAuth account paths, four internal-network or credential-forwarding paths, knowledge and chat authorization failures, and availability failures involving chats, folders, calendars, and OIDC. Upgrading is still not the whole answer for deployments that enabled OAuth token exchange: that feature also needs a trusted-client configuration or must stay disabled.

Updated September 10, 2026: eighteen newly reviewed upstream advisories were added in place instead of publishing a near-duplicate. Seventeen identify Open WebUI 0.11.1 as the fixed boundary; an older OAuth policy-bypass range was fixed in 0.9.0.

The Short Answer

GitHub's reviewed advisory database published seventeen Open WebUI vulnerabilities between 19:40 and 20:58 UTC on August 4, 2026. Six are rated high severity, ten medium, and one low. Three additional medium-severity advisories appeared late September 9, followed by six high- and nine medium-severity records on September 10. The affected branches reach back across multiple releases: 0.11.0 contains the fixes for the original seventeen, while 0.11.1 is the fixed boundary for seventeen of the eighteen newly reviewed issues. The remaining OAuth policy-bypass record affects versions before 0.9.0.

The alarming headlines need configuration context:

Those conditions matter, but they are not reasons to delay patching. They are the difference between "every default installation was compromised"—which the evidence does not show—and "multiple real trust boundaries failed in supported configurations"—which the advisories do show.

September 10 Update: Eighteen More Advisories Expand The Record

GitHub reviewed three additional upstream Open WebUI advisories late on September 9. All three identify version 0.11.1 as the fixed boundary:

Eight more reviewed records appeared at about 15:09-15:10 UTC on September 10:

Seven additional reviewed records appeared between 21:23 and 23:04 UTC on September 10. Their affected ranges all end before 0.11.1 or at 0.11.0:

These records do not report exploitation. They do change the remediation answer: 0.11.0 is no longer the current all-advisory security boundary. Operators who upgraded for the August disclosures should move again to Open WebUI 0.11.1 or later.

Who This Is For

This guide is for:

The key lesson is broader than one release: the model, web interface, authentication system, browser renderer, internal network, tools, and data store are separate security boundaries. Running model weights locally controls only part of that system.

What Is Confirmed

1. Seventeen advisories were published on August 4

The upstream Open WebUI project published detailed GitHub security advisories covering seventeen distinct issues. They include affected versions, preconditions, proof-of-concept descriptions, root causes, fixes, and credits. The first eight appeared between 19:40 and 20:02 UTC. Nine more appeared between 20:35 and 20:58 UTC, after the first version of this article had been researched.

Open WebUI's security policy says accepted vulnerabilities are published so operators can see what was found and which version contains a patch. A visible advisory history is evidence of an active disclosure process; the number of advisories alone is not proof that exploitation occurred.

At selection time, the public Open WebUI repository had roughly 147,800 GitHub stars. That large installed and interested audience makes a same-day security bundle materially important even before broad press coverage appears.

2. Two paths can lead to account takeover

The highest-scoring advisory is CVE-2026-70486, rated 8.2. On an instance with a terminal server configured, a normal authenticated user could place malicious HTML where Open WebUI's terminal file preview loaded it. The iframe granted scripts and same-origin access even though the file was served from the application's own origin.

That combination could let the previewed script read the victim's session token from browser storage. The advisory says the preview can open automatically after a display_file tool event, so a malicious file could reach the victim through prompt injection or a social step without requiring a separate preview click. If the stolen account belonged to an administrator or a user allowed to create server-side Functions, the impact could extend beyond the browser account.

The important limits are explicit: terminal-server connections are empty by default, a restrictive terminal-proxy Content Security Policy could already block the path, and deployments without a terminal server were not affected.

The second account-takeover issue, CVE-2026-70482, affects Open WebUI's OAuth token-exchange endpoint. The endpoint verified that an access token was valid with the provider, but it did not verify that the token had been issued to Open WebUI's OAuth client. An attacker who obtained a victim's token through another app registered with the same provider could exchange it for an Open WebUI session as that victim.

The standard OAuth callback is not affected. The vulnerable token-exchange feature is disabled by default, does not create new Open WebUI accounts, and still requires a token tied to an existing user. But when the conditions line up, the issued session inherits the victim's role—including administrator access.

3. Two server-side paths can reach internal services

CVE-2026-70479 affects deployments using the nondefault Playwright web loader. Open WebUI validated the top-level page before the browser loaded it, but did not apply the same destination check to scripts, images, WebSockets, service workers, or other subresources requested by that page.

That matters because a public page can instruct a browser process to request private addresses. If the Playwright container can reach cloud metadata, another container, or an internal API, the final page DOM can carry the returned content back through a normal web-search or RAG result. The advisory rates the issue 7.7 and says it is a read primitive, not just a blind network probe.

CVE-2026-70485 covers a different SSRF bypass. Open WebUI rejected obvious loopback, private, and cloud-metadata targets, but classified the literal IPv6 address without unwrapping the IPv4 address embedded in a NAT64 form. On a network with NAT64 translation, a verified user could wrap a blocked IPv4 destination in the well-known NAT64 prefix and receive the internal response through Open WebUI.

This is not universal. An IPv4-only network or any network without a NAT64 gateway has nowhere to route the encoded address. But IPv6-oriented cloud and Kubernetes environments can provide exactly the translation the attack needs.

4. A rendered chart can make a viewer's browser send requests

CVE-2026-70480 is a client-side request issue in Vega and Vega-Lite chart rendering. A crafted chart block in a shared chat, channel, model response, RAG result, or tool output could tell the viewer's browser to request an attacker-chosen URL.

Because the browser—not the Open WebUI server—makes that request, server-side SSRF filters never see it. The victim must view the content, and response data is readable only when same-origin or permissive CORS rules allow it. Even without a readable response, a remote beacon can reveal that a particular chart was viewed and expose ordinary request metadata such as IP address and timing.

This flaw applies under default rendering behavior in affected versions. Version 0.11.0 replaces the unrestricted loader with one that permits inline chart data and tightly constrained resources.

5. Three authorization boundaries and one availability boundary also failed

The remaining advisories are narrower but useful because they expose recurring mistakes:

Together, these show why hiding a button, granting channel write access, or checking authorization after a side effect is not the same as enforcing a server-side permission at the action boundary.

6. Nine later advisories added file, chat, tool, terminal, XSS, SSRF, and availability risks

The later batch materially changes the scope of the disclosure. It is not just a metadata correction.

These later disclosures add one default-reachable stored-XSS account-takeover path, one default-reachable SSRF path, a default-reachable knowledge-search denial of service, and several feature- or sharing-dependent authorization failures. They also reinforce a recurring lesson: a UUID is not an authorization check, and read or write access to one object must not silently confer authority over another.

The Original Seventeen-Advisory Checklist

The original August advisories can be checked without squeezing five fields into a wide table:

Is Open WebUI 0.11.0 Enough?

No. Version 0.11.0 contains the code fixes for the original seventeen August advisories, but it remains affected by seventeen of the eighteen newly reviewed September advisories. Version 0.11.1 is the first upstream release identified as fixing those additional paths. The separate OAuth policy-bypass record was fixed much earlier, in 0.9.0.

The OAuth token-exchange advisory also remains a configuration exception. Version 0.11.0 added a trusted-client check through RFC 7662 token introspection, but the advisory says that check is opt-in. If ENABLE_OAUTH_TOKEN_EXCHANGE=True, an operator must also configure the trusted-client ID allowlist. Its full variable name is OAUTH_TOKEN_EXCHANGE_ followed by TRUSTED_CLIENT_IDS.

The advisory adds a more serious limitation: Google, Microsoft Entra ID, GitHub, and Feishu do not provide the required introspection path for this Open WebUI control. On those providers, the advisory says token exchange has no safe configuration and should remain disabled. This warning applies to the token-exchange endpoint, not the standard OAuth authorization-code callback.

Version 0.11.1 was published before these September vulnerability records became public. That is why an operator can already be on the fixed code even though the advisory records are new.

What Is Still Unclear

How many public instances are actually exposed?

The advisories document affected code and test conditions, not an internet-wide inventory. Public scans can also miss private, VPN-only, or internal deployments and can misidentify versions behind proxies.

Has anyone exploited these flaws outside testing?

The upstream advisories include proof-of-concept descriptions, but OpenVeil found no primary evidence of exploitation in the wild through the September 10 research cutoff. That is not proof exploitation never happened.

Which features are enabled on a particular server?

Several issues require settings that are off by default. A version number alone does not reveal whether terminals, Playwright, channels, image generation, OAuth token exchange, NAT64 routing, public sharing, or a permissive browser network path are present.

Does upgrading erase evidence of an earlier compromise?

No. A patch prevents the documented path going forward. It does not invalidate stolen sessions, rotate OAuth credentials, remove malicious files, restore deleted channel messages, revoke exposed cloud credentials, or explain suspicious historical traffic.

Do these advisories prove OpenVeil is affected?

No. The advisories identify upstream open-webui package versions and specific code paths. They do not evaluate OpenVeil's deployed code, configuration, network, authentication, or browser policies. Similar product ancestry is not evidence that one named deployment contains every upstream feature or vulnerability.

What Open WebUI Operators Should Do Now

1. Record the current state before changing it

Capture the running image digest or package version, deployment configuration, enabled features, reverse-proxy rules, OAuth settings, and network paths. Preserve relevant logs before restarting anything if compromise is plausible.

2. Back up the persistent data and verify the backup

Open WebUI's official update guide says the persistent data includes chats, users, settings, admin configuration, uploaded files, generated content, and other application state. The guide recommends backing up before every update.

Do not treat the existence of an archive file as proof of recovery. Verify that the backup can be read and that it points to the intended instance before applying a schema-changing release.

3. Upgrade every instance to 0.11.1 or later together

The earlier 0.11.0 release notes warn that the release line includes database migrations, while 0.11.1 contains the ten newer fixes that affect 0.11.0. Multi-worker, multi-server, and load-balanced deployments should not use rolling updates across incompatible schemas; coordinate the update across the whole deployment.

After restarting, verify the running version from the application or immutable image digest. Pulling a newer container image without recreating the running container does not update the process already serving traffic.

4. Audit the OAuth token-exchange setting separately

Search the actual deployment environment for ENABLE_OAUTH_TOKEN_EXCHANGE. If it is false or absent, the OAuth token-exchange vulnerability is not reachable through that feature.

If it is true, do not stop at the package upgrade. Follow the advisory's trusted-client requirement when the provider supports introspection. Otherwise disable token exchange and use the standard OAuth callback flow.

5. Rotate what the exposed paths could reach

If the deployment used affected configurations, consider the downstream blast radius:

Rotating everything blindly can destroy useful evidence. Preserve evidence first when incident response is warranted.

6. Reduce the boundary after patching

Disable features that are not needed. Separate browser automation from cloud metadata and sensitive internal services. Use network egress controls in addition to application URL filters. Keep ordinary users away from server-side code-authoring permissions. Treat model, RAG, tool, file, and shared-chat output as untrusted content before rendering it in a privileged browser origin.

OWASP's session-management guidance explains why a browser-origin script is so consequential: JavaScript executing in the same origin can reach credentials stored in Web Storage. A sandbox label is not protection when the permissions restore the origin access the sandbox was meant to remove.

A Practical SELF-HOST Audit

Use this eight-part check for any self-hosted AI interface:

  1. S — Software: What exact version and image digest are running on every node?
  2. E — Enabled features: Which optional tools, terminals, renderers, loaders, channels, and connectors are active?
  3. L — Login: Which authentication flows issue sessions, and are tokens bound to the intended client?
  4. F — Files: Can uploaded, generated, or terminal-served content execute in a trusted browser origin?
  5. H — Host network: Which internal services, metadata endpoints, containers, and private addresses can the app or browser reach?
  6. O — Ownership: Are authorization checks tied to the user and object before any edit, delete, generation, or cancellation side effect?
  7. S — Sessions: Where are tokens stored, how are they revoked, and what happens after suspected theft?
  8. T — Telemetry: Can logs prove which URL, file, tool, channel, token flow, and downstream provider was used?

The framework is deliberately broader than patching. A fixed package still sits inside a deployment whose network, permissions, browser origin, and logging determine the real result.

What This Does Not Mean

These advisories do not prove that every Open WebUI instance was compromised. They do not show that local model weights leaked, that every default deployment exposed cloud metadata, or that the standard OAuth callback is broken.

They also do not prove that self-hosting is a bad privacy choice. A carefully isolated, maintained local deployment can give an operator control that a hosted service cannot. The cost of that control is operational responsibility: updates, backups, authentication, browser isolation, network egress, logs, incident response, and the security of every enabled extension and provider.

The narrow conclusion is strong enough: local inference is not the same as a secure AI application, and version 0.11.1 is now the minimum upstream Open WebUI release operators should evaluate for these thirty-five disclosed issues.

Where OpenVeil Fits

OpenVeil serves users who want a hosted, paid, privacy-focused AI chat workspace without installing and maintaining an Open WebUI server. It keeps normal private-chat history in the browser and does not maintain a server-side chat-history record for those sessions.

That convenience changes who handles the application-server update, but it does not make OpenVeil fully local, anonymous, or free of processing. Active requests can still be processed by OpenVeil and necessary AI, search, upload, hosting, routing, security, billing, and infrastructure providers. These upstream Open WebUI advisories also do not prove OpenVeil is affected or unaffected.

If you are comparing the two operating models, read private AI chat versus local AI, what a secure chatbot is not guaranteed to make private, and what no server chat history does not mean.

For users who value full infrastructure control and can maintain it, self-hosting may be the better fit. For users who want a narrower hosted chat workflow without operating the AI web application themselves, review OpenVeil's privacy policy and decide whether its documented boundary fits the task.

FAQ

What Open WebUI versions are affected?

The ranges vary by flaw. Some reach back to early 0.x releases, while others begin in 0.8.8, 0.9.0, 0.9.5, 0.9.6, or 0.10.0. Version 0.11.0 fixes the original seventeen advisories, while seventeen of the eighteen newly reviewed September records require 0.11.1 or later. The older OAuth policy-bypass range was fixed in 0.9.0.

Is Open WebUI 0.10.2 vulnerable?

Yes. The original seventeen advisories and ten of the newly reviewed September advisories include 0.10.2 in their affected ranges or descriptions, subject to each issue's feature, role, sharing, identifier, and network preconditions.

Is upgrading to Open WebUI 0.11.0 enough?

No longer. It fixes the original seventeen documented code paths, but seventeen newly reviewed September advisories identify 0.11.1 as the fixed boundary. OAuth token exchange also needs an additional trusted-client configuration when enabled. Providers without the required token-introspection support should not use that exchange feature. Operators should review logs, rotate exposed credentials when warranted, and verify the running version after the update.

Was Open WebUI hacked?

The advisories document vulnerabilities and proof-of-concept testing. They are not an incident report and do not establish that the project, every installation, or any specific operator was compromised.

Can these flaws expose local files or model weights?

These thirty-five advisories include indexed-file and knowledge-base disclosure, but they do not by themselves establish arbitrary host-file or model-weight theft. They also cover sessions, OAuth, internal HTTP services, browser requests, shared objects, tool source, provider-credit use, chat integrity, and availability. An internal service reached through SSRF could expose other data depending on that service's own behavior and authentication.

Does running Open WebUI only on localhost remove the risk?

It can reduce who reaches the login page, but it does not erase every boundary. A local browser can still render untrusted chat content, a malicious local account can still abuse enabled features, and the server or Playwright container may still reach internal services. Evaluate the actual users, browser origin, network, and tools.

Does using Ollama make Open WebUI secure?

No. Ollama can keep model inference local when configured for local models, but Open WebUI remains a separate web application with authentication, files, rendering, RAG, tools, channels, network requests, and storage. Read whether using Ollama means every AI path is local.

Should operators disable every optional feature?

Not necessarily. Features create value, but each should have a named owner, documented need, least-privilege configuration, network boundary, update path, and monitoring plan. Disable what has no current purpose.

Bottom Line

Open WebUI 0.11.1 is the current fixed boundary across thirty-five reviewed security advisories, including additional account-takeover, internal-network, credential-forwarding, knowledge-access, chat-integrity, authorization, and availability paths disclosed in September. Most operators should back up, upgrade, verify the running version, and review the features, sharing grants, identity policies, and network routes they enabled.

If OAuth token exchange is enabled, treat it as a separate urgent check: upgrading without constraining trusted client IDs—or disabling the feature when the provider cannot support that check—does not close the documented boundary.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.