CVE-2026-85664 in Chroma
Summary
by MITRE • 09/04/2026
Chroma 1.5.9 fails to validate maximum bounds on HNSW index parameters max_neighbors, ef_construction, and ef_search in collection-create requests. Unauthenticated attackers can supply arbitrarily large parameter values to exhaust server memory and cause denial of service during index compaction.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in Chroma version 1.5.9 represents a critical input validation failure within the vector database's core indexing mechanism, specifically affecting the Hierarchical Navigable Small World (HNSW) algorithm implementation used for approximate nearest neighbor searches. HNSW is a graph-based data structure that relies on specific configuration parameters to balance search accuracy against computational efficiency and memory consumption. The three primary parameters involved in this flaw are max_neighbors, which dictates the maximum number of connections per node during index construction; ef_construction, which controls the size of the dynamic candidate list used while building the index; and ef_search, which determines the breadth of the search space during query execution. In a properly secured system, these integer values must be constrained within reasonable bounds to prevent resource exhaustion. However, Chroma 1.5.9 fails to enforce maximum limits on these parameters when processing collection creation requests, allowing clients to specify arbitrarily large numerical values without triggering validation errors or warnings.
This lack of boundary checking creates a direct pathway for unauthenticated attackers to exploit the system through a denial-of-service attack vector. When an attacker submits a request with excessively high values for max_neighbors and ef_construction, the server attempts to allocate memory proportional to these inflated parameters during the index compaction phase. Since HNSW indexes are dense graphs where each node maintains multiple pointers to other nodes, increasing max_neighbors linearly increases the number of edges in the graph. Similarly, a large ef_construction value requires maintaining larger dynamic lists in memory during the construction process. The server does not cap these allocations, leading to rapid and uncontrolled consumption of available system RAM. This resource exhaustion can occur rapidly even with moderate parameter values if they are set sufficiently high relative to the host machine's capacity, effectively starving other processes or causing the Chroma service itself to crash due out-of-memory conditions.
The operational impact of this vulnerability is severe for any deployment relying on Chroma as a persistent vector store. A successful exploitation results in complete unavailability of the search functionality and potentially requires manual intervention such as restarting services or clearing corrupted index files if memory corruption occurs during the allocation failure. Because the flaw affects collection creation, it can be triggered repeatedly by different users or automated scripts to sustain the denial-of-service condition. This is particularly dangerous in multi-tenant environments where resource isolation may not be strictly enforced at the application level, allowing a single malicious actor to degrade performance for all other tenants sharing the same infrastructure. The vulnerability aligns with CWE-20 Improper Input Validation and CWE-400 Uncontrolled Resource Consumption, highlighting fundamental flaws in how external inputs are processed before being used to allocate system resources.
From an offensive security perspective, this flaw maps directly to ATT&CK technique T1496 Resource Hijacking, specifically the sub-category of resource exhaustion via denial-of-service attacks. Attackers can leverage standard HTTP endpoints exposed by Chroma to send crafted payloads that trigger the memory leak or spike without needing any authentication credentials. This makes the vulnerability particularly attractive for automated scanning tools and opportunistic attackers seeking to disrupt services with minimal effort. The absence of rate limiting combined with the lack of input validation amplifies the risk, as there are no built-in safeguards to throttle requests from a single source that exhibit these malicious patterns.
Mitigation strategies must focus on immediate patching and architectural hardening. The primary remediation is to upgrade Chroma to version 1.5.9 or later where this specific validation logic has been corrected to enforce upper bounds on max_neighbors, ef_construction, and ef_search parameters. Until an update can be applied, administrators should implement network-level controls such as Web Application Firewalls (WAF) that inspect request payloads for unusually large integer values in these fields and block them before they reach the application server. Additionally, deploying resource quotas at the container or operating system level using cgroups on Linux systems can limit the maximum memory a Chroma process is allowed to consume, thereby containing the impact of any successful exploitation attempt. It is also advisable to review access controls to ensure that collection creation endpoints are not exposed to untrusted networks if possible, reducing the attack surface available for such input validation bypasses.