CVE-2026-45833: ChromaDB: RCE via trust_remote_code in collection update

CRITICAL
Published June 12, 2026
CISO Take

ChromaDB versions 0.4.17 and later contain a code injection flaw that allows any authenticated user holding UPDATE_COLLECTION permission to execute arbitrary code on the server by supplying a malicious model repository URL with trust_remote_code set to true in the collection update API. The blast radius is significant: ChromaDB is a foundational vector store in a large share of production RAG architectures, so server compromise directly threatens the data pipelines feeding your LLM stack—including exfiltration of all stored embeddings and their source documents. Although no public exploit or CISA KEV entry exists yet, the trust_remote_code attack pattern is extensively documented in the ML ecosystem and trivial to operationalize once an attacker holds valid credentials, making the effective exploitation bar lower than the authentication prerequisite suggests. Organizations should immediately audit UPDATE_COLLECTION permission grants, enforce trust_remote_code=false at the configuration layer, isolate ChromaDB from direct internet exposure, and patch to a fixed release as soon as it is available from the vendor.

Sources: NVD ATLAS HiddenLayer Advisory (hiddenlayer.com)

What is the risk?

High urgency despite the authentication requirement. UPDATE_COLLECTION is a routine permission held by developers, integration service accounts, and CI/CD pipelines—all common targets for credential theft or insider abuse. Once that threshold is crossed, exploitation is deterministic: trust_remote_code=true is a deliberate design mechanism that bypasses all server-side code validation, making the payload delivery and execution reliable with no further bypass needed. The CVE was published on 2026-06-12 with no EPSS data yet, but CWE-94 code injection exploits in popular ML tooling have historically seen rapid weaponization. ChromaDB's prevalence across RAG stacks in enterprises adopting generative AI amplifies the organizational reach of a single exploited instance.

How does the attack unfold?

Credential Access
Attacker obtains valid ChromaDB credentials with UPDATE_COLLECTION permission via phishing, credential stuffing against a developer account, or abuse of a compromised CI/CD service account.
AML.T0012
Malicious Artifact Staging
Attacker publishes a Python model repository containing a reverse shell or RAT payload embedded in a model-loading hook to a public or attacker-controlled hosting platform.
AML.T0011.000
API Exploitation
Attacker sends a crafted PATCH request to the ChromaDB collection update endpoint referencing the malicious repository URL with trust_remote_code=true, triggering deterministic server-side code execution.
AML.T0049
Full Server Compromise
ChromaDB executes attacker-controlled code in its server process, enabling exfiltration of all vector embeddings and source documents, credential theft from the host environment, and persistent backdoor installation.
AML.T0050

What systems are affected?

Package Ecosystem Vulnerable Range Patched
ChromaDB pip No patch
28.2K OpenSSF 5.0 1.2K dependents Pushed 6d ago 0% patched Full package profile →

Do you use ChromaDB? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

