Breachwire.riscent

Breach report

MCP Inspector: a no-auth developer tool that let any website run code on your machine

AI & LLM BreachesCritical (CVSS 9.4)CVE-2025-495962025-07
The bottom lineAnthropic's MCP Inspector ran a local proxy with no authentication, so a malicious website could reach it through the browser and execute arbitrary commands on the developer's machine.
Category
AI & LLM Breaches
Type
CVE · Named incident (Anthropic MCP Inspector)
Date
2025-07
Severity
Critical (CVSS 9.4)
OWASP
LLM03 Supply Chain
CWE / CVE
CWE-78 CVE-2025-49596

What happened

MCP Inspector is Anthropic's developer tool for testing and debugging Model Context Protocol servers. Oligo Security disclosed a critical vulnerability, tracked as CVE-2025-49596, in which the tool's local proxy accepted commands with no authentication.

The Inspector proxy exposed an endpoint that could launch processes over the stdio transport, and it did so without any authorization check. Oligo showed that a malicious public website could reach that endpoint through the victim's browser by targeting the local service via the 0.0.0.0 address — the unpatched "0.0.0.0-day" browser behavior — combined with cross-site request forgery and DNS rebinding techniques. A crafted request such as http://0.0.0.0:6277/sse?transportType=stdio&command=touch&args=... would run an arbitrary command on the developer's machine. The report assigned a CVSS score of 9.4. The initial report was made in April 2025 and the CVE published in June 2025; the fix landed in version 0.14.1, which added session-token authentication and origin verification, making authorization mandatory by default.

Root cause

  • LLM03 Supply Chain. A widely used piece of AI developer tooling shipped with an insecure default — an unauthenticated local proxy able to spawn processes — so every developer running it exposed their machine to any web page they visited.

The core defect is a missing authentication and origin boundary on a locally bound service, letting browser-reachable requests cross from an untrusted web origin into command execution.

How it would have been caught

A security review of the tool's default configuration — checking whether the local proxy required authentication and validated request origins — would have flagged it before release. A dynamic test that issues a cross-origin request from a browser context to the Inspector's stdio endpoint and confirms a command runs is the direct reproduction; DNS-rebinding and CSRF test harnesses automate it.

How to prevent it

  • Require authentication (session tokens) on any locally bound developer service that can execute commands.
  • Validate the Origin header and reject requests from unexpected web origins to defeat CSRF and DNS rebinding.
  • Bind development tools to 127.0.0.1 with authorization on by default, never expose command execution without an explicit, authenticated handshake.

The Breachwire test (red → green)

From a browser context, issue a cross-origin request to the Inspector's stdio endpoint and confirm a command executes on the host (the RED control proving browser-to-RCE). Apply session-token auth and origin validation, then confirm the same cross-origin request is rejected, while an authenticated, same-origin Inspector session still launches MCP servers normally (the positive control).