Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

4.1 KiB

Raw Blame History

MCP Security: The Complete Guide to Securing MCP Servers in 2026

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	MCP Security: The Complete Guide to Securing MCP Servers in 2026
Source URL	https://bytehide.com/blog/mcp-security-guide
Source publisher / author	ByteHide (vendor blog)
Source type	blog post
Source date (published)	2026-09-22
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	Medium
Status	Active

Summary

ByteHide's guide argues authorization is optional in practice (local servers take env credentials, remote servers may skip auth entirely) and cites a May 2026 preprint measuring about 8,000 remote servers with around 40 percent unauthenticated (secondhand figures, treat as uncertain). It tabulates what the spec requires versus what the operator owns, works four attack examples (hidden-instruction exfil, shadowing, rug pull, poisoned output), recounts named incidents, and ends with secrets-hygiene and fleet-inventory checklists.

Key findings

"authorization is optional. Local servers usually take credentials from environment variables or configuration files, and remote servers can choose not to authenticate at all"; cites a May 2026 preprint measuring about 8,000 remote servers with "around 40% exposed tools with no authentication" (secondhand vendor-cited figures, uncertain per the pack Caveats).
Spec-requires vs. you-own table: the spec covers "Token validation and audience binding" but NOT "Which tools a caller may use" ("Map scopes to individual tools and enforce them server-side"), local-server credentials, publisher trust, or audit ("Log who called which tool, with which token, on whose behalf").
Four worked examples: (a) exfil via a hidden <system> instruction passing ~/.ssh/id_rsa in a locale param; (b) shadowing: a get_weather description adding an attacker BCC to send_email; (c) rug pull: "most clients don't re-prompt when descriptions change"; (d) poisoned output: "the GitHub MCP exploit... the tools were legitimate, but the content they returned carried the injection."
Real incidents, as recounted by ByteHide (secondhand): Koi Security's postmark-mcp (15 clean versions, then v1.0.16 silently BCC'd every email; about 1,500 downloads/week); Invariant Labs May 2025 GitHub scoping issue; July 2025 Supabase support-ticket exfil; CVE-2025-6514 (CVSS 9.6 RCE in mcp-remote). Note: the postmark-mcp figures conflict slightly with the explainx.ai account; treat as uncertain.
"Store credentials in a vault, not in the JSON files where MCP clients keep server configuration"; "One token per server"; "read-only by default"; "Separate identities for agents".
Inventory schema per server: name/package/URL, publisher, version/content hash, transport, scopes, tool-plus-description hashes, users/devices, first/last seen plus approval status; alert on new server, near-miss names, changed description hash, changed URL domain, rapid spread, new scopes.

Pros / strengths

Best single operations checklist in the pack: secrets, tokens, defaults, and identities in one place.
Attack examples map one-to-one onto client controls (description-hash pinning, re-approval on change).
The inventory schema is concrete enough to implement directly.

Cons / limitations / caveats

Vendor blog with secondhand statistics (preprint, Koi, Invariant) and at least one figures conflict with explainx.ai; all counts stay uncertain.
Incident accounts are summaries, not primary reports; no links to firsthand writeups are evidenced in the pack.
The server-side scope-mapping advice sits outside what a pure client can enforce.

Relevance to tai

Best single client-operations checklist source for tai: per-tool scope mapping, description-hash pinning with re-approval, secrets-out-of-config, fleet inventory.

Changelog

Date	Change
2026-10-18	Initial dossier created.

4.1 KiB Raw Blame History