Open WebUI Vulnerabilities: Which Advisories Hit Your Setup

Ask every instance what it is running. The version endpoint needs no login, so you can script it across every host, including the ones nobody registered with the platform team.

curl -s https://chat.internal.example/api/version
# {"version":"0.11.4","deployment_id":"..."}

Then read the answer against the vulnerable ranges. Counting how many active advisory ranges include a given version gives this picture for 25 September 2026:

Read the dates carefully. The 53 advisories were published in four batches (18 on 24 July, 17 on 4 August, 3 on 9 September, 15 on 10 September), but every one of them was already fixed in a shipped release when it went public: 18 in 0.10.0, 17 in 0.11.0, 17 in 0.11.1 and one in 0.9.0. These are disclosure dates, not the dates the bugs appeared, and anyone summarising them as "53 vulnerabilities found in seven weeks" is misreading the feed.

The full set of 164 holds exactly one critical, CVE-2026-44551, an LDAP empty-password authentication bypass scored 9.1, fixed in 0.9.0 in April 2026 and relevant only where LDAP authentication is enabled. Nothing in the July to September window is critical.

The obvious floor is 0.11.1, because that is where the published ranges stop. Do not use it. The release notes for v0.11.4, v0.11.2, v0.11.1 and v0.11.0 each carry the same passage under Fixed:

This release includes security and access-control fixes. We recommend updating production deployments at your earliest convenience. Not all security fixes in this version may be enumerated in the fixed section. Some may be withheld for a short time to give administrators time to upgrade.

The v0.11.3 hotfix note does not carry it. The project is telling you, in its own words, that a release can contain security fixes the advisory feed has not described yet. The last three batches show how long that gap runs:

A vulnerability scanner keyed to published advisories therefore runs behind the releases by that gap, and a policy of "upgrade when the scanner flags it" leaves you on a version the maintainers already consider superseded for security reasons. Upgrade on the release, not on the advisory. On the post date that means v0.11.4, released on 21 September 2026. We are not claiming v0.11.2 through v0.11.4 fix any specific named advisory; nothing citable said so on 25 September. The recommendation rests on the release notes and the lag pattern.

The README quickstarts use the moving :main tag. Replace it with the release tag so the running version is explicit, reproducible and something a change record can name:

docker pull ghcr.io/open-webui/open-webui:v0.11.4
# or the slim variant (note: slim defaults VECTOR_DB to pgvector)
docker pull ghcr.io/open-webui/open-webui:v0.11.4-slim

The same start-with-your-version triage applies to the gateway that often sits between Open WebUI and the models; we walked through it in the LiteLLM proxy security hardening checklist.

# Provider without RFC 7662 introspection (Google, Microsoft Entra ID, GitHub, Feishu):
ENABLE_OAUTH_TOKEN_EXCHANGE=False

# Provider that supports RFC 7662 introspection, and you need token exchange:
ENABLE_OAUTH_TOKEN_EXCHANGE=True
# comma-separated client ids you trust (these two are illustrative)
OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS=chat-portal,reporting-service

# Either way:
ENABLE_PYODIDE_FILE_PERSISTENCE=false

This is the table your change board wants. Thirty advisories need a setting or feature that is off in a fresh v0.11.4 install. Each row names the setting, its default, the advisories it opens, the highest severity among them and the release that closes all of them.

The rows sum to 30: 13 high, 15 medium, 2 low. The other 23 advisories need no non-default setting at all, and the next section deals with them.

To fill in the left column for your own install, check two places. Some keys are read straight from the environment, so the container env is authoritative for them:

docker exec open-webui env | grep -E '^(VECTOR_DB|ENABLE_OAUTH_TOKEN_EXCHANGE|ENABLE_OAUTH_BACKCHANNEL_LOGOUT|AIOHTTP_CLIENT_ALLOW_REDIRECTS|WEBUI_AUTH_TRUSTED_ROLE_HEADER|ENABLE_SCIM|UVICORN_WORKERS|OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS|ENABLE_PYODIDE_FILE_PERSISTENCE)='
# database backend without printing the connection string
docker exec open-webui sh -c 'echo "${DATABASE_URL%%:*}"'

No output line for a key means the default applies. If ENABLE_OAUTH_TOKEN_EXCHANGE=True prints and OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS does not, CVE-2026-70482 is still open on v0.11.4. The DATABASE_URL line prints only the scheme, so no password lands in a terminal log; an empty line means the default SQLite database.

Other settings live in the database. With ENABLE_PERSISTENT_CONFIG at its default of True, values saved through the admin panel win over the env file, so the env file can say channels are off while the running instance has them on. The upgrade-time version of that failure is covered in the comparison post's section on upgrades and disconnected networks. Read the live values through the admin config export instead:

curl -s -H "Authorization: Bearer $ADMIN_TOKEN" https://chat.internal.example/api/v1/configs/export \
  | jq '{channels: .["channels.enable"], terminals: (.["terminal_server.connections"] // [] | length), tool_servers: (.["tool_server.connections"] // [] | length), web_loader: .["web.loader.engine"], signup: .["ui.enable_signup"], default_role: .["ui.default_user_role"]}'

The endpoint needs an admin token and returns a flat dictionary keyed by dotted names. A null means no stored row, so the default applies. The query counts terminal and tool server connections instead of printing them, because connection entries can hold credentials.

Twenty-three advisories need no non-default setting: 5 high, 15 medium, 3 low. Sorting them by what the attacker needs is more useful than sorting by score.

Every one of the five default-reachable highs carries a condition that narrows it:

No advisory in the window gives an unauthenticated attacker code execution. The server-side code paths in CVE-2026-59214 and CVE-2026-59216 both need an admin, or a user with function or tool permissions, to act or be hijacked.

