CVE-2026-85664: Chroma HNSW Index DOS Vulnerability

CVE-2026-85664 Overview

CVE-2026-85664 affects Chroma version 1.5.9, an open-source vector database used in AI and retrieval-augmented generation (RAG) pipelines. The vulnerability stems from missing upper-bound validation on Hierarchical Navigable Small World (HNSW) index parameters in collection-create requests. Unauthenticated attackers can submit arbitrarily large values for max_neighbors, ef_construction, and ef_search. When the server later performs index compaction, memory usage grows unbounded and exhausts host resources. The result is a denial of service against the Chroma instance and any application depending on it. The issue is tracked under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
Unauthenticated remote attackers can trigger memory exhaustion and take Chroma 1.5.9 offline by supplying oversized HNSW index parameters in a single collection-create request.

Affected Products

Chroma 1.5.9 (open-source vector database)
Deployments exposing the Chroma frontend API without authentication enforcement
AI/RAG applications embedding Chroma 1.5.9 as a backing store

Discovery Timeline

2026-09-04 - CVE-2026-85664 published to NVD
2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-85664

Vulnerability Analysis

Chroma uses HNSW graphs to index vector embeddings for similarity search. Three parameters control graph construction and query behavior: max_neighbors sets the fan-out per node, ef_construction governs candidate list size during build, and ef_search controls candidate list size during query. Memory consumption scales with each parameter. In version 1.5.9, the collection-create endpoint accepts these values without enforcing maximum bounds. A single request supplying extreme values causes the compaction stage to allocate memory proportional to the requested graph size. The process consumes available RAM and swap until the operating system terminates it or the host becomes unresponsive. See the VulnCheck advisory for Chroma for full technical writeup.

Root Cause

The HNSW configuration handling in rust/types/src/hnsw_configuration.rs performs no maximum-value validation on user-supplied index parameters. Combined with an authentication module in rust/frontend/src/auth/mod.rs that permits unauthenticated access in default deployments, any network-reachable caller can submit malicious values. The tracking issue is documented in GitHub Issue #7225.

Attack Vector

Exploitation requires only network access to the Chroma HTTP API. An attacker sends a POST request to the collection-create endpoint containing an HNSW configuration with excessive parameter values. No authentication, user interaction, or prior foothold is required. The attack succeeds during background index compaction rather than at request time, delaying the visible failure and complicating attribution.

Because no verified proof-of-concept code is published, this article does not include exploit code. Refer to the Chroma source repository and the linked advisory for parameter semantics.

Detection Methods for CVE-2026-85664

Indicators of Compromise

HTTP requests to Chroma collection-create endpoints containing HNSW parameter values orders of magnitude above documented defaults
Sudden RSS growth of the Chroma server process followed by out-of-memory (OOM) termination in kernel logs
Repeated collection-create requests from a single source IP shortly before service degradation

Detection Strategies

Inspect API gateway or reverse-proxy logs for JSON payloads containing max_neighbors, ef_construction, or ef_search fields with values exceeding organizational baselines
Alert on Chroma processes exceeding memory thresholds or triggering cgroup OOM kills within container orchestrators
Correlate collection-create events with subsequent compaction failures in Chroma application logs

Monitoring Recommendations

Export Chroma process memory metrics to your observability stack and set thresholds well below host capacity
Enable audit logging on the frontend API and forward events to a centralized log platform for retention and analysis
Track collection creation rates per source and flag anomalous spikes for review

How to Mitigate CVE-2026-85664

Immediate Actions Required

Restrict network access to the Chroma API using firewalls, security groups, or a reverse proxy that terminates untrusted traffic
Enable authentication on the Chroma frontend and disable anonymous collection creation where feasible
Deploy request-body validation at the proxy layer to reject collection-create payloads containing oversized HNSW parameters
Apply resource limits (cgroup memory caps, Kubernetes resources.limits.memory) to contain memory exhaustion impact

Patch Information

No fixed version is listed in the enriched CVE data at the time of publication. Monitor the Chroma GitHub repository and Issue #7225 for a maintainer response and upgrade guidance. Upgrade from 1.5.9 as soon as a patched release is available.

Workarounds

Front the Chroma API with a Web Application Firewall (WAF) rule that caps max_neighbors, ef_construction, and ef_search to sane maxima (for example, aligned to documented defaults)
Run Chroma in a container with a hard memory limit so OOM events terminate only the affected pod rather than the host
Place Chroma behind an authenticated ingress and disallow collection creation for untrusted principals via network policy or application-layer authorization

bash

# Example NGINX snippet: reject oversized HNSW parameters before they reach Chroma
# Adjust thresholds to match your deployment's documented defaults
map $request_body $hnsw_too_large {
    default 0;
    "~*\"max_neighbors\"\s*:\s*[0-9]{4,}"      1;
    "~*\"ef_construction\"\s*:\s*[0-9]{5,}"    1;
    "~*\"ef_search\"\s*:\s*[0-9]{5,}"          1;
}

server {
    location /api/v1/collections {
        if ($hnsw_too_large) { return 413; }
        proxy_pass http://chroma_upstream;
    }
}