Unpatched CVSS 10 Alert: ChromaDB Python Server Grants Pre-Auth RCE via Malicious Hugging Face Models

ChromaDB, one of the most widely adopted open-source vector databases engineered to enable semantic matching, retrieval-augmented generation (RAG), and memory retention in AI applications, is facing a severe security flaw. A newly released technical report from HiddenLayer has exposed a critical flaw that grants completely unauthenticated attackers full remote code execution (RCE) over vulnerable instances.

With a maximum CVSS base score of 10.0, the vulnerability threatens a significant portion of the enterprise AI landscape. Boasting over 13 million monthly pip downloads and more than 27,500 GitHub stars, ChromaDB’s footprint stretches across prominent tech organizations and Fortune 500 giants alike, including publicly documented production dependencies at Mintlify, Weights & Biases, Factory AI, Capital One, and United Healthcare.

The underlying mechanics of the vulnerability, tracked as CVE-2026-45829, trace back to a classic architectural flaw: performing unsafe, user-controlled initializations before enforcing identity validation gates.

When developers interact with ChromaDB’s built-in API documentation page, the endpoint for creating new data collections (POST /api/v2/tenants/{tenant}/databases/{db}/collections) is explicitly labeled as an authenticated route. Under standard operations, this design reassures security teams that any unauthenticated external requests will be promptly dropped at the perimeter.

However, HiddenLayer’s reverse-engineering efforts exposed a fatal sequence of operations within the database’s Python FastAPI server implementation. As HiddenLayer explains in the report:

“ChromaDB’s Python FastAPI server can instantiate user-controlled embedding function settings before checking access permissions. This allows an unauthenticated attacker with HTTP API access to trigger remote code execution (RCE) by supplying a malicious Hugging Face model reference, giving the attacker full control of the server process.”

By passing a custom model configuration inside the embedding_function metadata block of the HTTP request, an attacker can trick the server into stepping away from the verification check. The server reads the configuration, reaches out to a public registry to pull down the model, and initializes the execution environment before ever evaluating whether the bearer token or session cookie is valid.

The core catalyst that transforms this authentication ordering bypass into full system compromise is how the Python ecosystem interacts with public model registries like Hugging Face.

Many modern machine learning models require custom configuration blocks or execution scripts to parse input data properly. To accommodate this, Python clients support the parameter trust_remote_code=True, which authorizes the application to dynamically download and execute arbitrary Python code packaged directly inside the remote model repository.

By supplying an unauthenticated request pointing to a poisoned Hugging Face repository containing an embedded exploit payload, the attacker forces the underlying ChromaDB server process to pull down and reflectively execute the malicious code natively. HiddenLayer highlights that the flaw relies on a compounding failure of design principles:

“The root cause of CVE-2026-45829 (CVSS 10) is two independent failures that compound each other. The server trusts client-supplied model identifiers without restriction, and acts on that trust before authenticating the user sending the request.”

The vulnerability is confirmed to have been introduced during a major feature overhaul in version 1.0.0 and remains entirely unpatched across subsequent updates up to the current 1.5.8 build.

To quantify the real-world impact of the bug, HiddenLayer conducted a global scanning sweep of internet-facing database infrastructure using the Shodan search engine. The resulting exposure metrics are deeply concerning for enterprise security teams:

“The vulnerability was introduced in version 1.0.0 and is unpatched as of version 1.5.8. Of internet-exposed ChromaDB instances we discovered via Shodan, 73% are running version 1.0.0 or later, the version range in which the vulnerable feature exists.”

This means that nearly three-quarters of all publicly accessible ChromaDB deployments worldwide are currently sitting entirely unprotected against a single-request zero-day exploit execution vector.