Skip to content

CVE-2026-45829 (chromadb) — risk assessment

Dependabot flagged this as a critical alert on chromadb (pinned at 1.5.9, the current latest release — no patched version exists upstream as of this assessment). Documented here rather than left as an unexplained open alert, following the same verify-against-the-real-code discipline as tool-seam-threat-model.md.

The vulnerability

GHSA-f4j7-r4q5-qw2c / CVE-2026-45829, critical (CVSS v4 9.3). Two related code-injection paths, per the upstream report (chroma-core/chroma#6717):

  1. Server-mode RCE. An unauthenticated attacker hits the ChromaDB HTTP server's /api/v2/tenants/{tenant}/databases/{db}/collections endpoint with a malicious model repository and trust_remote_code=true, achieving code execution on the server.
  2. Client-side RCE via a poisoned collection. If an attacker can write to a collection in advance, a client that later interacts with it normally can trigger code execution through the embedding-function configuration retrieval mechanism.

No patched version exists yet upstream (as of this writing, 1.5.9 — the version already pinned here — is both the latest release and the top of the vulnerable range).

Why neither path applies to kb-agent today

Checked against the real code (agent/tools.py, scripts/index.py), not assumed:

  • No server mode. Every use of chromadb here is chromadb.PersistentClient(path=...) — an embedded, in-process, file-backed client. kb-agent never starts the ChromaDB HTTP server, so path 1's endpoint doesn't exist to attack.
  • trust_remote_code is never set. Grepped the whole repo — the flag path 1 needs doesn't appear anywhere.
  • No attacker has write access to the collection. scripts/index.py's main() is the only writer of the knowledge_base collection, and it writes exclusively from kb/**/*.md — files this same pipeline generates locally from the user's own project manifests (ingest.py) — plus the user's own notes. This holds whether it rebuilds from scratch (--rebuild: delete_collection then create_collection) or updates incrementally (the default: get_or_create_collection, then upsert changed chunks and delete stale ones). The incremental path persists the collection across runs, but adds no new writer and no new source — chroma_db/ is local, gitignored, and never shared or network-exposed, so there is still no external party who could "poison the collection in advance" for path 2 to exploit.
  • No custom embedding-function config. create_collection() is called with no embedding_function argument, so there's no serialized config for path 2's retrieval mechanism to deserialize in the first place — chromadb's own default (all-MiniLM-L6-v2, run locally) is used.

What would change this assessment

Re-run this check if any of the following ever becomes true:

  • kb-agent starts running ChromaDB in server mode (HttpClient, or hosting the ChromaDB server itself) instead of PersistentClient.
  • Any code path sets trust_remote_code=True.
  • chroma_db/ is ever shared, synced, or populated from a source kb-agent doesn't fully control (e.g. ingesting a collection built by another machine/user).
  • A patched chromadb version ships — bump to it regardless of the above, since a real fix is strictly better than an assessed-safe workaround.

Disposition

Dismissing the Dependabot alert as tolerable risk, with a link back to this file, rather than leaving a "critical, unaddressed" flag with no accompanying explanation.