@guardbee/mcp-vector-store-scanner
🇬🇧 English | 🇹🇷 Türkçe | 🇨🇳 中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇧🇷 Português | 🇪🇸 Español | 🇩🇪 Deutsch
[npm version]
[npm downloads]
[License: MIT]
An MCP (Model Context Protocol) server that probes a vector-database (or vector-index-capable) endpoint for unauthenticated exposure — the same class of misconfiguration behind repeated real-world incidents of open Elasticsearch/MongoDB/Redis instances leaking data, now aimed at the RAG-era stack: Weaviate, Qdrant, Chroma, Elasticsearch/OpenSearch, Redis, and Postgres/pgvector.
Every RAG pipeline's embeddings live somewhere. If that vector store is reachable on the network without authentication, anyone who finds it can read (and often write) every document your retrieval pipeline was ever given — including anything sensitive that made it into a chunk.
Telemetry is off by default. With GUARDBEE_TELEMETRY=1 it sends the server, tool, success, duration and short parameter values such as a file path; longer strings and fields like content, token or password are replaced with a placeholder. See @guardbee/mcp-telemetry.
How it escalates
Each HTTP-based probe doesn't stop at "is this thing up" — it walks the same path an attacker would, in increasing order of impact, and only reports what actually succeeded:
- Instance info (medium) — version/build details readable without auth. Low impact alone, but confirms the service is exposed and helps fingerprint known CVEs.
- Schema / collection listing (high) — class or collection names readable without auth. Reveals your data model even before any real data is read.
- Actual stored data (critical) — a real object/point/document comes back without auth. This is the finding that matters: your embeddings (and whatever they were built from) are readable by anyone who can reach this port.
Redis and Postgres get the same treatment via their native wire protocols instead of HTTP — a PING (Redis) or a StartupMessage (Postgres) is enough to learn whether authentication is enforced, without ever sending a real password. No credential is ever guessed, brute-forced, or sent — every check here is read-only fingerprinting, the same category of probing dns-intelligence and ssl-inspector already do elsewhere in this monorepo.
Features
- 6 target types: Weaviate, Qdrant, Chroma, Elasticsearch/OpenSearch (HTTP), Redis (raw RESP), Postgres/pgvector (raw wire protocol)
- Auto-detection — fingerprints the endpoint by trying each known type in turn when
type isn't specified
- From-scratch protocol implementations for Redis and Postgres — no client library dependency, no real credentials ever sent, includes a TLS-upgrade path for Postgres's
SSLRequest handshake
- Escalating checks (info → schema → data) so a "critical" finding always means real data was actually read, not just that a port responded
- SARIF 2.1.0 output — CI/CD integration (GitHub Code Scanning, etc.)
- Config file support via
guardbee.yml
- 22 unit tests against local mock HTTP/TCP servers, covering every probe's matched/unmatched fingerprint and each escalation level
Quick Start
Claude Desktop / MCP Client
CLI (CI/CD)
MCP Tools
What it catches
Configuration (guardbee.yml)
Limitations (by design)
- Chroma's actual-document read isn't checked — its data-read API varies significantly across versions, so this scanner stops at the collection-listing level for it (still enough to detect the primary "no auth at all" misconfiguration).
- Milvus isn't supported — its primary API is gRPC, which doesn't fingerprint via a lightweight probe the way the others do.
- This checks for unauthenticated read access, not authorization bugs behind a working auth layer (e.g. a valid-but-overprivileged API key) — that's out of scope for an external, credential-less probe.
Development
License
MIT — GuardBee
Feedback
Questions, ideas, or a false positive? Start a thread in GitHub Discussions or open an issue. If GuardBee is useful to you, a ⭐ on the repository helps others find it.
