← BACK TO FEED
ChromaDBRCEunpatched vulnerabilityvector databaseAI security

ChromaDB Has an Unpatched RCE Flaw and Its Developers Aren't Picking Up the Phone

An unpatched remote code execution vulnerability (CVE-2026-45829, dubbed "ChromaToast") in ChromaDB allows unauthenticated attackers to gain full shell access to a server by supplying a malicious HuggingFace model identifier, which the server downloads and executes *before* performing any authentication checks. The flaw affects all ChromaDB versions since 1.0.0 and approximately 73% of internet-accessible deployments, potentially exposing sensitive data such as API keys, environment variables, and files. Despite multiple disclosure attempts by both HiddenLayer (from February 2025) and an independent researcher (from November 2025), Chroma has not responded or issued a patch as of version 1.5.8, leaving administrators to mitigate the risk by restricting network access to trusted clients only.

A critical remote code execution vulnerability in ChromaDB has been sitting unpatched for months, and the people who built it apparently can't be reached for comment. That's not a great look for a vector database pulling around 13 million pip downloads a month.

The flaw, tracked as CVE-2026-45829 and dubbed ChromaToast by the researchers at HiddenLayer who found it, lets an unauthenticated attacker spawn a shell and take over the server process entirely. No credentials required. Once in, everything the server can touch is fair game: API keys, environment variables, mounted secrets, files on disk. The works.

The root cause is fairly straightforward, and that's what makes it embarrassing. ChromaDB accepts client-supplied model identifiers and acts on them before it ever bothers checking whether the person sending the request is authorised to do so. The authentication check happens after the damage is already done.

HiddenLayer demonstrated this by sending a collection creation request with no credentials attached, pointing at a crafted HuggingFace model. The server dutifully fetched it, downloaded it, and executed it. Only then did it notice something was off and reject the request. By that point, of course, the attacker already had shell access.

The bug affects every ChromaDB release from version 1.0.0 onwards. HiddenLayer estimates roughly 73% of internet-exposed deployments are currently vulnerable. High-profile users of ChromaDB include Mintlify, Factory AI, and Weights & Biases, so the potential blast radius here isn't trivial.

The fix isn't complicated. Move the authentication check to before any configuration loading happens, and strip 'kwargs' keys from collection creation requests in both the V1 and V2 handlers. Simple in theory. Yet as of ChromaDB 1.5.8, none of it has been implemented.

What makes this worse is the disclosure timeline. HiddenLayer says it started trying to contact Chroma on February 17th through multiple channels and received nothing back. An independent researcher named Azraelxuemo reportedly flagged the same issue back in November 2025 and was similarly ignored.

Until a patch materialises, the only practical mitigation is restricting network access to ChromaDB so only trusted clients can reach it. If your deployment is sitting exposed to the internet, that's a problem you need to fix today, not when Chroma eventually gets around to responding to security researchers.

SecurityWeek reached out to Chroma for comment. We're not holding our breath.