Vector Database Security: Qdrant, Milvus, Weaviate, Chroma

Weaviate has not changed this. In the v1.39.0 source, the fallback authentication scheme is literally a struct with anonymous access set to true, and the startup validator counts anonymous access as a valid scheme, so nothing complains. Start the container with no AUTHENTICATION_ variables and it accepts unauthenticated reads and writes. Role-based access control stays off until you set AUTHORIZATION_RBAC_ENABLED yourself.

Qdrant's shipped config/config.yaml in 1.19.0 binds 0.0.0.0 on port 6333, leaves both api_key and read_only_api_key commented out, leaves jwt_rbac commented out and sets enable_tls: false. Milvus 3.0.0 still ships authorizationEnabled: false with a default root password of Milvus, tlsMode: 0 and internal TLS off. One line there deserves its own attention: enablePublicPrivilege is true, so even after you flip authorization on, the built-in public role starts with privileges attached. Turning authentication on is step one of two.

That table is the finding everyone already expects, which is exactly why it is not the interesting part. Move on to the four things that decide whether the store is actually safe.

This is the failure mode that survives a code review, because the config file reads correctly.

Qdrant treats an empty API key as unset. In 1.19.0's settings validation, an empty key string is treated as no key at all. So QDRANT__SERVICE__API_KEY pointing at an unset shell variable, or a Kubernetes secret that resolved to an empty value, leaves the instance open while your compose file and your Helm values both say otherwise. The engine logs a warning for api_key, alt_api_key and read_only_api_key when this happens, which means the real check is a grep of the startup log, not a reading of your configuration.

**Qdrant disables RBAC entirely when jwt_rbac is on but no api_key is set.** The API key doubles as the HMAC-SHA256 signing secret for JWTs. Set jwt_rbac: true without a key and the server logs that JWT RBAC is configured but no API key is set, therefore JWT RBAC is not enabled, and then serves traffic anyway. The code also recommends a minimum of 256 bits (32 bytes), because a short api_key is a short HMAC secret.

Milvus lets you build an RBAC model that nothing consults. common.security.authorizationEnabled is the switch that decides whether users and roles are checked at all. Leave it false and you have credentials, a role graph, an audit story for the questionnaire, and no enforcement.

The correction is the same in all three cases: never verify a control by reading the config that sets it. Verify it with a request.

# Run this from a different host, not the Docker host.
# 401 or 403 means the credential is enforced. 200 means it is not.
curl -s -o /dev/null -w 'qdrant %{http_code}\n'  http://vecdb.internal:6333/collections
curl -s -o /dev/null -w 'weaviate %{http_code}\n' http://vecdb.internal:8080/v1/schema
curl -s -o /dev/null -w 'chroma %{http_code}\n'   http://vecdb.internal:8000/api/v2/heartbeat

# And grep the startup log for the silent-disable warnings.
docker logs qdrant 2>&1 | grep -iE 'api key|jwt rbac'

Most self-hosted vector store exposure does not come from the engine. It comes from the deployment, and Docker documents the mechanism plainly: when you publish a container's ports, traffic to and from that container is routed in the nat table and gets diverted before it reaches the INPUT and OUTPUT chains that ufw uses. The host firewall you configured is not in the path. A team that added a deny rule on 6333 and moved on has a Qdrant instance on the public internet and a firewall config that says the opposite.

Three specific traps follow from that.

Milvus publishes four ports and people audit two. The standalone compose exposes 19530 and 9091 for the engine, plus the object store on 9000 and 9001 with MINIO_ACCESS_KEY: minioadmin and the engine defaults minio.accessKeyID: minioadmin, minio.secretAccessKey: minioadmin, minio.useSSL: false. The segments and binlogs, meaning your actual vectors, live in that bucket. An attacker who never touches 19530 can copy the corpus out of the object store.

Qdrant's cluster port is a separate trust boundary. The internal peer-to-peer gRPC API on 6335 does not verify the API key unless enforce_internal_auth is enabled, which ships commented out. A cluster with a key on 6333 can still be joined or queried on 6335.

Chroma binds two different ways depending on how you started it. The CLI run command defaults its host to localhost. The frontend server config default, which is what the container image uses, is 0.0.0.0 on port 8000. The developer who tested locally and the operator who deployed the image are both correctly reporting what they saw, which is exactly why the check has to be a port scan from outside the host rather than a reading of the docs.

