A Single HTTP Request Hands Out Shells on Most Public ChromaDB Servers

A pre-auth RCE in one of the most-deployed vector databases just went public — and the vendor never replied

On May 18, 2026, HiddenLayer disclosed CVE-2026-45829, a maximum-severity vulnerability in ChromaDB's Python FastAPI server. The flaw, nicknamed "ChromaToast," lets any unauthenticated attacker with network access trigger arbitrary code execution by sending a single crafted HTTP request. HiddenLayer first reported the issue to ChromaDB on February 17, 2026. Three months and four follow-up attempts later, there is still no patched version.

BleepingComputer and SecurityWeek both confirmed the disclosure on May 19. The Shodan scan that accompanied the research found that 73% of internet-exposed ChromaDB instances are running an affected version.

What we know

ChromaDB is the vector database under a large slice of the production retrieval-augmented generation stack — 13 million pip downloads per month, public production deployments at Mintlify, Weights & Biases, and Factory AI, and a homepage that lists Capital One and UnitedHealthcare as customers. The CVE affects versions 1.0.0 through 1.5.8 of the Python server. The Rust frontend is not affected. The full technical writeup is available from HiddenLayer's research team.

• The vulnerable endpoint is the collection-creation route. The server accepts an embedding function configuration from the client, fetches the named model from HuggingFace, and instantiates it — all before checking authentication.
• The client controls two of the inputs that matter: model_name (which can point to any HuggingFace repository) and the trust_remote_code: true flag (which tells HuggingFace to download and execute Python code shipped inside the model).
• After the model has already run, the server fires its auth check, returns a 500, and looks like a failed API call from the outside. The attacker already has a shell with access to environment variables, mounted secrets, and on-disk data.
• HiddenLayer's disclosure timeline shows the report was sent to the address on ChromaDB's security page, then followed up four times — including through IT-ISAC. None of the messages got a response.

Why it matters

Vector databases sit downstream of every embedding pipeline and upstream of every RAG-backed agent. A shell on the ChromaDB process gives the attacker the environment variables, mounted secrets, model files, and embedded documents the application has been trusting to that process. For most production deployments, that includes the LLM provider API keys, any cloud-storage credentials the indexer needed, and the source documents being embedded — frequently customer data.

The deeper problem is not specific to ChromaDB. Any AI service that loads models from a public registry inherits the trust assumptions of that registry. A model is not passive data; it is code, and trust_remote_code: true is the flag that says "I have read this code and I accept what it does." Letting an unauthenticated user set that flag on the server's behalf is not a parser bug — it is an architectural one.

What to do about it

1. Pull the Python FastAPI server off the public internet today. If you cannot move to the Rust deployment path, put the API port behind a private network or zero-trust proxy. The vulnerable feature exists in every version since 1.0.0 — there is no patched version to upgrade to.
2. Treat any internet-exposed instance as potentially compromised. Rotate the LLM provider keys, cloud credentials, and any other secrets that lived in the process environment, and review storage for data the application has embedded since 1.0.0.
3. Scan model artifacts before they reach any runtime. Malicious trust_remote_code payloads have identifiable patterns in the module files they ship. Apply the same provenance discipline to HuggingFace pulls that you already apply to npm and PyPI.

Bottom line

The pattern that broke ChromaDB — trusting client-supplied model identifiers, then authenticating later — will appear in other AI infrastructure projects, because the convenience of "just pull the model from HuggingFace" pushes every framework toward it. CVE-2026-45829 is a max-severity flaw in one widely deployed product today. The architectural lesson is what matters tomorrow: an embedding function configuration submitted by an untrusted user is attacker-controlled code execution. Build the perimeter accordingly.