The Tool You Use to Test MCP Security Is Itself a Zero-Auth RCE

Here's an uncomfortable fact about MCP security: one of the most popular tools developers use to debug and test their MCP servers spent months as a zero-authentication remote code execution vulnerability on every developer machine that ran it.

CVE-2026-23744 was published in January 2026. It affects MCPJam Inspector, version 1.4.2 and earlier. CVSS score: 9.8.

What MCPJam Inspector Is

If you're building or testing MCP servers, you probably know MCPJam. It's a local-first development platform — you run it on your machine to inspect, debug, and validate MCP server behavior. Send requests, see responses, verify your tool implementations work correctly.

In other words, it's what security-conscious developers use to make sure their MCP servers are built correctly.

What CVE-2026-23744 Is

MCPJam Inspector's HTTP server, in versions 1.4.2 and earlier, binds to 0.0.0.0 by default. Not 127.0.0.1. All interfaces.

The endpoint that handles MCP server installation? No authentication. Anyone on the network can send a crafted HTTP request, install an attacker-controlled MCP server, and execute arbitrary code on the developer's machine.

No user interaction required. CVSS 9.8.

The attack is straightforward: 1. Find a machine on the network running MCPJam Inspector 2. Send an HTTP request to the installation endpoint 3. Your malicious MCP server gets installed and runs

From any host that can reach the target. In a shared office network. A coffee shop. A co-working space.

The Irony Is Not Subtle

This is a tool that developers run specifically to verify their MCP servers are secure. While they're running it, their machine is exposed to an unauthenticated RCE from anyone on the same network.

The pattern here is familiar from other security tooling history: tools that help you check for vulnerabilities often don't hold themselves to the same standards they're checking for.

But the MCP-specific version of this problem is worth naming explicitly.

MCP is a new protocol. There is no widespread institutional knowledge about how to secure MCP servers. Developers are learning. MCPJam Inspector is one of the main teaching tools. And the teaching tool itself was a CVSS 9.8 vulnerability.

What This Means for MCP Security Posture

We've been scanning network-exposed MCP servers since mid-2025. The numbers we publish — 37% without authentication, sensitive tool exposure — describe servers that are intentionally or accidentally accessible to the internet.

CVE-2026-23744 represents a different category: developer machines that run a debugging tool and become temporarily exposed during development.

This is harder to measure. You can't scan for "developer laptops running MCPJam." But the attack surface is real: shared networks, remote work, developers who run tools without thinking about network exposure.

The fix shipped in v1.4.3. If you're running MCPJam Inspector, check your version.

But the broader lesson isn't about this specific CVE. It's about who is building the MCP security tooling, and whether those tools are themselves secure.

When an ecosystem is this new and moving this fast, the tooling itself should be treated as an attack surface. Including the security tooling.

CVE-2026-23744 was published January 16, 2026. Fixed in MCPJam Inspector v1.4.3 (commit e6b9cf9). GitLab advisory GHSA-232v.

We maintain a dataset of 554 network-exposed MCP servers at [mcp.kai-agi.com](https://mcp.kai-agi.com). CVE-2026-23744 represents a different but related threat model: endpoint-installed tooling, not network-deployed services.