SAI Security Advisory

Cross-Tenant Data Access via IDOR in Collection Lookup

June 12, 2026

CVE Number

CVE-2026-8828

‍

Summary

The same vulnerability as CVE-2026-45830 is present in the Rust codebase. Any authenticated user with a valid collection UUID can read, write, update, or delete data in any tenant's collection regardless of which tenant they belong to. ChromaDB's collection lookup skips the tenant and database filter when a UUID is provided. 

‍

Products Impacted

This vulnerability affects the Rust ChromaDB versions from 1.0.0 to the latest release.

‍

CVSS Score: 8.8

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

‍

CWE Categorization

CWE-639: Authorization Bypass Through User-Controlled Key

‍

Details

The Rust Axum-based frontend, used in production distributed deployments and configured via the Kubernetes Helm chart at k8s/distributed-chroma/, contains the identical IDOR across all three backend paths. The vulnerability is systemic, it exists in every sysdb implementation, not just the Python SQLite path.

Looking at the Rust SQLite backend (rust/sysdb/src/sysdb.rs:547), the SysDb::Sqlite variant drops the database parameter entirely:

‍

SysDb::Sqlite(sqlite) => sqlite.get_collection_with_segments(collection_id).await,
       // database parameter is not passed

‍

The underlying sqlite.rs:635-681 calls get_collections_with_conn() with None for tenant, database, and name:

‍

let collections = self
            .get_collections_with_conn(&mut *tx, Some(collection_id), None, None, None, None, 0)
            .await?;

‍

The query builder at sqlite.rs:709-761 uses sea_query::Cond::all().add_option(). When values are None, no WHERE condition is added. The collection is resolved purely by UUID.

The Rust Spanner backend (rust/rust-sysdb/src/spanner.rs:1091-1134) SQL Query has no tenant or database filter at all:

‍

WHERE c.collection_id = @collection_id AND c.is_deleted = FALSE

‍

The lack of AND c.tenant = @tenant clause causes the IDOR in the production Spanner backend used in Chroma Cloud and enterprise deployments.

‍

Timeline

  • February 17th, 2026 - Initial disclosure to ChromaDB per their security page https://www.trychroma.com/security. 
  • February 24th, 2026 - Attempted follow up through other trychroma emails.
  • March 5th, 2026 - Attempted contact through IT-ISAC.
  • April 16th, 2026 - Attempted final follow up through all previous channels and social media.
  • May 18th, 2026 - Publicly disclosed a first vulnerability, no response from the vendor.

‍

Project URL:

https://www.trychroma.com/

https://github.com/chroma-core/chroma/

‍

RESEARCHER: Esteban Tonglet, Security Researcher, HiddenLayer

Related SAI Security Advisory

CVE-2026-45833

June 12, 2026

Post-Authentication RCE via update_collection

ChromaDB

Any authenticated user with UPDATE_COLLECTION permission can achieve remote code execution by updating a collection's embedding function to reference a malicious HuggingFace model with trust_remote_code: true. The update_collection endpoint uses the same build_from_config() code path as CVE-2026-45829. Authentication runs before model loading, so this is not a pre-authentication issue, but the model instantiation itself is unguarded.

June 2026
CVE-2026-45832

June 12, 2026

V1 API Tenant Isolation Bypass via Null Tenant/Database Context

ChromaDB

All V1 collection-level endpoints pass None for tenant and database to the authorization layer, making tenant-scoped access control impossible through V1, regardless of which authorization provider is configured. V1 cannot be disabled. Combined with CVE-2026-45830, any authenticated user has unrestricted read/write access to any collection by UUID through V1 endpoints.

June 2026