Open WebUI security: the 2026 advisories, the version to run and the settings to harden

Which Open WebUI version to run in October 2026

Run Open WebUI v0.12.2 or later; the latest release on 24 October 2026 was v0.12.3 of 16 October. That day the first page of the project's GitHub security advisories listed ten advisories: eight fixed in v0.11.4 of 21 September, one in v0.11.1 and one, published on 18 October, in v0.12.2. Two of the ten are rated High, and both are closed by v0.11.4.

Open WebUI is the chat front end in our articles on a private ChatGPT alternative and on scaling Open WebUI to 1,000 users. Those cover components, licence, replicas and databases. This article covers the application layer: what the advisories say, which of them depend on a setting, and which defaults an administrator should change before staff sign in. The server underneath, its BMC, driver and inference API, is the subject of our guide to securing a GPU server.

The advisories of September and October 2026

The table lists the first page of the advisory list as read on 24 October 2026. The list has further pages with older advisories; the ten below are the ones published since September. We give the identifier, the severity Open WebUI assigned, the fixed release and the condition under which an installation is exposed. We leave out how each flaw is triggered.

Open WebUI security advisories on GitHub, list and each advisory page read on 24 October 2026; severity and CVSS 3.1 base score as Open WebUI states them. Only GHSA-wvm9-9g5j-623f has a CVE, CVE-2026-88006.

The two High advisories differ in who can use them. GHSA-vpq8-f445-hcq7 needed no account at all: while a user was signed in, a page on another website could obtain that user's session token through the community stats message handler and then act as the user, private chats included. It affects 0.7.0 up to, but not including, 0.11.4 and only installations with ENABLE_COMMUNITY_SHARING, which defaults to True. GHSA-q46m-r89w-j74p needs a regular account with access to a Terminals connection; through Open WebUI's terminal proxy such a user could read and change terminal policies and stop other users' terminals. Installations without a Terminals connection are not affected, and the advisory adds that Terminals 0.2.4 rejects such administrator requests on its side as well.

Three Moderate advisories concern sign-in through an identity provider. Two let users whom the provider's roles should have refused or demoted keep a session through the OAuth token exchange endpoint; both need ENABLE_OAUTH_TOKEN_EXCHANGE and ENABLE_OAUTH_ROLE_MANAGEMENT, which are off by default. GHSA-2rr4-q6pg-m5g3 appeared only where the identity provider sends its roles claim in the ID token and not in the userinfo response. The third, GHSA-6g45-8g27-fh8q, kept a deactivated user's open terminal working; since 0.11.4 open terminal sessions re-check the user's access every ten seconds.

The rest concern sharing inside the instance: a link scheme in shared chats that could run script in a viewer's session (Chromium-based browsers were not affected), file and directory metadata of knowledge bases that outlived a revoked share, forked chats in a read-only folder, and channel messages shown as coming from a webhook. Most advisories state that upgrading is enough and no configuration change is needed.

Defaults that decide exposure

Several advisories name a default as the condition, which is a reason to review defaults even on a patched version. A feature nobody in the company uses should be off, because its next advisory will then not apply.

Open WebUI environment variable reference (stated as up to date with v0.12.1) and backend env.py on the main branch, read on 24 October 2026; the community sharing default from advisory GHSA-vpq8-f445-hcq7.

Many of these are what the reference calls ConfigVar variables. The environment sets their value at the first start; after that the value is stored, and Open WebUI uses the stored value on every restart, including changes made in the Admin Panel. An administrator who adds ENABLE_SIGNUP=False to the compose file of a running instance changes nothing. Change it in the Admin Panel, or set ENABLE_PERSISTENT_CONFIG=False, with which the environment variables apply and Admin Panel changes are lost at restart. For an installation managed as code, the second is easier to audit.

Admin chat access and admin export are policy questions as much as security ones: with both on, every administrator can read and export what staff typed. Decide them with your data-protection officer, and keep the number of administrator accounts small.

Sign-up, roles, SSO and two-factor sign-in

Open sign-up with pending accounts is safe only as long as someone checks the pending list. Once staff sign in through your identity provider with OpenID Connect, switch sign-up off and decide whether the local login form stays: ENABLE_LOGIN_FORM hides the email and password fields, and ENABLE_PASSWORD_AUTH, True by default, lets password and SSO sign-in coexist. Keep one local administrator for the case where the identity provider is down, protected by a long password and two-factor sign-in.

