CVE-2026-45831: ChromaDB: RBAC bypass enables cross-tenant data access

HIGH
Published June 12, 2026
CISO Take

ChromaDB's SimpleRBACAuthorizationProvider checks whether a user holds a permission but never validates which tenant, database, or collection that permission applies to, allowing any authenticated user to read, write, or delete data across organizational boundaries. In multi-tenant RAG deployments—where ChromaDB commonly stores embeddings for different customers or business units—this means one tenant can access or poison another tenant's entire vector store, exposing proprietary documents and AI context. The vulnerability class is trivially exploitable: no special tooling or deep expertise is required beyond valid credentials and knowledge of another tenant's collection name, and no public EPSS score or KEV listing yet means detection lag is real. Organizations running ChromaDB 0.5.0+ with SimpleRBACAuthorizationProvider in any shared configuration should immediately isolate instances per tenant or apply the patch from HiddenLayer's advisory; shared deployments without isolation should be treated as fully exposed until remediated.

Sources: NVD ATLAS hiddenlayer.com

What is the risk?

High risk in any multi-tenant ChromaDB deployment. The flaw is architectural—the RBAC engine lacks scope binding entirely—making it reliably and trivially exploitable by any authenticated user without privilege escalation or complex attack chains. In single-tenant or network-isolated deployments risk is materially lower, but organizations must audit their configuration to confirm true isolation. Vector stores frequently contain sensitive embeddings reconstructable into proprietary documents, making data confidentiality the primary concern alongside integrity (cross-tenant poisoning) and availability (cross-tenant deletion).

How does the attack unfold?

Initial Access
Attacker authenticates to a shared ChromaDB deployment using their own valid tenant credentials, obtaining a legitimate API session with scoped permissions.
AML.T0012
Authorization Bypass
Attacker issues API requests targeting another tenant's collections; SimpleRBACAuthorizationProvider confirms the permission type exists but never validates the target scope, granting unauthorized access.
AML.T0049
Data Collection
Attacker enumerates and retrieves embeddings, document chunks, and metadata from unauthorized tenant collections via standard ChromaDB query and get APIs.
AML.T0085.000
Exfiltration / Impact
Attacker exfiltrates proprietary RAG knowledge base content, inserts adversarial embeddings to poison cross-tenant AI outputs, or deletes victim collections causing irreversible data loss.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
ChromaDB pip No patch
28.2K OpenSSF 5.0 1.2K dependents Pushed 6d ago 0% patched Full package profile →

Do you use ChromaDB? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

6 steps
  1. Immediately inventory all ChromaDB deployments running 0.5.0+ using SimpleRBACAuthorizationProvider — any shared-instance deployment is vulnerable.

  2. Apply the patched version referenced in HiddenLayer's advisory (https://www.hiddenlayer.com/sai-security-advisory/2026-06-chromadb-3).

  3. If patching is not immediately possible, deploy one ChromaDB instance per tenant rather than sharing a single instance across tenants — network isolation provides defense-in-depth.

  4. Audit ChromaDB access logs for anomalous cross-tenant API calls: flag requests where the authenticated user's tenant context does not match the target collection's tenant prefix.

  5. Restrict ChromaDB API access by source IP or service identity at the network layer where feasible.

  6. Review whether collection names are guessable or discoverable via list APIs, as exploitation requires knowledge of target collection identifiers.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.1.2 - Information access restriction
NIST AI RMF
GOVERN 6.2 - Organizational risk policies for AI are established
OWASP LLM Top 10
LLM08:2025 - Vector and Embedding Weaknesses

Frequently Asked Questions

What is CVE-2026-45831?

ChromaDB's SimpleRBACAuthorizationProvider checks whether a user holds a permission but never validates which tenant, database, or collection that permission applies to, allowing any authenticated user to read, write, or delete data across organizational boundaries. In multi-tenant RAG deployments—where ChromaDB commonly stores embeddings for different customers or business units—this means one tenant can access or poison another tenant's entire vector store, exposing proprietary documents and AI context. The vulnerability class is trivially exploitable: no special tooling or deep expertise is required beyond valid credentials and knowledge of another tenant's collection name, and no public EPSS score or KEV listing yet means detection lag is real. Organizations running ChromaDB 0.5.0+ with SimpleRBACAuthorizationProvider in any shared configuration should immediately isolate instances per tenant or apply the patch from HiddenLayer's advisory; shared deployments without isolation should be treated as fully exposed until remediated.

Is CVE-2026-45831 actively exploited?

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

How to fix CVE-2026-45831?

1. Immediately inventory all ChromaDB deployments running 0.5.0+ using SimpleRBACAuthorizationProvider — any shared-instance deployment is vulnerable. 2. Apply the patched version referenced in HiddenLayer's advisory (https://www.hiddenlayer.com/sai-security-advisory/2026-06-chromadb-3). 3. If patching is not immediately possible, deploy one ChromaDB instance per tenant rather than sharing a single instance across tenants — network isolation provides defense-in-depth. 4. Audit ChromaDB access logs for anomalous cross-tenant API calls: flag requests where the authenticated user's tenant context does not match the target collection's tenant prefix. 5. Restrict ChromaDB API access by source IP or service identity at the network layer where feasible. 6. Review whether collection names are guessable or discoverable via list APIs, as exploitation requires knowledge of target collection identifiers.

What systems are affected by CVE-2026-45831?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, multi-tenant AI applications, agent frameworks.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasesmulti-tenant AI applicationsagent frameworks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0025 Exfiltration via Cyber Means
AML.T0049 Exploit Public-Facing Application
AML.T0085 Data from AI Services
AML.T0085.000 RAG Databases

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.1.2
NIST AI RMF: GOVERN 6.2
OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

The SimpleRBACAuthorizationProvider authorization provider in versions 0.5.0 or later of the ChromaDB Python project evaluates whether a user holds a given permission but never checks which tenant, database, or collection that permission applies to allowing users to perform cross tenant actions.

Exploitation Scenario

An attacker with a legitimate account in Tenant A of a shared SaaS platform backed by ChromaDB authenticates normally and obtains an API session token. They call ChromaDB's collection-listing API — which may also lack scope enforcement — to enumerate collection names across tenants, or guess naming conventions from documentation. The attacker then issues a query against a Tenant B collection. SimpleRBACAuthorizationProvider confirms the caller holds 'read_collection' permission, which they do for their own tenant, but never validates that the target collection falls within their authorization scope. The attacker successfully dumps thousands of vectors and associated document chunks, reconstructing Tenant B's proprietary RAG knowledge base. In a second phase, they insert adversarially-crafted embeddings into Tenant B's collection to poison downstream LLM outputs without any direct LLM access.

Weaknesses (CWE)

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

  • [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.

Timeline

Published
June 12, 2026
Last Modified
June 12, 2026
First Seen
June 12, 2026

Related Vulnerabilities