CVE-2026-45831 Overview
CVE-2026-45831 is an authorization flaw in the SimpleRBACAuthorizationProvider component of the ChromaDB Python project. Starting in version 0.5.0, the provider checks whether a user holds a given permission but never verifies which tenant, database, or collection that permission applies to. Authenticated users can invoke permitted actions against any tenant, database, or collection in the deployment. The flaw is tracked as a Broken Access Control issue [CWE-863] affecting the open-source vector database used in many retrieval-augmented generation (RAG) pipelines.
Critical Impact
Any authenticated ChromaDB user can read, modify, or delete vector data belonging to other tenants, breaking multi-tenant isolation in AI and RAG deployments.
Affected Products
- trychroma/chromadb Python package, versions 0.5.0 and later
- ChromaDB deployments using the SimpleRBACAuthorizationProvider authorization provider
- Multi-tenant RAG and vector search services built on affected ChromaDB releases
Discovery Timeline
- 2026-06-12 - CVE-2026-45831 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2026-45831
Vulnerability Analysis
ChromaDB exposes a Role-Based Access Control (RBAC) layer through the SimpleRBACAuthorizationProvider. The provider determines whether a caller may perform an action such as collection:read, collection:write, or database:delete. The check confirms only that the user holds the requested permission. It does not bind the decision to the specific tenant, database, or collection identifier passed in the request.
As a result, a user granted read access to a single collection in their own tenant can issue the same action against a collection in a different tenant. The authorization layer answers "yes" because the permission exists on the principal, regardless of resource scope. This breaks the tenant isolation model that downstream applications rely on.
The flaw is network-exploitable against any ChromaDB API endpoint that depends on SimpleRBACAuthorizationProvider. Exploitation requires only valid low-privileged credentials and no user interaction.
Root Cause
The root cause is missing resource-scope enforcement in the authorization decision function. The provider evaluates the action verb against the caller's role grants but discards the tenant, database, and collection arguments supplied in the request context. Per [CWE-863], the system performs an authorization check using an incorrect comparison, allowing operations on resources the user was never granted.
Attack Vector
An attacker authenticates to the ChromaDB HTTP API with any valid account, including a low-privileged tenant user. The attacker then issues standard ChromaDB client calls such as list_collections, get_collection, add, update, delete, or delete_collection against tenant and database identifiers belonging to a different customer. The server validates that the role grants the action and returns or modifies the targeted data.
No specific exploitation code is published with this advisory. See the HiddenLayer Security Advisory for the vendor's technical write-up.
Detection Methods for CVE-2026-45831
Indicators of Compromise
- ChromaDB API requests where the authenticated principal's tenant or database differs from the tenant or database parameter in the request body or path.
- Unexpected get_collection, list_collections, or delete_collection calls from accounts that historically only access a single tenant.
- Outbound data transfers from ChromaDB hosts that exceed normal per-tenant baselines.
Detection Strategies
- Enable verbose ChromaDB access logging and correlate the authenticated user identity with the tenant, database, and collection fields in each request.
- Build allow-lists mapping each service account to the tenants and databases it is expected to touch, and alert on deviations.
- Hunt for one principal accessing more than one tenant ID inside any rolling window after upgrading to or running ChromaDB 0.5.0 or later.
Monitoring Recommendations
- Centralize ChromaDB application logs, reverse-proxy logs, and authentication events in a SIEM with OCSF-normalized schemas.
- Track high-impact verbs such as delete_collection and update per principal and alert on first-time cross-tenant invocations.
- Monitor for bulk query or get operations that return embeddings from multiple tenant namespaces in a single session.
How to Mitigate CVE-2026-45831
Immediate Actions Required
- Inventory all ChromaDB deployments and identify any instance using SimpleRBACAuthorizationProvider at version 0.5.0 or later.
- Restrict network access to the ChromaDB API so that only trusted application backends can reach it while a fix is rolled out.
- Rotate API tokens and credentials for any tenants that share an authorization-vulnerable ChromaDB instance.
- Review audit logs for cross-tenant access patterns dating back to the deployment of any affected version.
Patch Information
No fixed version is enumerated in the NVD record at the time of writing. Consult the HiddenLayer Security Advisory and the upstream chromadb project release notes for the patched release and upgrade guidance.
Workarounds
- Replace SimpleRBACAuthorizationProvider with an authorization provider that enforces resource scope, or implement a custom provider that validates tenant, database, and collection on every request.
- Run a dedicated ChromaDB instance per tenant so that a cross-tenant action is not reachable through shared infrastructure.
- Place an authorizing reverse proxy in front of ChromaDB that rewrites or validates tenant and database parameters against the authenticated identity.
# Configuration example: isolate ChromaDB per tenant at the network layer
# until an authorization-scoped provider is in place.
export CHROMA_SERVER_AUTHZ_PROVIDER="chromadb.auth.simple_rbac.SimpleRBACAuthorizationProvider"
export CHROMA_SERVER_HOST="127.0.0.1" # bind to loopback
export CHROMA_SERVER_HTTP_PORT="8000"
# Front with a reverse proxy that pins each upstream to a single tenant
# and rejects requests whose tenant/database fields do not match the caller.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