# The only exposure check that counts, run from another machine.
nmap -Pn -p 6333,6335,8080,8000,9000,9001,9091,19530,50051 vecdb.internal

The clean answer for regulated deployments is to stop publishing host ports entirely: put the store on an internal container network or a private subnet, reach it only from the retrieval service, and terminate TLS and authentication at a proxy you control. That is a large part of why the cost and control comparison of cloud versus on-premise AI usually lands on the on-prem side once the data is regulated.

Only one of these engines lets the credential itself carry the tenant predicate. Qdrant's JWT tokens can embed a payload filter that the engine applies to every request made with that token, so a leaked token is scoped rather than total. Weaviate has role-based access control but it is off until you enable it. Milvus starts the public role with privileges attached. Chroma has no per-collection authorization at all.

Everywhere except a properly configured Qdrant, the tenant filter is a query parameter your application chooses to send, and one code path that forgets it is a cross-tenant read that no database setting will catch. So the tenant predicate belongs above the query API: a retrieval service that derives the tenant from the verified session and refuses to build a query without it, plus a CI test that authenticates as tenant A and asserts zero results from tenant B.

The topology question underneath this (collection per tenant, shared collection with a filter, or a hybrid) has real recall consequences and we worked through it in multi-tenant RAG isolation. This section is only about who enforces it.

A snapshot is the whole corpus, exportable, usually governed by controls nobody reviewed.

Two consequences follow. Snapshot artifacts inherit the classification of the source corpus, so they need the same encryption at rest, retention clock and access logging. And an erasure request that only deletes from the live index leaves those vectors in every snapshot taken before it, which is a separate problem from what DELETE physically does inside an HNSW graph, covered in vector database GDPR erasure and HNSW soft deletes.

CVE-2026-26190 is the cleanest illustration of the network point. Before 2.5.27 and 2.6.10 the entire /api/v1/ REST surface was registered on the Milvus metrics and management port 9091 with no authentication at all, and the debug expression endpoint used a token derived from the etcd root path, which defaults to the string by-dev. Port 9091 is still published by the standalone compose file, so the fix protects you only if you are actually on a fixed line.

CVE-2025-64513 should end any argument about internal trust. An unauthenticated caller forged one header, sourceID, and the Proxy treated the request as an internal component: full administrative access to every collection.

CVE-2026-25628 is why a read-only key is not a containment boundary. From 1.9.3 until the 1.16.0 fix, a caller holding only that key could point the /logger endpoint at an arbitrary path on disk and append to it. Its privileges-required rating is low rather than none, which is exactly the level most teams hand to their retrieval service.

And the Chroma dates are the story. Version 1.5.9 landed on 5 May 2026, the advisory on 18 May 2026, and there has been no release since. An unpatched critical plus three months of silence is a supportability question, not a patching backlog item, and it belongs in the vendor risk file.

One hedged note while you are auditing Chroma: on some 1.0.x builds the native auth environment variables were accepted without taking effect, so verify enforcement with an unauthenticated request rather than trusting that the variables were read.

The argument that turns everything above from an engineering preference into a control requirement is this: a vector store is a second copy of your source documents, not a derived index.

Published inversion work recovers 92 percent of 32-token text inputs exactly from their embeddings using a multi-step iterative method, and the same paper demonstrates extracting full patient names from a clinical notes dataset (Text Embeddings Reveal (Almost) As Much As Text). If your corpus is patient notes, deal documents, case files or HR records, the embedding collection carries the handling obligations of the source under GDPR and HIPAA: lawful basis, retention, erasure, access logging, breach notification.

That reframing changes three decisions at once. The store belongs inside the same data boundary as the source system, which for most regulated buyers means on-premise or a private subnet with no published host ports. Snapshots are regulated artifacts, not operational scratch. And an unauthenticated read of a collection is a disclosure of the underlying records, not a leak of "just vectors". If you are still choosing an engine, the Pinecone, Weaviate and Qdrant comparison covers the cost and performance side.

Twelve checks. Each one is verified by an observation, not by a configuration file.

The pattern across all twelve is that the software default is the least interesting risk, because it takes an hour to fix. The deployment boundary, the silently-disabled credential, the second copy in the object store and the version floor are the ones that survive a security review and show up in an incident. For the broader control set, start at our AI security pillar.