genai
SECURITY LAB
IncidentsSupply chain

RCE in Anthropic's MCP Inspector via a Malicious Web Page

Critical severityVendor vulnerabilityJune 2025LLM04: Supply Chain
Status: CVE-2025-49596 (CVSS v4.0 9.4); credited to Tenable (Rémy Marot), independently reported by Oligo Security (Avi Lumelsky); fixed in MCP Inspector 0.14.1
Sources checked October 2026
On this page

The tool AI developers use to test MCP servers would run commands for any website they happened to visit.

WhenJune 2025
TargetAnthropic MCP Inspector
ResearcherTenable (Rémy Marot, credited); Oligo Security (Avi Lumelsky), independently
TechniqueUnauthenticated proxy + 0.0.0.0-day + CSRF → RCE
CVECVE-2025-49596 — CVSS v4.0 9.4 (Critical)
Attack flow
  1. 1A developer runs MCP Inspector locally; its proxy has no authentication
  2. 2They visit a malicious web page, which (via 0.0.0.0-day + CSRF) reaches the local proxy
  3. 3The proxy spawns a process — code execution on the developer's machine
Try this attack in a live lab Open the lab

What happened

In 2025, Tenable (credited in the advisory) and Oligo Security independently reported CVE-2025-49596 in Anthropic's MCP Inspector — the standard tool for building and testing Model Context Protocol servers. Its proxy defaulted to no authentication and could spawn local processes; chained with the browser '0.0.0.0-day' and a CSRF request, a developer who merely visited a malicious website could have commands executed on their machine. Fixed in 0.14.1.

How the attack worked

The Inspector exposed an unauthenticated local proxy able to start processes. Browsers can be tricked into reaching services on 0.0.0.0, so a malicious page could issue a cross-site request that told the local proxy to run a command — no credentials, no user action beyond opening a tab.

Root cause

A developer tool exposed a powerful, process-spawning capability over an unauthenticated local endpoint reachable from the browser — a conventional web-security failure in core AI tooling.

Why it matters

It targets the machines of the people building AI agents. The mechanism is old-fashioned no-auth/CSRF RCE, but the blast radius is the AI supply chain's developers.

How to prevent it

  • Update to 0.14.1+ (authentication and origin checks added).
  • Never run dev tools with open, unauthenticated local proxies.
  • Bind local services to loopback and require auth for anything that can execute.

FAQ

What made this exploitable from a web page?

The Inspector's proxy ran without authentication and could spawn local processes. Combined with the '0.0.0.0-day' browser quirk and a CSRF request, a malicious site could reach the local Inspector and make it run commands — no credentials needed.

Is this really an 'AI' vulnerability?

The root cause is a classic no-auth/CSRF web RCE — but it sits in core MCP developer tooling, so it exposes the machines of the people building AI agents. It's an AI-supply-chain risk more than an LLM-native one.

How do you defend?

Update to 0.14.1+ (which adds authentication and origin checks), and never run agent/MCP dev tools with open, unauthenticated local proxies.

Replay this attack
Submit a job to an AI tool's API that runs commands for anyone who can reach it — the missing-authentication flaw behind the Inspector's proxy, without the browser hop.
Open the live lab
A live, sandboxed lab. It recreates the technique, not this exact product.