Overview

Executive Summary

Oligo Security Research reported a Remote Code Execution (RCE) vulnerability and DNS rebinding in the MCP Inspector project to Anthropic, leading to CVE-2025-49596 being issued, with a Critical CVSS Score of 9.4.

This is one of the first critical RCEs in Anthropic’s MCP ecosystem, exposing a new class of browser-based attacks against AI developer tools. With code execution on a developer’s machine, attackers can steal data, install backdoors, and move laterally across networks - highlighting serious risks for AI teams, open-source projects, and enterprise adopters relying on MCP.

When a victim visits a malicious website, the vulnerability allows attackers to run arbitrary code on the visiting host running the official MCP inspector tool that is used by default in many use cases.

Star history of the MCP Inspector

We would like to thank Anthropic for promptly fixing the vulnerability in version 0.14.1 of the MCP Inspector, and for updating the project’s documentation accordingly.

In this article, we dive into the security of the MCP tooling and ecosystem, focusing on one significant attack vector: chaining the known 0.0.0.0-day logical flaw with a new vulnerability in the MCP inspector, to take over a developer’s machine, without being on the same network through the browser.

A few words on MCP

The Model Context Protocol (MCP) is a communication framework designed to connect agents and tools, facilitating real-time collaboration and operation. MCP servers are APIs that enable interaction between real-world systems, running either on cloud infrastructures or locally on developers’ machines, using the MCP protocol. The most common languages for MCP servers are Python and JavaScript, with many open-source implementations hosted on GitHub, pioneered by Anthropic and used by almost everyone in 2025: from Windows to OpenAI.

MCP servers use client libraries provided by Anthropic, and they allow for interactions across a variety of platforms, establishing connections between agents (machines or services) and tools. A complementary protocol known as A2A (Agent to Agent) connects agents to each other, increasing the utility of the system. In this blog, we will focus on MCP which is the backbone that connects AI agents with their tools. Before MCP, a similar concept existed for a while, and it was  tool/function calling (without the server part - directly executed through application code). MCP helps delegate this work to remote servers.

Developers use MCP servers to create secure, efficient communication pipelines that integrate various tools and agents. 

Debugging & Testing MCP Servers: MCP Inspector

There are many open source official MCP servers implementations as well as community maintained MCP servers. Developers are running these servers using Anthropic’s official tooling.

The MCP Inspector is an official tool from Anthropic that consists of two main components that work together:

  • MCP Inspector Client (MCPI): A React-based web UI that provides an interactive interface for testing and debugging MCP servers
  • MCP Proxy (MCPP): A Node.js server that acts as a protocol bridge, connecting the web UI to MCP servers via various transport methods (stdio, SSE, streamable-http)

By following the quickstart guide provided in MCP's official documentation, developers can get their servers up and running, which in turn allows for the execution of commands, file handling, and data flow in a seamless manner. However, the default settings exposed developers to significant security risks.

How Open Source Projects Use the MCP Inspector

Many open-source projects leverage MCP to streamline interactions between agents. One notable use case is in AI development, where tools like the MCP Inspector can monitor and debug interactions within the MCP ecosystem. This tool is vital for developers seeking to trace, debug, and optimize communications between agents and tools, but it can also open the door to security risks if improperly configured.

The quickstart documentation in official Anthropic’s MCP Python SDK encourages developers to run the “mcp dev” command.

The MCP Inspector tool runs by default when the mcp dev command is executed. It acts as an HTTP server that listens for connections, with a default setup that does not include sufficient security measures like authentication or encryption. This misconfiguration creates a significant attack surface, as anyone with access to the local network or public internet can potentially interact with and exploit these servers.

Also, it states that it should only be running on trusted networks, such as “localhost”. It should not be exposed to other computers on the network (and neither Websites should be able to communicate with it using the browser).

Anthropic's involvement in the development and management of the MCP ecosystem has led to improvements in the tools provided, but it also exposes certain weaknesses. The vulnerability we’re discussing - related to the lack of default authorization in the MCP Inspector - highlights the importance of improving security as the ecosystem evolves.

Who is using the MCP inspector?

