CVE-2026-87017: Open WebUI KB metadata leaks across

Q: Is CVE-2026-87017 actively exploited?

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

Q: How to fix CVE-2026-87017?

Upgrade Open WebUI to 0.11.1 or later, which fixes the filter enforcement in the affected vector backend search methods (see commit 1d6d4e6 and GHSA-pcvc-8vrv-8q6w). Until patched, audit knowledge base names and descriptions on any shared/multi-tenant instance and remove or genericize anything sensitive (client names, internal project codenames, confidential subject lines) since those fields are the ones exposed. Review Open WebUI access logs for unusual patterns of knowledge-search-tool calls returning results across many distinct knowledge base IDs from a single low-privileged account, which would indicate enumeration attempts. Apply least-privilege knowledge base sharing — don't rely on the search tool's filter alone as the sole access control boundary until the fix is confirmed deployed.

Q: What systems are affected by CVE-2026-87017?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, knowledge management / multi-tenant AI platforms.

Q: What is the CVSS score for CVE-2026-87017?

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

CISO Take

Open WebUI's built-in knowledge search tool correctly tags queries with the caller's readable knowledge identifiers, but eleven of the shipped vector-store backends never enforce that filter server-side, so any authenticated user can enumerate the IDs, names, and descriptions of knowledge bases they were never granted access to. The actual document text stays isolated in separate per-collection storage, capping the blast radius to metadata, and exploitation needs only low privileges and no user interaction over the network (CVSS 4.3, AC:L/PR:L/UI:N). There's no EPSS score, no CISA KEV listing, and no public exploit or scanner template, so this reads as a quiet internal-exposure bug rather than an actively targeted flaw — but with 168 other CVEs already logged against this package and a package risk score of 38/100, Open WebUI deployments deserve routine patch hygiene regardless. Upgrade to 0.11.1 to close the filter gap; until then, treat knowledge base names/descriptions as visible to any logged-in user and avoid embedding sensitive client, project, or internal codenames in KB metadata on multi-tenant instances.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium risk overall. Exploitability is high in relative terms — network-reachable, low attack complexity, only low privileges required, and no user interaction — but impact is narrow: confidentiality-only, limited to metadata (identifiers, names, descriptions), with no effect on integrity or availability and no access to the underlying document text. There is no evidence of active exploitation (not in CISA KEV, no SSVC decision), no EPSS score published, and no public exploit code or Nuclei template, which lowers near-term urgency. The realistic risk driver is multi-tenant or shared-instance deployments (SaaS-style Open WebUI installs, internal platforms shared across teams/clients) where knowledge base naming conventions may themselves be sensitive (e.g., client names, project codenames, incident names).

How does the attack unfold?

Initial Access

Attacker obtains or already holds a low-privileged authenticated account on a shared/multi-tenant Open WebUI instance.

AML.T0012

Exploitation

Attacker invokes the built-in knowledge search tool; the vulnerable vector backend ignores the readable-knowledge-ID metadata filter and returns cross-tenant results.

AML.T0085.000

Reconnaissance / Collection

Attacker enumerates identifiers, names, and descriptions of knowledge bases outside their permission scope across the shared collection.

AML.T0064

Impact

Disclosed metadata (client names, project codenames, confidential subject lines) enables targeted social engineering or further access-control abuse against high-value knowledge bases.

Initial Access

Attacker obtains or already holds a low-privileged authenticated account on a shared/multi-tenant Open WebUI instance.

AML.T0012

Exploitation

Attacker invokes the built-in knowledge search tool; the vulnerable vector backend ignores the readable-knowledge-ID metadata filter and returns cross-tenant results.

AML.T0085.000

Reconnaissance / Collection

Attacker enumerates identifiers, names, and descriptions of knowledge bases outside their permission scope across the shared collection.

AML.T0064

Impact

Disclosed metadata (client names, project codenames, confidential subject lines) enables targeted social engineering or further access-control abuse against high-value knowledge bases.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Open WebUI	pip	>= 0.7.0, <= 0.11.0	`0.11.1`
151.8K 3 dependents Pushed 7d ago 83% patched ~5d 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.2%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C Low

I None

A None

What should I do?

1 step

