On 20 October 2026, a safe MCP plugin catalog needs a 12-point admission gate: pin code, inspect tool text, restrict privileges, and retest updates. Recent research shows a familiar approval screen cannot by itself stop tool poisoning or filesystem escapes.
At a glance
- Two Filesystem MCP Server flaws received CVSS scores of 7.3 and 8.4, covering a directory-prefix bypass and a symlink route to host-file access.
- A 2025 MCP security study divides the server lifecycle into four phases and 16 activities, which makes one-time installation review inadequate.
- Hermes’s catalog says its reviewed entries are pinned to a specific commit, giving installers a fixed code target rather than a moving branch.
- A Home Assistant dispute on 16 October 2026 showed that a privacy-preserving secret check still needs clear disclosure and a visible off switch.
What changed in MCP plugin security?
MCP, or Model Context Protocol, lets an AI application discover and call external tools. That makes a plugin catalog more than a directory of extensions. It is an admission system for code, credentials, tool descriptions, network access and background processes.
The missing control in many generic checklists is a review of what the model reads before it makes a call. Trail of Bits showed that a server’s tool description reaches the model during tool discovery, creating an instruction-injection route before the user invokes that tool. Its “line jumping” research calls this a failure of both invocation controls and connection isolation.
That changes the catalog question. Do not ask only, “Is this plugin’s code trustworthy?” Ask whether its complete manifest can alter the model’s treatment of every other connected tool. A manifest includes tool names, descriptions, parameter schemas, prompt templates, declared permissions and outbound destinations.
What was promised versus what shipped?
The timeline shows why a catalog review must cover discovery, installation, operation and updates. The pattern is not one isolated bug. It is a chain of findings where the user-facing action looked narrower than the model-facing or host-level effect.
-
Invariant Labs disclosed tool poisoning: instructions embedded in a tool description could steer an agent toward sensitive files and conceal the actual data passed as an argument. The promised action was a harmless tool call; the demonstrated risk was secret exfiltration. -
Trail of Bits documented line jumping, where malicious descriptions could shape model behaviour at connection time. The expected boundary was “no action without invocation”; the attack began before invocation. -
Cymulate’s disclosure timeline records a patch release for two Anthropic Filesystem MCP Server issues reported on 30 March 2025. The expected boundary was an allowed directory; the flaws permitted prefix confusion and symlink-based escape. -
Semgrep’s demonstration notes that its tool-shadowing example worked on Windsurf 1.99.3 at that date. The intended choice was a legitimate tool; the demonstration explored how a rival tool could front-run it. -
Researchers revised a lifecycle study that maps MCP server security across creation, deployment, operation and maintenance. That framing supports recurring catalog controls rather than a single install-time scan. -
A Home Assistant issue raised consent concerns over a secret-exposure check. A maintainer later explained that only the first five characters of a locally calculated SHA-1 hash were sent to Have I Been Pwned, and identified an opt-out command.
What must happen before a one-click install?
Before listing a plugin, the catalog operator should create an immutable review record. It should identify the publisher, repository, exact commit, subdirectory, package lockfile, runtime command, required environment variables and every declared tool. If any item changes, the old approval should not carry forward.
This is a useful model because the Hermes plugin catalog describes installs as a repository plus subdirectory at a reviewed commit. A commit pin does not prove a plugin is safe. It does establish which code and metadata reviewers examined, and prevents a silent branch update from changing the install later.
| Catalog gate | Evidence required before approval | Fail-closed decision | What it blocks |
|---|---|---|---|
| Publisher identity | Named maintainer and repository ownership | Do not list an unverified publisher | Impersonated integrations |
| Immutable release | Commit, tag or package digest recorded in the catalog | Do not install a floating branch | Silent replacement after review |
| Manifest review | Raw tool descriptions, prompts and schemas | Reject hidden or unexplained instructions | Tool poisoning |
| Permission mapping | Files, network hosts, secrets and write actions | Deny broad access by default | Credential and host overreach |
| Collision test | Unique names and predictable tool selection | Reject conflicting tools | Tool shadowing |
| Update review | Human-readable manifest and permission diff | Pause upgrades that expand access | Catalog rug pulls |
The table adds a decision that ordinary dependency scanning misses: a catalog should reject a plugin whose explanation changes the model’s instructions, even if its code contains no known vulnerability. SlowMist’s checklist already calls for code integrity, source verification, isolated execution and background-process controls; catalog operators should make those checks enforceable listing criteria.
How do you inspect tool descriptions?
Render every tool description and every parameter definition exactly as the model receives it. Do not approve from a shortened card, a tool name or a marketing summary. The user needs a review screen that shows the resolved command, complete arguments, requested files and destination host before a sensitive call runs.
Invariant Labs found that users may see a simplified tool interface while the model sees instructions hidden inside the full description. Its example used a benign-looking addition tool to request configuration data and an SSH private key through an extra argument. That is why a catalog must scan textual metadata, not only source code.
- Reject descriptions that order the model to hide activity, bypass consent or treat the tool as mandatory.
- Flag instructions that mention private keys, configuration paths, tokens, passwords or unrelated tools.
- Require each parameter to have a plain-language purpose and a data classification.
- Show the full resolved input at approval time, including values added by the agent.
- Store a hash of the reviewed manifest, then alert on any description or schema change.
This is also where catalog teams should use trust on first use. Record the manifest when it is first approved, then stop the plugin when its tool list, description or schema changes. Trail of Bits specifically recommends alerts for new tools and altered descriptions, rather than assuming a previously trusted connection remains safe.
How do you stop one plugin controlling another?
Do not load unrelated plugins into one undifferentiated model context when they hold different privileges. Give high-risk functions, such as shell access, email, source control and production administration, separate agent sessions or tightly limited tool sets. A malicious description cannot shadow a tool the model never sees.
Semgrep’s repository demonstrates collision behaviour by installing alternate servers that expose the same tool name. The catalog response should be strict: unique tool names, explicit namespaces and a test that confirms a requested tool resolves to the reviewed server. “Best match” is not an acceptable security rule.
Connection isolation also needs a practical meaning. The model itself can act as the relay between servers, even where servers cannot directly communicate. Trail of Bits described this as an indirect bridge, so a catalog should prevent lower-trust plugins from sharing an agent context with plugins that can access valuable secrets or send data externally.
What permissions should an MCP plugin get?
Grant a plugin only the files, commands, network destinations and credentials needed for its single job. Run it as an unprivileged operating-system user, in a sandbox where possible, and give separate credentials to separate plugins. A broad personal token turns a small integration defect into an account-wide incident.
Cymulate showed why path boundaries need adversarial tests. A prefix comparison accepted paths that merely began with an allowed directory name, while a symlink route could defeat containment and enable reads or writes outside the intended scope. A catalog cannot accept “restricted folder” as a claim without testing canonical paths, sibling prefixes and symbolic links.
For filesystem plugins, require a test suite that denies traversal attempts, sibling directories with matching prefixes, symlink targets, non-existent paths and write operations outside the real allowed root. For network plugins, use an outbound proxy or allowlist. For secrets, provide a broker that returns short-lived, scoped credentials rather than exposing a general environment variable.
How should updates and catalog pins work?
Every update should be treated as a fresh permission request when it changes code, tool text, network access, command execution or secret scopes. A pinned commit solves reproducibility, not trust over time. The catalog should show a readable change report before moving an installed plugin to a new pin.
Hermes says catalog updates move users only when a new reviewed pin is available. That is the correct starting mechanism. The missing security layer is an approval boundary around expanded capability: a version that adds a write tool or a new outbound host should remain disabled until an administrator accepts that specific change.
Maintain a revocation path as well. It should disable a plugin by publisher, commit or tool signature across every enrolled client. The academic lifecycle model supports this approach because maintenance is a distinct security phase, not a housekeeping task after deployment.
What should users see before secret data leaves?
Consent needs to describe the data path, not merely display “Allow plugin?” The approval screen should name the source, the exact data category, the receiving service, the purpose, and whether the action writes data or sends it beyond the device. It should also offer a durable off switch.
Home Assistant’s October 2026 discussion is a useful warning. The maintainer described a k-anonymity-style check where secrets stay local, a SHA-1 hash is calculated locally, and only its first five characters go to Have I Been Pwned. Even so, users objected because the feature was not clearly explained, and the project pointed to ha security options --pwned=false as the opt-out.
For MCP plugins, that means catalog pages should disclose telemetry, remote checks and background activity before installation. A technically narrow transmission can still be a trust failure if the user cannot understand it, stop it or audit it. This is especially important where the integration handles private repositories, messages, home devices or credentials.
What belongs in the runtime audit trail?
Log enough to reconstruct authority without storing secret payloads. Record the plugin identity, pinned release, manifest hash, tool selected, user approval, resolved permission scope, destination host, result and error. Redact tokens and sensitive arguments by default, then protect the logs from alteration.
Runtime controls matter because MCP risks appear after a clean installation. The Semgrep security guide emphasises explicit consent and user control, while SlowMist calls for monitoring, anomaly detection, detailed logs and limits on background activity. Use those controls to alert on new tools, unusual outbound destinations, repeated denials, long-running processes and calls outside normal working patterns.
A practical catalog should also publish a test record: which client versions were assessed, whether full descriptions were visible, whether tool-name collisions were rejected, and whether approvals exposed complete arguments. It is not a guarantee. It gives buyers a concrete basis to compare one-click integrations before granting them access.
What we could not verify?
No public standard in the material reviewed here defines a universal, machine-readable MCP catalog manifest that binds code, tool descriptions, permissions and update consent into one signed object. MCP client behaviour also varies, so a catalog cannot assume that every desktop app displays full arguments or isolates connected servers in the same way.
Vendors and MCP client maintainers could settle those questions by publishing conformance tests for manifest display, tool collision handling, context isolation, update diffs and revocation. Until then, organizations should treat a “reviewed” catalog badge as evidence of a process, not proof that a plugin has a safe permission boundary.
Sources
- Cymulate: EscapeRoute and CVE-2025-53109/CVE-2025-53110
- Trail of Bits: Jumping the line
- Invariant Labs: Tool Poisoning Attacks
- Hou, Zhao, Wang and Wang: MCP security threats and lifecycle research
- Nous Research: Hermes Official Plugins
- Home Assistant issue #49314
- Semgrep: A Security Engineer’s Guide to MCP