Major tech companies like Microsoft and Google are increasingly using MCP-related technologies, especially in the realm of AI and cloud-based services. However, the same vulnerabilities that plague open-source projects are also a concern for large enterprises.

As part of ongoing efforts to ensure the safety of their users, companies must address the issues inherent in such open protocols. These organizations are beginning to recognize the need to include security features like authentication, encryption, and robust access controls, although the ecosystem remains in early stages of maturation.

0.0.0.0-day in 2025: Still Unpatched in Chromium and Firefox

What if attackers could leverage the MCP buzz to target MCP developers? Well, it’s no longer a theory, it is possible.

The 0.0.0.0-day vulnerability is an 19-year old vulnerability in all major browsers, which resides due to a lack of browser standardization - when it comes to requests that are being made to the private network.

The vulnerability stems from the inability of certain browsers to properly handle the IP address 0.0.0.0, which is often assumed to be secure because it points to localhost. Attackers can exploit this flaw by crafting a malicious website that sends requests to localhost services running on an MCP server, thereby gaining the ability to execute arbitrary commands on a developer’s machine.

Oligo Security called out this flaw in 2024. Despite the discovery and claims on fixes that are in progress, the vulnerability still remains unpatched in major browsers as of 2025. The IP 0.0.0.0 poses many developers at risk until a standard (RFC) will be available for the browsers to comply with and adhere to.

Localhost has been proved to be abused for years, from eBay scanning visitor’s ports.
Recent research called localmess proved Meta and Yandex have used it to fingerprint users (Web-to-App Tracking) in 2025. 

CVE-2025-49596 (CVSS Score 9.4): CSRF in MCP-Inspector Leads to Remote Code Execution 

One of the most serious concerns with this vulnerability is the Cross-Site Request Forgery (CSRF) attacks from public websites - dispatching malicious requests that can result in remote code execution on the MCP developer/user machine - even if it is listening on localhost /127.0.0.1.

Our payload will use the /sse endpoint with stdio transport, which has a command query parameter which is the terminal command we would like to execute. Then, we can use the args parameter to pass arguments to that command in the following way:

  • http://0.0.0.0:6277/sse?transportType=stdio&command=touch&args=%2Ftmp%2Fexploited-from-the-browser

When an attacker successfully crafts and sends a request to the MCP Inspector’s request, from a public domain’s javascript context, they can trigger arbitrary commands on the visiting (victim) machine, effectively gaining control over it.

The fact that the default configurations expose MCP servers to these kinds of attacks means that every time a developer runs the mcp dev command or executes the inspector proxy, they may be inadvertently opening a backdoor to their machine.

An example attacker payload that uses 0.0.0.0 as target host, will look like this:

<script>

fetch("http://0.0.0.0:6277/sse?transportType=stdio&command=touch&args=%2Ftmp%2Fexploited-from-the-browser", {

    "headers": {

        "accept": "*/*",

        "accept-language": "en-US,en;q=0.9", 

        "cache-control": "no-cache",

        "pragma": "no-cache"

    },

    "referrer": "http://127.0.0.1:6274/",

    "referrerPolicy": "strict-origin-when-cross-origin",

    "body": null,

    "method": "GET",

    "mode": "no-cors",

    "credentials": "omit"

})

</script>

Internet Facing Servers

The MCP Inspector tool has a unique fingerprint in the response, which makes it easier for attackers to identify. Internet facing servers are currently exposed to this attack.

We managed to identify MCP Inspector instances that are exposed to the internet and are in immediate risk of remote code execution. 

What can attackers achieve?

By doing so, the attacker can gain full access to the host machine, and everything that is connected to it via network.

Practical Risks: Targeting AI Developers and MCP Users

Let’s take a closer look at a scenario where an MCP inspector is being used, leading to an exploitation chain. A developer running or testing a local MCP server may follow the quickstart instructions, not realizing that by doing so, they’re leaving their host vulnerable to attack.

For example, a malicious attacker could create a blog post containing a payload that targets MCP servers. Once the developer visits the page, the malicious JavaScript would dispatch a request to 0.0.0.0:6277, instructing the MCP Inspector proxy to execute arbitrary commands.

