CVE-2024-34351: ChromaDB RCE via MinJinja Template Injection

The Impact of CVE-2024-34351 on AI Infrastructure

ChromaDB, a widely adopted open-source vector database designed for Large Language Model (LLM) applications, has been found vulnerable to a maximum-severity unauthenticated RCE flaw. Tracked as CVE-2024-34351, the vulnerability carries a CVSS score of 10.0, indicating the highest level of risk to affected systems. According to BleepingComputer, this vulnerability allows an attacker to execute arbitrary Python code on the host server without requiring any authentication credentials.

The rise of generative AI has led many organizations to deploy vector databases like ChromaDB to store and retrieve embeddings. Because these databases often sit at the core of an AI application’s data flow, a compromise at this level can lead to complete data exfiltration, Lateral Movement within the cloud environment, and the poisoning of AI training data. Security researchers discovered that the flaw resides in the way the database handles metadata filtering expressions, which are processed during query execution.

Technical Analysis: Server-Side Template Injection via MinJinja

The root cause of the CVE lies in ChromaDB’s implementation of the MinJinja template engine. MinJinja is a lightweight template engine for Rust and Python, often used for dynamic content generation. In ChromaDB versions up to 0.5.0, the system permitted the evaluation of user-supplied expressions within metadata filters. Specifically, when a user performs a query with a ‘where’ clause, the backend processes these filters using MinJinja.

An attacker can craft a malicious query containing a specially formatted string that escapes the intended template sandbox. By injecting Python-compatible instructions into the template, the attacker triggers a Server-Side Template Injection (SSTI). Since the FastAPI server running ChromaDB processes these requests with the privileges of the service account, the injected code runs directly on the underlying operating system. This lack of input sanitization transforms a simple database query into a gateway for full system hijacking.

How to detect CVE-2024-34351 exploit attempts

Security teams and the SOC should prioritize visibility into incoming HTTP traffic directed at ChromaDB API endpoints. To understand how to detect CVE-2024-34351 exploit attempts, defenders should look for unusual characters or Python-like syntax (e.g., double curly braces {{ }}, underscores __, or calls to self, config, or request) within the JSON payloads of POST requests to /api/v1/collections/{id}/query.

Furthermore, monitoring for unexpected outbound network connections from the ChromaDB container or server is a strong IoC. Attackers successfully exploiting this vulnerability typically attempt to establish a C2 channel or download secondary payloads via curl or wget once code execution is achieved.

Remediation and Patch Guidance

The most effective mitigation is the application of the official ChromaDB 0.5.0 remote code execution fix, which was released in version 0.5.1. This update introduces stricter validation for metadata filters and restricts the capabilities of the MinJinja environment to prevent template escape. Organizations utilizing ChromaDB in a production environment should verify their current version immediately using pip show chromadb or by checking the container image tags.

In addition to patching, the following defensive measures should be implemented:

• Network Isolation: Ensure that ChromaDB instances are not directly accessible from the public internet. Use a VPN or internal load balancer with strict access control lists (ACLs).
• Least Privilege: Run the ChromaDB process as a non-privileged user inside a containerized environment to limit the impact of a potential breakout.
• Runtime Monitoring: Deploy EDR solutions on the host or use cloud-native security tools to detect anomalous process spawns, such as sh or bash being executed by the Python FastAPI process.