Unpatched ChromaDB Vulnerability Exposes AI Servers to Pre-Auth Takeover

By Ash K
Unpatched ChromaDB Vulnerability Exposes AI Servers to Pre-Auth Takeover

The dangerous part of this ChromaDB vulnerability is not just that it enables remote code execution. It is that the server can execute attacker-controlled model code before it decides whether the requester is allowed to be there at all.

Security researchers at HiddenLayer have disclosed CVE-2026-45829, a pre-authentication code injection flaw in ChromaDB’s Python FastAPI server that can allow an unauthenticated attacker with HTTP API access to take control of the server process.

The vulnerability, nicknamed ChromaToast, affects ChromaDB version 1.0.0 and later, and HiddenLayer says it remains unpatched as of ChromaDB 1.5.8. For AI teams running internet-accessible or poorly segmented ChromaDB deployments, this is not a theoretical model-safety issue. It is a server takeover path.

What Happened

HiddenLayer reported that ChromaDB’s Python FastAPI server can process user-supplied embedding function configuration before enforcing authentication. An attacker can send a collection creation request to the /api/v2/tenants/{tenant}/databases/{db}/collections endpoint without credentials and point the server to a malicious Hugging Face model repository.

The attack hinges on the trust_remote_code option. When set to true, Hugging Face model-loading logic can download and execute Python code shipped with a model repository. That feature has legitimate uses for custom model architectures, but in this case it becomes the payload delivery mechanism.

According to HiddenLayer, ChromaDB accepts the unauthenticated request, reaches out to Hugging Face, downloads the attacker-controlled model, and executes it. Only after that does the server perform the authentication check and reject the request. From the API client’s perspective, the request may look like a failed call. On the attacker’s side, the code has already run.

Why This Stands Out

This is a clean example of an authentication-ordering failure with AI-specific consequences. The endpoint is intended to be authenticated, but the risky work happens too early in the request lifecycle.

HiddenLayer described the root cause as two compounding failures: ChromaDB trusts client-supplied model identifiers without sufficient restriction, and it acts on that trust before authenticating the user sending the request.

That combination matters because model loading is not passive. A model repository can contain executable code. If a server accepts a user-controlled model reference and allows remote code execution flags to pass through unchecked, the model registry effectively becomes part of the application’s attack surface.

Impact on Vulnerable Deployments

Successful exploitation can give the attacker control of the ChromaDB server process. From there, the attacker may be able to access anything that process can reach, including environment variables, API keys, mounted secrets, application data, and files stored on disk.

That impact is especially serious for AI and retrieval-augmented generation environments. Vector databases often sit close to sensitive business data, internal documents, embeddings, application credentials, and service integrations. A compromised ChromaDB server can become a pivot point into the broader AI application stack.

HiddenLayer said ChromaDB has roughly 13 million monthly pip downloads and 27,500 GitHub stars. The company also reported that 73% of internet-exposed ChromaDB instances it discovered through Shodan were running version 1.0.0 or later, the range where the vulnerable feature exists.

Affected Versions and Patch Status

CVE-2026-45829 affects ChromaDB Python project version 1.0.0 and later. The National Vulnerability Database describes the issue as a pre-authentication code injection vulnerability that allows an unauthenticated attacker to run arbitrary code by sending a malicious model repository and setting trust_remote_code to true.

HiddenLayer said the issue was unpatched as of ChromaDB 1.5.8. The researchers said full remediation would require moving the authentication check before configuration loading and stripping any keys named kwargs from requests in both V1 and V2 create_collection handlers.

The disclosure timeline published by HiddenLayer says the company first contacted ChromaDB on February 17, 2026, followed up on February 24, contacted through IT-ISAC on March 5, and made a final follow-up attempt on April 16.

Mitigation Guidance

Until a patch is available, HiddenLayer recommends favoring the Rust-based deployment path, including chroma run and Docker Hub images since version 1.0.0, rather than the affected Python FastAPI server path.

Organizations running the Python FastAPI server should restrict network access to the ChromaDB port to trusted clients only. That means no direct internet exposure, no broad internal access, and no assumption that an “authenticated” API route is safe if unauthenticated traffic can still reach the service.

Defenders should also review ChromaDB deployments for unexpected outbound connections to model repositories, unusual process activity from the ChromaDB service account, suspicious environment variable access, and newly created files or shells spawned by the database process.

The Bigger AI Security Lesson

ChromaToast is not just a ChromaDB story. It is a warning about how AI infrastructure changes old security assumptions.

Traditional databases store and retrieve data. AI infrastructure often fetches, loads, transforms, and executes model-linked artifacts as part of normal operation. That makes model configuration, model repositories, and runtime loading behavior part of the security boundary.

The trust_remote_code flag is the clearest signal here. It does exactly what the name says. When that trust decision can be influenced by an unauthenticated remote client, the application is no longer just processing a request. It is importing attacker-controlled code into its runtime.

NeuraCyb's Assessment

CVE-2026-45829 should push security teams to treat vector databases as production infrastructure, not developer-side AI plumbing. If ChromaDB is reachable over the network, it deserves the same controls as any exposed database or application server: authentication enforcement, segmentation, egress controls, runtime monitoring, and emergency isolation capability.

The sharp takeaway is this: in AI systems, “loading a model” can be equivalent to running code. Any platform that lets users influence that loading path before authentication has already lost the first and most important security check.

References

HiddenLayer: ChromaToast Served Pre-Auth

NVD: CVE-2026-45829 Detail

SecurityWeek: Unpatched ChromaDB Vulnerability Can Lead to Server Takeover

GitHub: ChromaDB Python Backend Server Side RCE Discussion

Ash K
Ash K
Ashton is a seasoned Cybersecurity Professional with over 25 years of experience in Cybersecurity Research, Cybersecurity Incident response, Products and Security Solutions architecture.