Open WebUI added two-factor sign-in in v0.12.0 of 10 October. Administrators can require an authenticator app for every user under Admin Settings, Authentication, or with ENABLE_MFA; users enrol from a QR code at their next sign-in and receive ten single-use recovery codes. MFA_ALLOW_OAUTH_BYPASS lets OAuth sign-ins through without it, which suits an identity provider that already enforces a second factor.

If you map roles from the identity provider with ENABLE_OAUTH_ROLE_MANAGEMENT, OAUTH_ALLOWED_ROLES and OAUTH_ADMIN_ROLES, check whether you also need the token exchange endpoint. It is off by default, and both OAuth advisories applied only where it was on. Where you need it, run 0.11.4 or later and confirm whether your provider sends roles in the userinfo response or only in the ID token.

We set up Open WebUI on the GPU servers we supply as part of our Private AI/ML service; describe your identity provider, user count and the features staff need, and our team replies with the configuration we would apply.

Secret key, cookies and the reverse proxy

WEBUI_SECRET_KEY is the key for Open WebUI's JSON Web Tokens, which carry the sessions. In the backend source on the main branch it has "No hardcoded fallback by design", and Open WebUI refuses to start with authentication enabled and an empty key. Generate a long random value, keep it in your secret store and give the same value to every replica, as our scaling guide explains.

Serve Open WebUI only over HTTPS through a reverse proxy, and set WEBUI_SESSION_COOKIE_SECURE to true, since its default is false. The advisory on links in shared chats notes that a Content-Security-Policy header forbidding inline script blocks that attack and that Open WebUI sets none by default. A CSP is added at the reverse proxy; test it against the version you run before rollout, because a policy that blocks scripts the interface needs breaks the page.

Tools, Functions, Pipelines and terminals run code

Open WebUI's plugin documentation is direct about this: "Tools, Functions, Pipes, Filters, and Pipelines execute arbitrary Python code on your server." It asks that "Only trusted administrators should have permission to create, import, or modify Tools and Functions", that regular users should not have Workspace access unless explicitly required, and that installed plugins are audited regularly. About the community site it says "Featured does not mean vetted." Functions are managed only by administrators; Tools can be added by users who have been given the permission, so leave that permission with administrators.

Such code runs with the rights of the Open WebUI server process, so it reaches what that process reaches, its environment and database included. Review each plugin before import, keep a list of what is installed with its version, and put plugins under the same change control as the application.

Terminals give users a shell on a separate terminal server. Two of the ten advisories concern them, and installations without a terminal server were affected by neither. If you enable them, run Terminals 0.2.4 or later, pin each connection to a named policy, grant access only to the users who need it and treat the terminal server as a host that users control.

Two more defaults stay off. ENABLE_OPENAI_API_PASSTHROUGH forwards any request to the upstream API with the administrator's key, and the reference warns that "Any authenticated user can reach any upstream endpoint". BYPASS_MODEL_ACCESS_CONTROL gives every user every model. Behind Open WebUI, vLLM should be reachable only from the Open WebUI host, since its --api-key covers only some routes, as our guide to securing a GPU server shows; our article on vLLM security advisories covers the model server's own versions. Prompt injection through documents and tools is a separate risk, covered in our guide to prompt injection and LLM security.

Updates and a monthly advisory check

The release notes of v0.11.2 and v0.12.0 both state "This release includes security and access-control fixes" and recommend updating production deployments at the earliest convenience; v0.11.2 adds that not all fixes may be listed and that some may be withheld for a short time. The advisories fixed in v0.11.4 were published on 27 and 28 September, six and seven days after the release. A team that updates only when an advisory appears is therefore always late; follow the releases.

Name one person who reads the advisory list once a month and after every release, records which advisories apply to the features you have on, and plans the upgrade. Upgrade by stopping all replicas, letting one instance run the database migrations and restarting the rest, as the scaling guide describes; back up the database first, because the guide notes that a Helm rollback cannot undo migrations.

Hardening checklist for an Open WebUI installation

Our summary of the sections above.

For outbound connections, Open WebUI's OFFLINE_MODE switches off its version update check and sets Hugging Face offline mode; our article on telemetry in self-hosted AI tools goes through every component of the stack. Who may read the query log and for how long is covered in our guide to an LLM gateway with keys, budgets and a log.

What we supply

You can buy the platform from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order, assembled and tested before delivery, with the operating system, drivers, CUDA and a container runtime installed on request. Open WebUI, vLLM, sign-in through your identity provider and retrieval on your documents are part of our Private AI/ML service. Tell us which Open WebUI version your pilot runs and we compare it with the current advisories.

FAQ