In the end, the attacker gains full access to the developer’s machine, compromising the integrity of their system and any data it contains, opening reverse shells - all from a public web page.

Demo: MCP Inspector RCE using 0.0.0.0

In this section, we demonstrate how easy it is for an attacker to hijack an MCP inspector server running with default settings. By following the official quickstart guide and executing the mcp dev command, we open the server to remote code execution.

Steps:

  1. Run the command uv run mcp dev server.py
  2. The command runs the MCP Inspector proxy in the background automatically. The server is listening on port 6277.
  3. An attacker injects JavaScript into a malicious web page under a public domain.
  4. The JS payload dispatches a request to 0.0.0.0:6277. The HTTP packet reaches the server, which then executes the attacker-controlled command.
  5. Also, showed that the same attack can leverage DNS rebinding which is another attack vector, by creating a malicious DNS record that points to 0.0.0.0:6277  or 127.0.0.1:6277.

The Fix

We would like to thank Anthropic's Security Team for fixing this issue.
The MCP inspector is a developer tool for testing and debugging MCP servers. Versions of MCP Inspector below 0.14.1 are vulnerable to remote code execution due to lack of authentication between the Inspector client and proxy, allowing unauthenticated requests to launch MCP commands over stdio. Users should immediately upgrade to version 0.14.1 or later to address these vulnerabilities

In this commit, Anthropic added session token to the proxy by default. This approach is similar to the one of Jupyter notebooks. The session token makes sure only authorized clients can use the inspector - mitigating CSRF attacks.

  • Before version 0.14.1 there were no session tokens or authorization: 
~/git/oligo-mcp/ [main*] uv run mcp dev oligo_readonly_server.py
Starting MCP inspector...
⚙️ Proxy server listening on port 6277
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀

In version 0.14.1 a session token is used by default:

  • ~/git/oligo-mcp/ [main*] uv run mcp dev oligo_readonly_server.py
Starting MCP inspector...
⚙️ Proxy server listening on 127.0.0.1:6277
🔑 Session token: 03b238d87a33aa56033344589ed2ae01cde3dfd9d396a51548bfc9b6cdfd8291
Use this token to authenticate requests or set DANGEROUSLY_OMIT_AUTH=true to disable auth
🔗 Open inspector with token pre-filled:
   http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=03b238d87a33aa56033344589ed2ae01cde3dfd9d396a51548bfc9b6cdfd8291
   (Auto-open is disabled when authentication is enabled)
🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀

The commit also added allowed origins verification, which mitigates the browser attack vectors completely, resolving the attack vector that was possible from public websites. Imagine reading a blog about MCP, and ending up being exploited from a public website. After this fix, when the server binds only on localhost, it will not accept connections from public websites (non-allowed origins).

Also, the security documentation was improved:

Responsible Disclosure Timeline

  • April 18, 2025 - Oligo Reported the vulnerabilities to Anthropic, highlighting Remote Code Execution POC that is carried from a public website, by using the 0.0.0.0 IP address, with or without DNS rebinding (on modern browsers).
    • Anthropic shared that another researcher reported the vulnerability on March 26, 2025, and confirmed that they are working on a fix.

Looking Forward - Should I panic?

The primary recommendation is to secure your MCP inspector by enabling authentication and check the hosts by default - which is now the default, in version 0.14.1.

MCP inspector is often installed globally on a developer’s machine, but some projects are managing their own MCP inspector installations. We recommend upgrading the inspector globally and in each project that installs it (under node_modules). 

Make sure you are using the most recent version of the MCP inspector:

You can check which version is installed at the moment:

  • ~/ npm list -g
  • ├── @modelcontextprotocol/inspector@0.10.0 

The patched version is 0.14.1. In such case, upgrade your MCP inspector:

  • ~/ npm install -g "@modelcontextprotocol/inspector@^0.14.1"

Conclusion

Localhost services may appear safe but are often exposed to the public internet due to network routing capabilities in browsers and MCP clients. 

MCP’s official documentation was updated to educate users against 0.0.0.0 and DNS rebinding attacks targeting MCP inspector servers. The mitigation adds Authorization which was missing in the default prior to the fix, as well as verifying the Host and Origin headers in HTTP, making sure the client is really visiting from a known, trusted domain. Now, by default, the server blocks DNS rebinding and CSRF attacks.

