Which versions of ChromaDB are affected by CVE-2026-45831?

ChromaDB versions 0.5.0 and later contain a cross-tenant authorization bypass in SimpleRBACAuthorizationProvider allowing authenticated users to access databases and collections owned by other…

How to fix or mitigate CVE-2026-45831?

Within 24 hours: Inventory all ChromaDB deployments, document versions in use, and confirm whether SimpleRBACAuthorizationProvider is active for multi-tenant isolation. Within 7 days: Evaluate interim mitigations including network segmentation between tenants, disabling SimpleRBACAuthorizationProvider if alternatives exist, and implementing cross-tenant access monitoring. Within 30 days: Deploy selected interim controls, establish baseline of access logs for forensic analysis, and monitor vendor communications for patch availability.

ChromaDB CVE-2026-45831

Q: What is the CVSS score of CVE-2026-45831?

CVE-2026-45831 has a CVSS 4.0 base score of 8.8 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/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. EPSS exploitation probability: 0.0%.

EUVD-2026-36482 HIGH

Incorrect Authorization (CWE-863)

2026-06-12 HiddenLayer

GHSA-xph7-9rjv-w5fr

Python Authentication Bypass Chromadb Red Hat

8.8

CVSS 4.0 · Vendor: HiddenLayer

Severity by source

Vendor (HiddenLayer) PRIMARY

8.8 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/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

vuln.today AI

9.6 CRITICAL

Network-reachable API, low-privileged tenant account required (PR:L), no user interaction; scope change to other tenants (S:C) with high confidentiality/integrity impact and no availability effect.

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

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Red Hat

6.8 MEDIUM

qualitative

Primary rating from Vendor (HiddenLayer).

CVSS VectorVendor: HiddenLayer

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jun 12, 2026 - 16:25 vuln.today

DescriptionCVE.org

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.

Articles & Coverage 1

News 5 New Python Vulnerabilities - 1 Critical, 4 High Severity Jun 13, 2026

AnalysisAI

Cross-tenant authorization bypass in ChromaDB's SimpleRBACAuthorizationProvider (versions 0.5.0 and later) allows authenticated users to perform actions against tenants, databases, and collections they do not own. The provider verifies that a user holds a given permission but never validates the scope of that permission against the target resource, enabling lateral movement across multi-tenant deployments. No public exploit identified at time of analysis, but the flaw was disclosed by HiddenLayer and affects any Chroma deployment relying on the built-in RBAC provider for tenant isolation.

Technical ContextAI

ChromaDB is a popular open-source vector database widely used as the memory/retrieval layer for LLM and RAG applications. Its SimpleRBACAuthorizationProvider is an in-tree authorization plugin that gates API actions by permission name (e.g., 'collection:read', 'tenant:create'). The root cause is CWE-863 (Incorrect Authorization): the provider's permission-check routine answers 'does this user hold permission X?' but discards the resource identifier (tenant, database, or collection) embedded in the request, so a permission granted within one tenant is silently honored against any other tenant or collection. In multi-tenant SaaS or shared-research deployments - where the entire isolation model rests on RBAC scoping - this collapses tenant boundaries to a single shared namespace.

RemediationAI

No vendor-released patch identified at time of analysis - the only reference is the HiddenLayer advisory at https://www.hiddenlayer.com/sai-security-advisory/2026-06-chromadb-3, which security teams should monitor for an upstream fix tag. As a compensating control, replace SimpleRBACAuthorizationProvider with a custom AuthorizationProvider that validates the requested tenant/database/collection against the user's scoped grants before returning Allow; this requires implementing the Chroma authorization interface and re-testing every API path, but it restores tenant isolation. If a custom provider is not feasible, deploy one Chroma instance per tenant so the missing scope check cannot bridge tenants - at the cost of operational overhead and lost resource sharing - or front Chroma with a reverse proxy that enforces tenant scoping at the URL/header layer before requests reach the RBAC provider, accepting that this duplicates authorization logic and can drift from Chroma's internal model.