Open WebUI Has 8 New Security Advisories. Is 0.11.0 Enough?

August 4, 2026

Eight new Open WebUI advisories cover account takeover, internal-network access, channel tampering, and permission bypasses. Most fixes are in 0.11.0, but one OAuth setup needs an extra configuration change.

title: "Open WebUI Has 8 New Security Advisories. Is 0.11.0 Enough?" slug: "open-webui-security-advisories-0-11-0" excerpt: "Eight new Open WebUI advisories cover account takeover, internal-network access, channel tampering, and permission bypasses. Most fixes are in 0.11.0, but one OAuth setup needs an extra configuration change." meta_title: "Open WebUI 0.11.0 Fixes 8 Security Flaws" meta_description: "Eight Open WebUI security advisories include account takeover and SSRF. Learn who is affected, what 0.11.0 fixes, and the OAuth step upgrade alone misses." tags: - Open WebUI vulnerabilities - Open WebUI 0.11.0 - self-hosted AI security - AI chatbot security status: published published_url: "https://openveil.app/blog/open-webui-security-advisories-0-11-0" published_at: "2026-08-04" post_id: "6eca3967-0922-40e4-9ac1-d3152c909d7f"

Yes—Open WebUI operators should move to version 0.11.0 after taking a verified backup. Eight security advisories published on August 4 include two account-takeover paths, two ways to reach internal services, and four authorization or browser-request flaws. But upgrading is not the whole answer for deployments that enabled OAuth token exchange: that feature also needs a trusted-client configuration or must stay disabled.

Last updated: August 4, 2026

The Short Answer

GitHub's reviewed advisory database published eight Open WebUI vulnerabilities within about 22 minutes on August 4, 2026. Four are rated high severity, three medium, and one low. The affected branches reach back as far as version 0.5.0, while the upstream project identifies 0.11.0 as the fixed release for all eight.

The alarming headlines need configuration context:

• The terminal-preview account takeover requires a configured terminal server and a malicious file reaching a victim's preview.
• The OAuth account takeover requires the nondefault token-exchange feature and a provider token for the victim.
• One internal-network attack requires the nondefault Playwright web loader.
• The NAT64 bypass requires a network that actually translates NAT64 addresses.
• Other flaws depend on channels, image generation, a shared chat, or knowledge of another chat's identifier.

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.

Who This Is For

This guide is for:

• people self-hosting Open WebUI at home or on a private server
• teams operating multi-user Open WebUI instances
• administrators who enabled terminals, Playwright web loading, channels, image generation, OAuth, or public sharing
• security teams reviewing local-versus-hosted AI deployments
• users who assumed local model inference automatically made the surrounding web application secure

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. Eight advisories were published on August 4

The upstream Open WebUI project published detailed GitHub security advisories covering eight distinct issues. They include affected versions, preconditions, proof-of-concept descriptions, root causes, fixes, and credits.

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:

• CVE-2026-70481: on standard channels, an ordinary member with write access could edit or delete messages written by someone else. Edited content stayed attributed to the original author. Channels are disabled by default, and direct-message and group-channel paths already enforced authorship.
• CVE-2026-70484: a user explicitly denied image-generation permission could still trigger the legacy image path through a crafted chat-completion request, consuming provider credits and storage. Image generation is off by default, and native function calling was not affected.
• CVE-2026-70483: an authenticated user who knew another chat's identifier could cancel its active generation because cancellation occurred before ownership was checked. The chat was not deleted or disclosed, and timing plus identifier knowledge limit the impact.

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.

The Eight-Advisory Map

Is Open WebUI 0.11.0 Enough?

For seven of the eight advisories, the upstream disclosures say upgrading to 0.11.0 resolves the issue without another configuration change.

The OAuth token-exchange advisory is the exception. Version 0.11.0 adds 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 OAUTH_TOKEN_EXCHANGE_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.0 is currently the project's latest release. It was published July 27, before the eight public advisories appeared on August 4, which is why an operator can already be on the fixed code even though the vulnerability 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 during the August 4 scan. 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.0 together

The 0.11.0 release notes warn that the release includes database migrations. 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:

• invalidate active Open WebUI sessions after an account-takeover path
• rotate cloud or service credentials reachable from Playwright or NAT64 networks
• review terminal files and tool events that opened previews
• inspect channel edits and deletions where channels were enabled
• review unexpected image-provider usage and stored outputs
• search outbound DNS, HTTP, and proxy logs for internal-address or beacon traffic

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.0 is now the minimum upstream Open WebUI release operators should evaluate for these eight 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 0.5.0, while others begin in 0.6.34, 0.7.0, 0.8.0, 0.9.0, or 0.9.6. The upstream advisories identify 0.11.0 as the fixed release for all eight.

Is Open WebUI 0.10.2 vulnerable?

Yes. All eight advisories include 0.10.2 in their affected ranges or descriptions, subject to each issue's feature and network preconditions.

Is upgrading to Open WebUI 0.11.0 enough?

It fixes the documented code paths, but OAuth token exchange needs an additional trusted-client configuration when enabled. Providers without the required token-introspection support should not use that exchange feature. Operators should also 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 eight advisories focus on sessions, OAuth, internal HTTP services, browser requests, channel integrity, provider-credit use, and generation availability. They do not by themselves establish arbitrary local-file or model-weight theft. 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.0 contains fixes for eight newly public security advisories, including two account-takeover paths and two internal-network read paths. Most operators should back up, upgrade, verify the running version, and review the features 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.