2. Vector Databases

Section verified: April 30, 2026

The storage layer for RAG, embeddings, and long-term LLM memory. Many of these ship without authentication enabled by default, exposed instances often disclose collection names, schema, embedding model, and the LLM provider keys used to generate vectors.

ChromaDB

Fingerprint note: Shodan does not index arbitrary HTTP endpoint paths (/api/v1/heartbeat, /api/v1/collections, /openapi.json) in the root banner, it crawls / and headers only. Path-based fingerprints only work when the path string appears inside HTML response bodies (see http.html:"/api/v1/heartbeat" above). This is a general lesson applicable across the catalogue.

Status-code caveat: Chroma returns 404 at / regardless of auth configuration (no root handler registered), so http.status:200 and http.status:401 both return 0 for product:"Chroma". Auth-enabled vs unauth cannot be distinguished from Shodan banner data alone, probe /api/v1/heartbeat live to tell them apart.

{"nanosecond heartbeat": 1713384722842816000}

What a T1 Chroma heartbeat response looks like. No auth, full API reachable.

Qdrant

Fingerprint field lesson (generalizable): "qdrant" bare returns 189 hits but "qdrant" port:6333 returns 0, not a bug. Bare "<term>" matches Shodan’s banner text (headers + initial response). On port 6333, Qdrant’s REST root returns JSON without the literal word “qdrant” in headers, so banner match misses. The http.html: field parses response bodies and does catch it. Always try both "<term>" and http.html:"<term>".

Path indexing: Qdrant’s /telemetry, /snapshots, and /points/search endpoints don’t surface in Shodan at all, even the terms “telemetry”, “points”, “snapshots” paired with “qdrant” return 0 on every combination tested. These endpoints require live probing, not Shodan queries.

Deployment shift: 922 of 949 Qdrant instances are no longer on port 6333 (80+443+proxies = ~90% of exposure). Same pattern as n8n and Flowise.

Weaviate

Deployment anomaly: Weaviate is the only vector DB verified so far that did not mass-migrate off its default port. 899 of 1,647 instances (~55%) remain directly exposed on 8080, vs Qdrant (3% on 6333) and Flowise (~0% on 3000). Likely explanation: Weaviate is more often run behind application backends rather than user-facing reverse proxies, the embedding service sits between an app and the data, not between a user and a UI. The practical impact: direct 8080 hits are higher-confidence “this is a real Weaviate API, no auth layer in front” signals.

Path indexing: All 5 original /v1/schema, /v1/objects, /v1/meta, /v1/nodes, /v1/backups queries returned 0. Shodan doesn’t crawl these paths. Live-probing the /v1/meta endpoint on confirmed Weaviate hosts is required to enumerate version + module config.

Module fingerprint gap: "text2vec-openai" and "generative-openai" both return 0 alone and paired, module config is server-side metadata, not reflected in root banner or HTML. To detect OpenAI-key-backed Weaviate deployments, probe /v1/meta live on the 899 port:8080 hits.

Auth reality check: Weaviate ships with anonymous access enabled unless AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=false is explicitly set. With 899 direct-exposure hits, assume most are unauthenticated absent contrary evidence.

Milvus

gRPC blind spot (important): Milvus’s primary API runs on port 19530 over gRPC (HTTP/2 + protobuf binary framing). Shodan’s banner grab cannot read the “milvus” string from a gRPC banner, it’s not HTTP text. port:19530 returns 522 baseline hits that likely include Milvus, but "milvus" port:19530 returns 0. These 522 hits cannot be confirmed as Milvus from Shodan alone; live probing via a gRPC reflection request or a milvus.proto.milvus.MilvusService/DescribeCollection RPC is required.

Path indexing: Original queries using /api/v1/health and /metrics on port 9091 all returned 0 (same Shodan crawl-path limitation documented in Chroma and Qdrant sections).

Component visibility ranking: In this catalogue’s data, the Attu admin UI is more exposed than the Milvus core itself (2,071 Attu banner hits vs ~1,500 Milvus HTML hits). Attu is a React SPA with full read/write access to any Milvus it connects to, typically via a connection dropdown with no auth checks in the UI layer. A reachable Attu is a reachable database.

Side-service exposure: When Milvus is deployed with its full stack, the etcd metadata store (port 2379) and MinIO object backend (port 9000) often ride alongside, etcd exposes the entire schema and collection topology; MinIO holds the raw vector files. Check "milvus" "etcd" and "milvus" "MinIO" results for colocated trifectas.

Object Storage & Artifact Stores

Vector databases are the search layer. Object storage is where the models, embeddings, raw documents, training datasets, and DB snapshots actually live on disk. Milvus, Weaviate, and most RAG pipelines back onto MinIO or S3 by default. A compromised bucket is typically a higher-impact finding than the index in front of it.

MinIO