Upgrade Open WebUI to 0.11.1 or later, which fixes the filter enforcement in the affected vector backend search methods (see commit 1d6d4e6 and GHSA-pcvc-8vrv-8q6w). Until patched, audit knowledge base names and descriptions on any shared/multi-tenant instance and remove or genericize anything sensitive (client names, internal project codenames, confidential subject lines) since those fields are the ones exposed. Review Open WebUI access logs for unusual patterns of knowledge-search-tool calls returning results across many distinct knowledge base IDs from a single low-privileged account, which would indicate enumeration attempts. Apply least-privilege knowledge base sharing — don't rely on the search tool's filter alone as the sole access control boundary until the fix is confirmed deployed.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Data Leakage Auth Bypass Privacy Violation RAG Framework AML.T0012 - Valid Accounts AML.T0064 - Gather RAG-Indexed Targets AML.T0085.000 - RAG Databases

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9 - Data for AI systems

NIST AI RMF

MANAGE-4.1 - Risk treatments to reduce identified AI risks

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-87017?

Open WebUI's built-in knowledge search tool correctly tags queries with the caller's readable knowledge identifiers, but eleven of the shipped vector-store backends never enforce that filter server-side, so any authenticated user can enumerate the IDs, names, and descriptions of knowledge bases they were never granted access to. The actual document text stays isolated in separate per-collection storage, capping the blast radius to metadata, and exploitation needs only low privileges and no user interaction over the network (CVSS 4.3, AC:L/PR:L/UI:N). There's no EPSS score, no CISA KEV listing, and no public exploit or scanner template, so this reads as a quiet internal-exposure bug rather than an actively targeted flaw — but with 168 other CVEs already logged against this package and a package risk score of 38/100, Open WebUI deployments deserve routine patch hygiene regardless. Upgrade to 0.11.1 to close the filter gap; until then, treat knowledge base names/descriptions as visible to any logged-in user and avoid embedding sensitive client, project, or internal codenames in KB metadata on multi-tenant instances.

Is CVE-2026-87017 actively exploited?

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

How to fix CVE-2026-87017?

Upgrade Open WebUI to 0.11.1 or later, which fixes the filter enforcement in the affected vector backend search methods (see commit 1d6d4e6 and GHSA-pcvc-8vrv-8q6w). Until patched, audit knowledge base names and descriptions on any shared/multi-tenant instance and remove or genericize anything sensitive (client names, internal project codenames, confidential subject lines) since those fields are the ones exposed. Review Open WebUI access logs for unusual patterns of knowledge-search-tool calls returning results across many distinct knowledge base IDs from a single low-privileged account, which would indicate enumeration attempts. Apply least-privilege knowledge base sharing — don't rely on the search tool's filter alone as the sole access control boundary until the fix is confirmed deployed.

What systems are affected by CVE-2026-87017?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, knowledge management / multi-tenant AI platforms.

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

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

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasesknowledge management / multi-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0064 Gather RAG-Indexed Targets

AML.T0085.000 RAG Databases

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.7.0 until 0.11.1, the built-in knowledge search tool passed the caller's readable knowledge identifiers through a metadata filter, but the search methods in eleven shipped vector backends ignored that filter. An authenticated user on an affected backend could enumerate the identifiers, names, and descriptions of inaccessible knowledge bases from the shared collection, although the associated document text remained in separate collections. This issue is fixed in version 0.11.1.

Exploitation Scenario

An adversary with a legitimate but low-privileged account on a shared Open WebUI instance (e.g., a contractor, a user in one department, or a customer on a multi-tenant SaaS deployment) issues normal queries through the built-in knowledge search tool. Because the vector backend in use ignores the caller's readable-knowledge-ID filter, the search returns hits from knowledge bases belonging to other users or tenants, revealing their identifiers, names, and descriptions even though the attacker cannot read the underlying documents. The attacker uses this metadata to map out what confidential projects, clients, or datasets exist on the platform, then pivots to social engineering (e.g., requesting access by referencing a real internal project name) or targets those specific knowledge bases for further access-control abuse or insider-style requests.

Weaknesses (CWE)

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Primary CWE-863 Incorrect Authorization Primary CWE-200 Exposure of Sensitive Information to an Unauthorized Actor CWE-863 Incorrect Authorization

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.