DEV Community

Custodia-Admin
Custodia-Admin

Posted on • Originally published at pagebolt.dev

CVE-2025-54136 MCPoison: Why Hosted MCP Servers Have a Smaller Attack Surface

#security #cve #mcp #mcpoison

CVE-2025-54136 MCPoison: Why Hosted MCP Servers Have a Smaller Attack Surface

This week, security researchers disclosed CVE-2025-54136 MCPoison — a vulnerability in self-hosted MCP (Model Context Protocol) servers that allows attackers to inject malicious tools.

The attack is simple:

  1. An attacker creates a fake MCP tool named screenshot
  2. They place it in the local MCP tools directory
  3. The Cursor agent (or other LLM client) loads the fake tool without verification
  4. The fake tool steals data, credentials, or executes arbitrary code

The root cause: self-hosted MCP servers trust local tool names without cryptographic verification.

How MCPoison Works

A typical self-hosted MCP setup:

Cursor IDE
    ↓
Local MCP Server (runs on your machine)
    ↓
Loads tools from: ~/.mcp/tools/
    ↓
Agent calls: take_screenshot()
    ↓
Which screenshot tool runs? The real one? Or the fake one in the same directory?
Enter fullscreen mode Exit fullscreen mode

The MCP server has no way to verify which tool is authentic. It loads tools by name from the local filesystem. An attacker who can write to that directory can inject a fake tool with the same name.

CVE-2025-54136 proves this isn't theoretical. The vulnerability was demonstrated in the wild.

Why Self-Hosted MCP Is Vulnerable

Self-hosted MCP servers (Playwright-based, Puppeteer-based, custom tools) inherit all the trust assumptions of your machine:

  • No cryptographic verification — tools are loaded by filename, not by signature
  • Local file system access — any code that can write to the tools directory can inject fake tools
  • No sandboxing — fake tools run with the same permissions as legitimate ones
  • Supply chain risk — every tool you install becomes part of your attack surface

An attacker who compromises even one tool in your ecosystem can:

  • Intercept screenshots (steal sensitive data from pages you're automating)
  • Log API calls (capture credentials, API keys)
  • Modify automation results (inject false data into your workflows)
  • Execute arbitrary code (full system compromise)

The Hosted API Difference

Hosted MCP APIs (like PageBolt) have a fundamentally different trust model:

Self-hosted MCP:

Cursor IDE → Local Tool (untrusted, no verification) → Possible data theft
Enter fullscreen mode Exit fullscreen mode

Hosted API:

Cursor IDE → API Call (signed, encrypted, validated) → PageBolt Infrastructure → Result
Enter fullscreen mode Exit fullscreen mode

When you call PageBolt's screenshot API:

  1. No local tool loading — there's no tools directory to poison
  2. Cryptographic verification — API calls are signed and encrypted end-to-end
  3. Zero local execution — tools run in isolated cloud infrastructure, not on your machine
  4. No file system access — the API can't access your files, credentials, or clipboard
  5. Immutable audit logs — every API call is logged and verifiable

Even if an attacker compromises the network between your client and PageBolt, they can't:

  • Inject fake tools
  • Access your file system
  • Steal credentials stored locally
  • Modify your automation results (signatures prevent tampering)

Real-World Impact

Scenario: You're using a Cursor agent with self-hosted Playwright MCP

Your security posture:

  • Playwright MCP runs on your machine ✓
  • You trust Playwright's developers ✓
  • But do you trust every dependency Playwright has? Every npm package? Every plugin?
  • One compromised dependency = entire tool poisoned ✓

Scenario: You're using PageBolt API with Cursor

Your security posture:

  • API runs in isolated cloud infrastructure ✓
  • No local tools to poison ✓
  • PageBolt controls the execution environment ✓
  • Your file system is unreachable ✓
  • Credentials are never exposed ✓

The attack surface is orders of magnitude smaller.

What You Should Do Now

If you're using self-hosted MCP tools (especially for sensitive automation):

  1. Audit your tools — do you know what code is running? Have you verified it?
  2. Minimize attack surface — use only tools you absolutely need
  3. Keep tools updated — apply security patches immediately
  4. Monitor tool behavior — log all tool executions, flag anomalies
  5. Consider hosted alternatives — for critical operations, use APIs instead of local tools

If you're building production automation:

  1. Use hosted APIs — zero local execution, smaller attack surface
  2. Verify signatures — if using self-hosted tools, cryptographically verify them
  3. Sandbox isolated — run self-hosted tools in containers with restricted permissions
  4. Audit regularly — treat tools as security-critical infrastructure

The Bigger Picture

CVE-2025-54136 is one vulnerability. But it exposes a deeper architectural problem:

Self-hosted tools inherit the security of your entire machine.

As MCP becomes standard for AI agent tooling, this becomes critical. A Cursor agent that can run arbitrary local code via compromised tools is a compromise vector for your entire system.

Hosted APIs shift this risk. The API provider manages the attack surface. You get the functionality (screenshots, PDFs, web automation) without the supply chain risk.

Try It Now

If you're concerned about MCPoison in your MCP ecosystem:

  1. Get API key at pagebolt.dev (free: 100 requests/month, no credit card)
  2. Replace self-hosted screenshot/PDF tools with PageBolt API calls
  3. Reduce your attack surface from "all local tools" to "read-only API calls"
  4. Get immutable audit logs of every API call

Your Cursor agents will be more secure. Your automation will be more reliable.

And you won't be exposed to the next CVE-2025-54136 variant.

Top comments (0)