The unlocked memory of AI apps: exposed vector databases with no authentication

What happened

Vector databases — Chroma, Weaviate, Pinecone, Milvus, Qdrant and others — store the embeddings that power Retrieval-Augmented Generation (RAG). Security researchers describe a recurring misconfiguration class: instances deployed with open network ports and no authentication, discoverable through port scanning, service fingerprinting, and connection strings leaked in public repositories. This entry describes the vulnerability class as documented; it does not assert a specific count of exposed instances. With unauthenticated access, an attacker can query the store, read the proprietary embeddings, and treat the AI system's knowledge layer as a direct attack surface.

Root cause

Many vector stores ship with authentication off by default (CWE-306) to make local development easy, and teams carry that default into internet-facing deployments. The RAG app works — it retrieves context and answers questions — while the invariant "only the application may read or write the knowledge base" is never enforced. Three concrete harms follow: embedding exfiltration and model inversion, where an attacker extracts vectors and partially reconstructs the original sensitive documents; vector poisoning, where write access injects malicious embeddings that subvert the model's grounding into returning false or attacker-chosen answers; and prompt-injection orchestration, where knowing exactly what context is retrievable lets an attacker craft precise injections.

How it would have been caught

A test that connects to the vector store's endpoint from off-host with no credentials and asserts the connection is refused flips red on any exposed instance. An asset scan for the store's ports reachable from the public internet catches the exposure. A poisoning check writes a known-bad vector without auth and confirms it is rejected. Each is a direct, unauthenticated reproduction.

How to prevent it

• Require authentication on every vector database and never expose it to the public internet — reach it over a private network from the application only.
• Separate read and write credentials; deny anonymous writes so retrieval cannot be poisoned.
• Treat embeddings as sensitive data: they can be inverted back toward source content. Encrypt at rest and monitor for bulk-export queries.

The Breachwire test (red → green)

From an external host with no credentials, connect to the vector store and confirm you can read embeddings or write a new vector — the RED proof it is open. Enable authentication and restrict it to a private network with read/write separation, then confirm the same unauthenticated connection is refused for both reads and writes, while the application still queries with its scoped credential.