The model context protocol is a great example of an open source with security in mind and care for its users:

  • MCP Inspector and Jupyter Notebook default configurations include authorization by default using session-tokens.
  • On the contrary, some Open Source projects often end up highlighting security warnings and disclaimers in their documentation, which places the responsibility of securing the deployment on the user’s, and assuming users read the documentation - one of the many reasons why Shadow Vulnerabilities exist, as well real-world attacks like ShadowRay that we have caught in the wild.

The MCP tooling ecosystem, being open-source, is still in its infancy, and we are happy . Until its security matures, developers should approach it with caution. Always read the docs.

References

  1. https://en.wikipedia.org/wiki/0.0.0.0#0.0.0.0_day_exploit
  2. https://nvd.nist.gov/vuln/detail/CVE-2025-49596
  3. https://github.com/modelcontextprotocol/inspector
  4. https://github.com/modelcontextprotocol/inspector/commit/50df0e1ec488f3983740b4d28d2a968f12eb8979#diff-c299744f73df4daa7a22854dda2023b68bfc8a5d59d8fb90b3a53b0c2842d807R98-R101
  5. https://github.com/modelcontextprotocol/inspector/security/advisories/GHSA-7f8r-222p-6f5g
  6. https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
  7. https://security.snyk.io/vuln/SNYK-UNMANAGED-CHROMIUM-7654159
  8. https://github.com/WebKit/WebKit/pull/29592/files
  9. https://localmess.github.io/
  10. https://www.youtube.com/watch?v=23Mz7qcRz50&ab_channel=Mrgavyadha

Popular Questions

What is CVE-2025-49596 and how severe is it?

  • A critical Remote Code Execution vulnerability (CVSS 9.4) in MCP Inspector
  • Allows attackers to execute arbitrary code when victims visit malicious websites
  • Affects all MCP Inspector versions prior to 0.14.1

How can I check if my MCP Inspector is vulnerable?

  • Run npm list -g to check your installed version
  • Versions below 0.14.1 are vulnerable
  • Check both global installations and project-specific ones in node_modules

What steps should I take to secure my MCP installation?

  • Upgrade immediately to version 0.14.1 or later
  • Run npm install -g "@modelcontextprotocol/inspector@^0.14.1"
  • Verify the update was successful by checking the version again

How does the MCP Inspector vulnerability work?

  • Exploits lack of authentication in the MCP Inspector proxy
  • Uses CSRF attacks from malicious websites to send commands to localhost
  • Leverages the 0.0.0.0 address to bypass browser security controls

What damage could an attacker do by exploiting this vulnerability?

  • Execute arbitrary code on the victim’s machine
  • Access sensitive data and credentials
  • Open reverse shells for persistent access
  • Potentially move laterally through connected networks

Who is affected by the MCP Inspector vulnerability?

  • AI developers or deployments using the MCP inspector tool
  • Anyone running the mcp dev command
  • Organizations with exposed MCP Inspector instances
  • Users of open-source projects that depend on the MCP inspector

What is the 0.0.0.0-day vulnerability and how does it relate to this exploit?

  • A 19-year-old browser vulnerability that mishandles the 0.0.0.0 IP address
  • Still unpatched in major browsers like Chrome and Firefox
  • Allows websites to communicate with localhost services
  • Enables the MCP Inspector exploit without requiring network access

expert tips

Avi Lumelsky
Avi Lumelsky
AI Security Researcher

Avi Lumelsky is a security researcher specializing in engineering and AI. At Oligo Security, he secures AI infrastructure by uncovering vulnerabilities in open-source projects. Previously at Deci AI (now part of NVIDIA), he focused on model optimization. His work has resulted in reports for major companies like Google and Meta, and has been featured in Forbes and Hacker News. He also maintains open-source eBPF projects and explores vulnerabilities in AI frameworks and inference servers.

Subscribe and get the latest security updates

Built to Defend Modern & Legacy apps

Oligo deploys in minutes for modern cloud apps built on K8s or older apps hosted on-prem.