CVE-2026-59217: Open WebUI: read-only users can inject files into RAG KBs

GHSA-7r7x-gjvr-448g MEDIUM CISA: TRACK*
Published July 9, 2026
CISO Take

Open WebUI fails to enforce its own write-access check when files are uploaded with a metadata.knowledge_id field, letting a user who only has read access to a knowledge base silently attach arbitrary files to it. This matters less as a classic data-breach vector — CVSS 4.3 reflects no confidentiality or availability impact — and more as a data-integrity problem for any RAG pipeline built on Open WebUI, since a low-privileged account (a shared workspace guest, contractor, or compromised low-trust login) can plant attacker-controlled content that gets indexed and later retrieved into other users' LLM context. EPSS sits at the 82nd percentile, there's no public exploit or Nuclei template, and it's not in CISA KEV, so this is not an urgent breaking-alert item, but it's a straightforward, no-user-interaction bug (AC:L, UI:N) once an attacker has any low-privilege foothold. Upgrade to Open WebUI 0.10.0 or later, and in the interim audit knowledge-base membership and recently added files for anything uploaded by read-only members.

Sources: NVD GitHub Advisory EPSS CISA KEV ATLAS

What is the risk?

Medium severity per CVSS (4.3), driven down by the requirement for an authenticated low-privileged account (PR:L) and the limited formal impact (I:L, C:N, A:N). However, the practical risk in an AI deployment is higher than the raw score suggests: this is a broken-authorization bug (CWE-862/863) that lets a read-only knowledge-base member perform a write operation the platform explicitly gates elsewhere. In multi-tenant or team Open WebUI deployments — the common self-hosted pattern — 'read-only' access is often granted broadly (guests, contractors, cross-team collaborators), making the attacker precondition easy to satisfy. No public PoC or scanner template exists yet, and EPSS (0.27%, 82nd percentile) indicates low near-term mass-exploitation likelihood, but the low complexity and lack of required user interaction mean it's trivial to exploit once access is obtained.

How does the attack unfold?

Initial Access
Attacker obtains or already holds a valid, low-privileged (read-only) account on a shared Open WebUI knowledge base.
AML.T0012
Exploitation
Attacker uploads a file via the general upload endpoint with metadata.knowledge_id set to the target knowledge base, bypassing the write-access check enforced only on the dedicated knowledge-add endpoint.
Impact
The attacker-controlled file is auto-linked and indexed into the knowledge base, poisoning future RAG retrievals and enabling indirect prompt injection against any user or agent that queries it.
AML.T0070

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip < 0.10.0 0.10.0
149.6K 4 dependents Pushed yesterday 81% patched ~6d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
4.3 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 22% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I Low
A None

What should I do?

1 step
  1. Upgrade Open WebUI to version 0.10.0 or later, which restores the write-access check on the file-upload-to-knowledge-base path. Until patched, review knowledge-base membership lists and tighten who holds even read-only access to sensitive knowledge bases. Audit recently added files in shared/production knowledge bases for content added by accounts that should only have read access, and correlate against /api/v1/files/ upload logs and knowledge-base file-add events if audit logging is enabled. As a temporary compensating control, restrict knowledge-base sharing to trusted, need-to-know users only until the upgrade is applied.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
NIST AI RMF
MANAGE-2.3 - Mechanisms to supersede/mitigate risks from third-party or externally-sourced data
OWASP LLM Top 10
LLM08 - Vector and Embedding Weaknesses

Frequently Asked Questions

What is CVE-2026-59217?

Open WebUI fails to enforce its own write-access check when files are uploaded with a metadata.knowledge_id field, letting a user who only has read access to a knowledge base silently attach arbitrary files to it. This matters less as a classic data-breach vector — CVSS 4.3 reflects no confidentiality or availability impact — and more as a data-integrity problem for any RAG pipeline built on Open WebUI, since a low-privileged account (a shared workspace guest, contractor, or compromised low-trust login) can plant attacker-controlled content that gets indexed and later retrieved into other users' LLM context. EPSS sits at the 82nd percentile, there's no public exploit or Nuclei template, and it's not in CISA KEV, so this is not an urgent breaking-alert item, but it's a straightforward, no-user-interaction bug (AC:L, UI:N) once an attacker has any low-privilege foothold. Upgrade to Open WebUI 0.10.0 or later, and in the interim audit knowledge-base membership and recently added files for anything uploaded by read-only members.

Is CVE-2026-59217 actively exploited?

No confirmed active exploitation of CVE-2026-59217 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59217?

Upgrade Open WebUI to version 0.10.0 or later, which restores the write-access check on the file-upload-to-knowledge-base path. Until patched, review knowledge-base membership lists and tighten who holds even read-only access to sensitive knowledge bases. Audit recently added files in shared/production knowledge bases for content added by accounts that should only have read access, and correlate against `/api/v1/files/` upload logs and knowledge-base file-add events if audit logging is enabled. As a temporary compensating control, restrict knowledge-base sharing to trusted, need-to-know users only until the upgrade is applied.

What systems are affected by CVE-2026-59217?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, knowledge base / document retrieval, self-hosted LLM UI.

What is the CVSS score for CVE-2026-59217?

CVE-2026-59217 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.29%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesknowledge base / document retrievalself-hosted LLM UI

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0070 RAG Poisoning

Compliance Controls Affected

EU AI Act: Article 15
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, the file upload path accepted metadata.knowledge_id and auto-linked uploaded files to a target knowledge base without applying the write-access check used by /api/v1/knowledge//file/add, allowing read-only knowledge-base users to add arbitrary files. This issue is fixed in version 0.10.0.

Exploitation Scenario

An attacker (or a malicious/compromised low-trust insider) is granted read-only access to a shared Open WebUI knowledge base — for example, as a guest collaborator on a team instance or a member of a broader community workspace. Instead of going through the gated `/api/v1/knowledge//file/add` endpoint, they use the general file-upload endpoint and set `metadata.knowledge_id` to point at the target knowledge base. Because this path never applies the write-access check the dedicated endpoint uses, the upload is auto-linked to the knowledge base despite the attacker lacking write permission. The file is then indexed and becomes part of the corpus retrieved by the RAG pipeline, so the next time any user (or an agent) queries that knowledge base, the LLM's context window can include attacker-controlled content — enabling indirect prompt injection, misinformation, or planted malicious instructions/links surfaced as if they were trusted, vetted knowledge-base material.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Timeline

Published
July 9, 2026
Last Modified
July 24, 2026
First Seen
July 9, 2026

Related Vulnerabilities