ChromaDB pre-auth RCE exposes AI pipelines to full server compromise

At a glance

What this is: A critical ChromaDB flaw lets attackers trigger pre-authentication code execution in AI vector database deployments.

Why it matters: It matters because vector databases, RAG backends, and agentic AI pipelines can become direct server-compromise paths if identity and network controls assume authentication always happens first.

By the numbers:

• Approximately 73% of internet-exposed ChromaDB instances are running vulnerable versions according to Shodan-based scanning data.
• ChromaDB is used in approximately 14 million monthly PyPI downloads, giving the flaw a substantial enterprise footprint.

👉 Read Orca Security's analysis of ChromaDB CVE-2026-45829 and AI pipeline exposure

Context

ChromaDB is a vector database used in AI retrieval, semantic search, and agentic application pipelines. The problem here is not a simple software bug in isolation. It is a pre-authentication execution path in infrastructure that many teams treat as trusted backend plumbing, which means the normal assumption that authentication happens before code runs no longer holds.

For IAM and security teams, the exposure is broader than application patching. When an internet-facing AI data service can execute attacker-controlled code before authorization, the blast radius includes secrets, environment variables, mounted credentials, and adjacent infrastructure. That turns a database-tier issue into an identity and access problem because compromise of the runtime can collapse the trust boundaries around the entire AI workflow.

The article’s starting position is atypical only in the sense that ChromaDB is especially popular and exposed; the underlying governance mistake is common across modern AI stacks. Teams often secure model endpoints and forget the retrieval layer can become the earliest and most dangerous execution point.

Key questions

Q: What fails when a vector database can execute code before authentication?

A: The trust boundary fails because the service can run attacker-controlled code before it verifies who sent the request. In that situation, authentication no longer protects the execution path, and secrets, environment variables, and local credentials may be exposed even if the request is later rejected. The issue is sequencing, not just access control.

Q: Why do internet-facing AI retrieval services create outsized risk?

A: They often sit close to prompts, embeddings, API keys, and orchestration credentials, so one runtime compromise can expose more than the service’s own data. If the service can also fetch or load external artifacts, the attack surface includes untrusted code execution as well as data access, which increases the blast radius significantly.

Q: How do security teams know whether an AI backend is safe to expose publicly?

A: A safe exposure decision depends on more than patch level. Teams should verify that authorization happens before any artifact loading, that remote model references are treated as untrusted, and that the service cannot reach sensitive secrets or privileged network paths. If those conditions are not met, public exposure is too risky.

Q: Who is accountable when a pre-authentication RCE affects an AI service?

A: Accountability usually spans application owners, platform teams, and cloud operators because the failure sits across request handling, deployment design, and network exposure. Governance frameworks should assign ownership for runtime execution paths, not just patching, because the key question is who approved an architecture that can execute untrusted input before authentication.

Technical breakdown

Pre-authentication code execution in the FastAPI request path

The flaw sits in ChromaDB’s Python FastAPI server, where user-controlled embedding function configuration is handled before authentication checks complete. That ordering mistake matters because a crafted POST request to the collection creation endpoint can carry a malicious HuggingFace model reference with trust_remote_code enabled. If the server resolves and executes that reference before rejecting the request, the attacker gets arbitrary Python execution without valid credentials. In practice, the attack is not about breaking authentication itself, but about placing executable input ahead of the auth gate.

Practical implication: Treat any internet-facing Python API that evaluates remote model references as an execution surface, not just an access-controlled service.

Why vector database deployments become code-execution targets

Vector databases in RAG and agentic AI systems often sit close to sensitive application context, including prompts, embeddings, tokens, and service credentials. That proximity makes them attractive once remote code execution is possible, because compromise of the database process can expose secrets and pivot into connected services. The architectural issue is that a retrieval backend is often assumed to be data-only, while in reality it may fetch models, load plugins, or interact with orchestration code that expands the trust boundary. ChromaDB shows how quickly that boundary can disappear when untrusted model metadata is allowed to influence runtime behavior.

Practical implication: Separate retrieval services from secret-bearing workloads and review every path that can trigger model loading or code evaluation.

Internet exposure plus unsafe model loading creates a high-risk combination

The reported exposure is amplified by the fact that many ChromaDB instances are internet-facing and that the vulnerable versions are widely deployed. When a service can download and execute remote code during request handling, the issue resembles a supply-chain execution problem inside the request path. In zero-trust terms, the service is trusting a remote artifact before it has established whether the request is even authorized. That is why patching alone is not enough for mature environments: the deployment model, network reachability, and model-source trust chain all contribute to exploitability.

Practical implication: Restrict public access, block untrusted model sources, and verify that runtime artifact loading cannot occur before authorization.

Threat narrative

Attacker objective: The attacker aims to achieve unauthenticated server compromise inside an AI retrieval backend and use that foothold to steal secrets or pivot into connected systems.

