Cross-Tenant Data Access via IDOR in Collection Lookup

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