MinIO reality check: The previously-listed "MinIO" port:9000 -"auth" is not a useful auth filter, -"auth" matches ~identical counts (43,778 vs 43,775) because “auth” is not a banner token for MinIO either way. Query dropped. Distinguishing authenticated vs open buckets requires live probing /probe-bucket-sign/ or attempting anonymous ListBuckets.

Docker Registry

Harbor

Triage note: Anonymous /v2/_catalog read ≠ anonymous push. But anonymous pull of internal images leaks entire codebases, build-time secrets in layer history, and the full supply chain of whatever ships from that registry. Rate severity on read vs. push separately before escalating. See §12 for Docker daemon and container runtime exposure (distinct from the artifact store).

Scale callout: MinIO (~50k console hits + ~44k data hits) and Docker Registry (~15k) together form the single largest AI-adjacent attack surface in this catalogue, bigger than any model-serving, vector-DB, or orchestration platform measured. When a Milvus or Weaviate colocates with an exposed MinIO, the storage layer is almost always the faster path to training data, DB snapshots, and raw vectors. Prioritize accordingly.

Elasticsearch / OpenSearch

Elasticsearch

Kibana

OpenSearch

AI-extension blind spot (important): The vector-search features that make Elasticsearch/OpenSearch relevant to AI (dense_vector field, knn plugin, embeddings, number_of_shards, index mappings) are invisible to Shodan. Every query containing "dense_vector", "knn", "embeddings", or "number_of_shards" returns 0, even alone, even in html fields. These tokens live in per-index API responses (/_mapping, /_cat/indices), which Shodan does not crawl. You cannot distinguish “ES running a RAG vector store” from “ES storing web logs” via Shodan alone, requires live probing.

Auth-state blind spot: "elasticsearch" -"security_exception" matches the same 77k as unfiltered (literally 77,772 vs 77,771). X-Pack auth errors don’t appear in Shodan banners either. Distinguishing open clusters from auth-gated ones requires live / or /_cluster/health probes with no auth header.

Browser plugin pollution tested, not a concern: http.html:"opensearch" -"opensearchdescription" = 22,845 hits (removes 1 from 22,846). The W3C OpenSearch browser plugin spec is not meaningfully contaminating OpenSearch DB counts.

Scale note: With product:"Elastic" at 92,587, Elasticsearch is the single most-exposed platform in this entire catalogue, larger than MinIO Console (49,984) and n8n (77,102). Most of these run for observability/logs, not vectors, but a non-trivial fraction of the 3,728 v8.x instances serve RAG workloads whose vector indexes cannot be separated from log indexes without live probing.

PostgreSQL + pgvector

PostgreSQL base platform

pgvector

Supabase

pgAdmin

Timescale

Neon

Scale reality: PostgreSQL at 603k+ is the largest base-platform count in this catalogue, but the vast majority are not AI-adjacent. The pgvector subset is 125 banner-match hits, three orders of magnitude smaller. Supabase is the signal-to-noise winner here: 45,784 Supabase HTML hits vs 125 raw pgvector hits, and Supabase ships pgvector by default. A reachable Supabase backend with open anon keys is a pgvector-backed RAG store with higher probability than probing a random "PostgreSQL" host.

Auth-state blind spot: PostgreSQL uses a binary protocol on 5432; Shodan captures the startup error/version banner but not auth posture. psql -h <ip> -U postgres or explicit SELECT over a captured connection string is the only way to confirm anonymous vs authenticated access. The 603,878 banner hits are a visibility count, not a vulnerability count.

Original query failures: All 5 originals combined narrow port (5432) + path-style strings ("pgvector", "vector") that don’t coexist in the PG startup banner. "PostgreSQL" port:5432 "pgvector" = 0 because the startup error doesn’t contain extension names. Use the replacements above.

Redis Vector Search

MongoDB

ClickHouse

Other Vector DBs

No product facet on Shodan (verified 0) for: SurrealDB, ArangoDB, Marqo, LanceDB, Typesense, Vespa, Zilliz, Cassandra, txtai. Use banner/HTML variants.

Graph Databases / Memory

Ratel noise warning: "ratel" bare returns 156,554 hits due to unrelated projects/products sharing the name. http.title:"Ratel" (73) is the clean version for Dgraph’s UI specifically.

Auth-state takeaways from this section:

• Redis -"AUTH" -"NOAUTH" filter is meaningful (245k → 68k)
• MongoDB -"auth" filter is meaningful (107k → 90k)
• Contrast with ES -"security_exception" and MinIO -"auth" which are both no-ops
• Rule: always verify negative-filter behavior against the unfiltered count before relying on it as T1

MongoDB "vector" anomaly ⚠️: The "MongoDB" port:27017 "vector" query returns 59,996 hits, suspiciously large given MongoDB Atlas Vector Search is a 2023+ feature that runs on Atlas cloud (not typically self-hosted on open 27017). Likely contaminated by the word “vector” appearing in unrelated MongoDB banner/log content. Sample before trusting this as a RAG-backend fingerprint.