1. Entry occurs when an attacker sends a crafted HTTP POST request to the ChromaDB collection creation endpoint with a malicious embedding configuration.
2. Credential access and execution happen when the server downloads and runs attacker-controlled Python code before the request is denied as unauthorized, exposing runtime secrets and environment variables.
3. Impact follows as the attacker gains control of the server process, enabling data theft, lateral movement, and broader infrastructure compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Pre-auth execution in AI backends turns an access-control failure into an identity failure: This vulnerability works because the server evaluates untrusted model configuration before it verifies the caller. That means the auth boundary is placed after the execution boundary, which is a structural failure of trust sequencing rather than a simple missing control. For practitioners, the lesson is that AI retrieval infrastructure cannot be assumed to be inert data plumbing when it can execute remote code as part of request processing.

ChromaDB exposes a runtime trust chain, not just a patching problem: The risky condition is the combination of remote model references, executable Python loading, and internet exposure. That creates what we call a runtime trust chain, where the service depends on external artifacts before it has established authorization or provenance. The implication is that identity and platform teams must evaluate the whole execution path, not just the version number.

Data access controls fail when the server process itself is the target: Once attacker-controlled code runs inside the backend, secrets, environment variables, and mounted credentials are all in scope. That means conventional least privilege at the network perimeter does not prevent compromise if the service can self-execute untrusted content. The control gap is the absence of execution separation between request intake and code evaluation, and practitioners should treat that gap as the real failure mode.

Internet-exposed AI infrastructure needs provenance controls as much as authentication: The article shows that a service can be authenticated by design and still be vulnerable if its runtime ingests untrusted artifacts. In NHI terms, the problem is not only who can call the service, but what the service is allowed to execute on behalf of the caller. Teams should re-evaluate whether their AI stack assumes trusted inputs where provenance controls are actually required.

Pre-authentication code execution is the named failure mode this case makes visible: ChromaDB’s flaw illustrates that some AI services collapse the distinction between request validation and runtime execution. That failure mode should now be treated as a governance category in its own right, because it bypasses ordinary access review logic and makes exposed infrastructure behave like an unauthenticated code runner. The practical conclusion is to redesign AI backend trust boundaries around execution, not just admission.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why lifecycle, access, and trust controls for AI-adjacent infrastructure need to be evaluated with the same discipline as human IAM, according to The State of Non-Human Identity Security.

What this signals

Runtime trust chains: The ChromaDB flaw reinforces a broader programme issue for AI stacks. Teams are increasingly securing authentication at the edge while leaving model loading, retrieval, and artifact execution outside governance, which means the service can still become a code-execution point even when access control looks sound.

At the programme level, this is a reminder to map every AI workload to its executable trust boundaries, not just its network boundaries. If a retrieval service can fetch remote artifacts or interpret user-supplied configuration before auth, it belongs in the same review path as other high-risk non-human identities and shared service runtimes.

The governance signal is structural: identity teams need one view of who can call a service, what the service can execute, and which credentials are exposed if the runtime is compromised. Without that three-part view, patching becomes reactive cleanup rather than risk reduction.

For practitioners

• Block pre-auth code evaluation paths Review every endpoint that accepts model references, embedding functions, or other remote artifacts, and ensure nothing is resolved or executed until authorization is complete. Test for any request path where user input can influence runtime loading before auth.
• Treat remote model sources as untrusted code Scan model artifacts before runtime execution, disable trust_remote_code where possible, and require explicit provenance checks for any external model reference used by a retrieval service.
• Remove internet exposure from Python AI backends Restrict API ports to trusted clients only, place the service behind network controls, and avoid public exposure for workloads that can download or execute code dynamically.
• Separate retrieval services from secret-bearing runtimes Isolate vector databases from mounted secrets, high-value environment variables, and adjacent services that would expand the blast radius after process compromise.
• Verify patch status and deployment paths immediately Confirm whether instances are on version 1.5.9 or later, determine whether the Python FastAPI server is in use, and prioritize exposed assets before lower-risk internal deployments.

Key takeaways

• ChromaDB’s CVE-2026-45829 shows that a pre-authentication execution flaw can turn an AI retrieval backend into an unauthenticated code runner.
• The exposure is substantial because many internet-facing instances are still on vulnerable versions, and compromise can reveal secrets, environment variables, and connected credentials.
• The control that would have mattered most is sequencing: authorization must happen before any remote artifact can be loaded or executed.

Key terms

• Pre-authentication Code Execution: Code execution that occurs before a request is authenticated or rejected. In practice, it means the service can run attacker-controlled logic while still believing it is only processing input, which collapses the usual protection offered by login or authorization checks.
• Runtime Trust Chain: The sequence of external artifacts, model references, loaders, and permissions a service depends on while it runs. When any part of that chain can be influenced by untrusted input, the service may execute content before identity controls or provenance checks can stop it.
• Vector Database Exposure: The risk created when a vector database is reachable from untrusted networks or embedded in sensitive AI workflows. Because these services often sit near prompts, embeddings, and credentials, a compromise can expose more than data, including the runtime and adjacent secrets.
• Trust Remote Code: A setting or design choice that allows downloaded model code to execute inside a local runtime. It is a high-risk capability because it converts external artifacts into executable input, so governance must treat provenance, review, and network exposure as part of the control surface.

Deepen your knowledge

ChromaDB pre-auth execution risk and AI retrieval backend hardening are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are securing AI pipelines that load external artifacts or expose vector databases, it is worth exploring.

This post draws on content published by Orca Security: ChromaDB CVE-2026-45829 and pre-authentication code execution in AI retrieval backends. Read the original.