Three features account for 13 of the 30 non-default advisories and 6 of the 13 highs among them. The recommendation is the same for all three: if you do not use the feature, leave it off, and confirm it is off in the persisted config rather than the env file.

Some advisories apply because of decisions made at install time for reasons that had nothing to do with security.

CVE-2026-87016 (high 8.1, fixed in 0.11.1) allows sign-in as another user on SQLite, the default database, when OAuth, OIDC or SCIM is enabled. JSON matching compiled to a SQL LIKE, so wildcard characters in the subject claim matched other accounts. PostgreSQL deployments are not affected at all. Deliberate exploitation needs a subject claim the attacker controls, which means an operator pointed OAUTH_SUB_CLAIM at a user-settable claim. The realistic risk is the accidental one: a legitimate subject containing an underscore can match a different account with no attacker involved. The SCIM path needs the SCIM bearer token. If you run SSO on SQLite, this is also a reason to plan the move to PostgreSQL.

CVE-2026-87017 (medium 4.3, fixed in 0.11.1) exposed knowledge bases a user could not otherwise access through the built-in knowledge tool, because 11 of the 15 shipped vector backends ignored the access filter: both Qdrant clients, Elasticsearch, OpenSearch, both Milvus clients, openGauss, Oracle 23ai, Pinecone, S3 Vectors and Weaviate. Chroma, pgvector, MariaDB and Valkey applied it and were never affected, so the default VECTOR_DB (chroma, or pgvector on the slim image) is safe from this one. Teams that pointed Open WebUI at an existing Qdrant or Milvus cluster to share a corpus were exposed. The general lesson, that a retrieval-time permission filter is a control you test rather than trust, is the subject of our post on stale ACLs in RAG and revoked access that still returns documents. The backend behind the portal also has its own CVE history; see self-hosted vector database security hardening.

CVE-2026-87014 (medium 6.5, fixed in 0.11.1) is narrower than its title suggests. An admin demoted through SSO role sync, meaning WEBUI_AUTH_TRUSTED_ROLE_HEADER or OAuth role mapping, kept read and write access to all users' notes, and only over a Socket.IO connection opened while still admin and held open across the demotion. A reconnect, reload or sign-out ended it, and demotions made in the admin panel were never affected.

CVE-2026-87011 (high 7.5, fixed in 0.11.1) is the uncomfortable one. It lets unauthenticated requests stall the server through uncached OIDC fetches in back-channel logout, and the attacker needs only network access and the issuer string. The advisory notes that ENABLE_OAUTH_BACKCHANNEL_LOGOUT is recommended in the Open WebUI hardening documentation, which lists IdP-initiated back-channel logout as a hardening step. A hardening step opened an unauthenticated denial of service until 0.11.1. That hardening guide is useful, but it names no CVE or GHSA and does not map advisories to settings, which is why the table above has to exist in your own runbook.

This pattern predates the batch. CVE-2025-64496 (high 7.3, fixed in 0.6.35) needed Direct Connections, which ships off, and CVE-2026-45672 (high 8.8, fixed in 0.8.12) ran Jupyter code despite ENABLE_CODE_EXECUTION=false. A disable switch is a control only from the version that enforces it; CVE-2026-59227 in this batch repeated the lesson with an image edit route that ignored ENABLE_IMAGE_EDIT=False.

Running Open WebUI inside your own perimeter changes the answer in three concrete places.

Network egress decides the fetch advisories. Eight advisories in the window involve fetching something the attacker chose. Seven are server-side: CVE-2026-54020 (DNS rebinding), CVE-2026-70485 (NAT64), CVE-2026-87999 (Azure platform channel), the two Playwright loader SSRFs, the redirect bypass and the filter-list bypass (which, per its advisory, never got past the private-IP guard). A host whose outbound traffic is denied at the network layer neutralises all seven regardless of version. The eighth, the Vega chart fetch in CVE-2026-70480, runs in the viewer's browser, so it is bounded by what the workstation can reach. We cover the host-level deny and what it breaks in securing an Ollama server exposed to the internet. v0.11.4 also ships a default fetch filter list of 18 entries, including 169.254.169.254, metadata.google.internal, metadata.azure.com and 168.63.129.16, merged with any WEB_FETCH_FILTER_LIST entries you add. Treat it as a second layer, not the first.

Cloud "private" is not an enclave. CVE-2026-87999 exists only on Azure, and CVE-2026-70485 only on a network that provides NAT64. Neither applies to hosting on your own hardware in a network without a NAT64 gateway. If your "private AI" is a VM in a public cloud tenancy, check both: the Azure one applies on any Azure host, and the NAT64 one on any IPv6 or dual-stack network that translates 64:ff9b::/96. That is a concrete input to the hosting decision.

Disconnected instances cannot watch for updates. ENABLE_VERSION_UPDATE_CHECK defaults to true and calls api.github.com; inside an air-gapped enclave the call fails and the endpoint returns no latest version. Combine that with fixes shipping 8 to 25 days before their advisories, and the patch trigger has to be the release feed watched from a connected machine, followed by a pinned image staged into the enclave under change control. The sneakernet side of that process is the same one we describe in the vLLM air-gapped deployment guide.

Account lifecycle closes the loop. ENABLE_SIGNUP defaults to True and DEFAULT_USER_ROLE to pending, so on a fresh install anyone who reaches the login page can create a pending account. A pending account, newly registered or deactivated back to pending, is the attacker in CVE-2026-70490 (terminals), and CVE-2026-59226 (automations) let a deactivated account's scheduled automations keep running. If identities come from SSO or an admin, set signup off, and check the persisted ui.enable_signup value in the export rather than trusting the env file.

Six steps, each small enough to finish before Friday:

More on securing the rest of a private AI stack sits in our AI security guide.