OPEN-WEBUI · CVE-2026-109287 · AI agents & MCP
FIX → 0.11.4
Open WebUI's knowledge base directory endpoints accept a directory id from a different knowledge base, so a user who can read one knowledge base can see the names, parents and owner ids of folders in another. File contents and embeddings of the other knowledge base are not exposed according to the advisory.
first public Sep 27, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams running a self-hosted Open WebUI release from 0.9.6 up to but not including 0.11.4 that use knowledge base directories. Exposure requires an account with read access to at least one knowledge base and a directory id from a knowledge base that account cannot access, which the advisory says is hard to obtain since ids are random UUIDs. Deployments on other versions or without knowledge base directories can skip it.
Not affected if no-knowledge-directories, version-outside-range
Who cares knowledge-bases, open-webui, python, self-hosted
open-webui version with pip show open-webui; affected versions are >= 0.9.6 and < 0.11.4.workspace.knowledge permission is off by default).A user who can read one knowledge base could list it with the id of a directory that belongs to a different knowledge base they have no access to. The response returned that directory and every parent above it, including folder names and the owning user. The same foreign directory id was also accepted as the parent of a new or moved directory and as the target directory when linking files. None of these paths checked that the directory belonged to the knowledge base named in the request.
workspace.knowledge permission (off by default) or the admin role.With one retained directory id, the attacker reads the current name, id, parent, owner user id, containing knowledge base id and timestamps of that directory and all of its ancestors. Renames made after their access was revoked are also visible. Where folder names encode client, project or case names, that structure is the sensitive part. The id requirement keeps the realistic attacker population small. The write-side paths let the attacker attach their own directories or files under a foreign directory, but this gives them nothing beyond the write access they already hold on their own knowledge base. File contents, file lists and the embeddings of the foreign knowledge base are not exposed.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to 0.11.4
open-webui 0.11.4 (fixed in commit a9541c18c; the advisory says upgrading is sufficient)Fixed in a9541c18c. Directory lookups are now bound to the knowledge base in the request: the breadcrumb walk only follows directories of that knowledge base, and every endpoint that accepts a directory or parent id rejects one from another knowledge base. The upload path ignores it. Upgrading is sufficient.
backend/open_webui/models/knowledge.py, get_directory_breadcrumbsbackend/open_webui/routers/knowledge.py, GET /api/v1/knowledge/{id}/files (directory_id), POST /{id}/dirs/create and POST /{id}/dirs/{dir_id}/update (parent_id), POST /{id}/file/add and POST /{id}/files/batch/add (directory_id)backend/open_webui/routers/files.py, upload auto-link (metadata.directory_id)Each endpoint checked the caller's access to the knowledge base in the URL and then used the caller-supplied directory id as given. The breadcrumb walk looked directories up by id alone, while the file list and directory list in the same response were filtered by knowledge base. So the one part of the response that followed the caller's id could leave the authorised knowledge base. The create, update and link paths had the same gap, and only the move, delete and sync cleanup paths compared the directory's knowledge base to the one in the URL.
Reproduced against the real knowledge router on a fresh database. The admin owns a private knowledge base A with the nested directories ACME-Litigation/witness-list and a knowledge base B shared with an ordinary user.
GET /api/v1/knowledge/{A}/files returns 400 (no access).GET /api/v1/knowledge/{B}/files?directory_id={id of witness-list} returns 200 with breadcrumbs listing ACME-Litigation and witness-list, each carrying knowledge base A's id and the admin's user id.POST /api/v1/knowledge/{B}/dirs/create with parent_id set to a directory of A returns 200 and stores the foreign parent. The same happens for POST /api/v1/knowledge/{B}/dirs/{dir}/update.On the fixed version, step 2 returns an empty breadcrumbs list and step 3 returns 404. Directories of B still produce breadcrumbs and can still be used as parents.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.