5 steps
  1. Immediate: Set trust_remote_code=false globally in ChromaDB configuration and implement API-layer input validation to reject any collection update request containing a model repository URI or the trust_remote_code parameter.

  2. Permission audit: Enumerate all accounts with UPDATE_COLLECTION permission; revoke from non-essential service accounts and developer accounts in production; enforce least-privilege.

  3. Network segmentation: Ensure ChromaDB API ports are not directly internet-reachable; place behind an authenticated reverse proxy or API gateway with request logging.

  4. Patch: Monitor the ChromaDB GitHub repository and the HiddenLayer advisory (https://www.hiddenlayer.com/sai-security-advisory/2026-06-chromadb-5) for a fixed release; upgrade immediately upon availability.

  5. Detection: Alert on any UPDATE_COLLECTION API calls that include model repository fields or the trust_remote_code parameter; enable full request-body logging for the collection update endpoint and ship to SIEM.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system
ISO 42001
A.6.2.6 - AI supply chain security A.9.5 - AI system security
NIST AI RMF
GOVERN 6.2 - AI risk and impact — third-party components MANAGE 2.2 - Risk response — incident and vulnerability response
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities LLM08 - Vector and Embedding Weaknesses

Frequently Asked Questions

What is CVE-2026-45833?

ChromaDB versions 0.4.17 and later contain a code injection flaw that allows any authenticated user holding UPDATE_COLLECTION permission to execute arbitrary code on the server by supplying a malicious model repository URL with trust_remote_code set to true in the collection update API. The blast radius is significant: ChromaDB is a foundational vector store in a large share of production RAG architectures, so server compromise directly threatens the data pipelines feeding your LLM stack—including exfiltration of all stored embeddings and their source documents. Although no public exploit or CISA KEV entry exists yet, the trust_remote_code attack pattern is extensively documented in the ML ecosystem and trivial to operationalize once an attacker holds valid credentials, making the effective exploitation bar lower than the authentication prerequisite suggests. Organizations should immediately audit UPDATE_COLLECTION permission grants, enforce trust_remote_code=false at the configuration layer, isolate ChromaDB from direct internet exposure, and patch to a fixed release as soon as it is available from the vendor.

Is CVE-2026-45833 actively exploited?

No confirmed active exploitation of CVE-2026-45833 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-45833?

1. Immediate: Set trust_remote_code=false globally in ChromaDB configuration and implement API-layer input validation to reject any collection update request containing a model repository URI or the trust_remote_code parameter. 2. Permission audit: Enumerate all accounts with UPDATE_COLLECTION permission; revoke from non-essential service accounts and developer accounts in production; enforce least-privilege. 3. Network segmentation: Ensure ChromaDB API ports are not directly internet-reachable; place behind an authenticated reverse proxy or API gateway with request logging. 4. Patch: Monitor the ChromaDB GitHub repository and the HiddenLayer advisory (https://www.hiddenlayer.com/sai-security-advisory/2026-06-chromadb-5) for a fixed release; upgrade immediately upon availability. 5. Detection: Alert on any UPDATE_COLLECTION API calls that include model repository fields or the trust_remote_code parameter; enable full request-body logging for the collection update endpoint and ship to SIEM.

What systems are affected by CVE-2026-45833?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, AI/ML platforms, agent frameworks, LLM application stacks.

What is the CVSS score for CVE-2026-45833?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasesAI/ML platformsagent frameworksLLM application stacks

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0012 Valid Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15, Article 9
ISO 42001: A.6.2.6, A.9.5
NIST AI RMF: GOVERN 6.2, MANAGE 2.2
OWASP LLM Top 10: LLM03, LLM08

What are the technical details?

Original Advisory

A code injection vulnerability in version 0.4.17 or later of the ChromaDB Python project allows an authenticated attacker to run arbitrary code on the server by sending a malicious model repository and trust_remote_code set to true in the /api/v2/tenants/default_tenant/databases/default_database/collections/{collection_id} if they have the UPDATE_COLLECTION permission.

Exploitation Scenario

An attacker with a legitimate ChromaDB account—obtained via credential stuffing against a developer's reused password or through a compromised CI/CD service account—prepares a malicious Python model repository on a public platform such as Hugging Face Hub or a self-controlled server. The repository embeds a reverse shell payload inside a custom from_pretrained loading hook. The attacker issues a PATCH request to /api/v2/tenants/default_tenant/databases/default_database/collections/{collection_id} with a JSON body specifying the malicious repository URL and trust_remote_code=true. ChromaDB fetches and executes the repository code server-side, establishing a reverse shell to the attacker's C2 infrastructure. From that foothold, the attacker exfiltrates all vector embeddings, document chunks, and environment credentials—then optionally inserts poisoned vectors to degrade or manipulate RAG outputs for the targeted organization.

Weaknesses (CWE)

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

  • [Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
  • [Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.

Timeline

Published
June 12, 2026
Last Modified
June 12, 2026
First Seen
June 12, 2026

Related Vulnerabilities