Vector Store Scanner

io.github.GuardBeePublished by GitHub account GuardBeev0.3.1Updated Nov 3, 2026

Probes vector-database endpoints for unauthenticated exposure of embeddings/RAG data

VerifiedSTDIODesktop onlyDatabasesSecurity & Monitoring

Overview

AI-generated overview

Probes vector-database endpoints (Weaviate, Qdrant, Chroma, Elasticsearch, Redis, Postgres/pgvector) for unauthenticated exposure of embeddings and RAG data.

What you can do
  • Scan a single host and port for unauthenticated exposure, auto-detecting the store type or taking an explicit one
  • Escalate HTTP probes from instance info to schema and collection listing to reading actual stored objects or documents
  • Check Redis and Postgres/pgvector over their native wire protocols without sending any credentials
  • List the supported store types and the checks run against each
  • Report findings with severity levels and SARIF output for CI/CD use
When to use it
Useful when auditing your own RAG or vector-search infrastructure for open, unauthenticated endpoints, or when adding a credential-less exposure check to a CI/CD pipeline. It is a read-only fingerprinting tool, not a general vulnerability scanner.
Requirements
Runs as a local stdio process, typically launched with npx from the npm package; Node.js is needed. Network reachability to the target host and port is required. No accounts, API keys or headers are declared. Optional telemetry is off by default and enabled with the GUARDBEE_TELEMETRY environment variable; a guardbee.yml config file can set fail-on and timeout.
Before you install
Only scan systems you are authorized to test: the tool actively probes endpoints and reads stored data when access is unauthenticated. It reports data exposure but does not fix it, and it does not cover authorization bugs behind a working auth layer. Enabling telemetry sends server, tool, success, duration and short parameter values such as a file path to a third party.

Installation

In SourceWeft

  1. Open Vector Store Scanner in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

@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.

Claude ──► vector-store-scanner ──► Your vector-store endpoint              │              ├─ weaviate / qdrant / chroma / elasticsearch  (HTTP fingerprint)              │     info ──► schema/collections ──► actual stored data              ├─ redis        (raw RESP: PING, no AUTH sent)              └─ postgres     (raw wire protocol: SSLRequest + StartupMessage, no password sent)

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:

  1. Instance info (medium) — version/build details readable without auth. Low impact alone, but confirms the service is exposed and helps fingerprint known CVEs.
  2. Schema / collection listing (high) — class or collection names readable without auth. Reveals your data model even before any real data is read.
  3. 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

json
{  "mcpServers": {    "guardbee-vector-store-scanner": {      "command": "npx",      "args": ["-y", "@guardbee/mcp-vector-store-scanner"]    }  }}

CLI (CI/CD)

bash
npx @guardbee/mcp-vector-store-scanner scan my-qdrant.internal --type=qdrant --fail-on=high --format=sarif > results.sarif

MCP Tools

ToolDescription
scan_endpointProbes a single host/port for unauthenticated exposure
list_patternsLists the supported store types and what each check looks for

What it catches

StoreCheckSeverity
Weaviate/v1/meta readable without authmedium
Weaviate/v1/schema readable without auth — reveals class nameshigh
Weaviate/v1/objects returns real data without authcritical
Qdrant/ instance info readable without authmedium
Qdrant/collections readable without authhigh
Qdrant/collections/<name>/points/scroll returns real data without authcritical
Chromaheartbeat reachable without authmedium
Chroma/collections readable without authhigh
Elasticsearch/OpenSearchcluster info readable without authmedium
Elasticsearch/OpenSearch/_cat/indices readable without authhigh
Elasticsearch/OpenSearch/<index>/_search returns real documents without authcritical
RedisPING accepted without AUTHcritical
Postgres/pgvectorno TLS offeredmedium
Postgres/pgvectorAuthenticationOk with no password challengecritical

Configuration (guardbee.yml)

yaml
vector-store-scanner:  fail-on: high       # any | critical | high | medium | low | none  timeout-ms: 4000

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

bash
npm run buildnpm test             # 22 unit tests

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.

Source: packages/vector-store-scanner/README.md at commit bc5997d

Tools

2

scan_endpoint

Probe a vector-database (or vector-index-capable) endpoint for unauthenticated exposure — Weaviate, Qdrant, Chroma, Elasticsearch/OpenSearch (HTTP fingerprinting, escalating from instance info → collection/schema listing → actual stored data), Redis (RESP PING without AUTH), and Postgres/pgvector (wire-protocol SSLRequest + StartupMessage handshake, no real credentials sent). Read-only — never writes or authenticates with real credentials.

ParameterstlshostrequiredporttypetimeoutMs

list_patterns

List the vector-store types this scanner can fingerprint, and what unauthenticated-access checks it runs for each

Takes no parameters.

Version history

3
  1. v0.3.1LatestOct 30, 2026
  2. v0.2.2Oct 22, 2026
  3. v0.1.2Oct 13, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts