MCP Inspector Security Update: What 2.14.0 Fixes and How to Verify Your Setup

MCP Inspector 2.14.0 fixes three security issues in the v2 line. If you use the legacy v1 line, 1.0.4 addresses the schema-validation stall, the only one of the three advisories that lists v1. Check the copy your browser or automation actually uses: a fresh terminal can resolve a patched package while an older Inspector process is still serving the same local port.

The project’s 2.14.0 release et 1.0.4 release were published late on November 4, 2026 UTC. The associated advisories appeared across November 4–5 UTC. These are fixes for the Inspector client and its local tooling, not evidence that the Model Context Protocol itself or every MCP server is vulnerable.

Which version fixes your issue?

These are the ranges in the three project advisories for @modelcontextprotocol/inspector, not a general minimum for every future advisory. Use a currently approved release containing the fixes. The project marks v1 deprecated; use its 1.0.4 fix if you still need that line, and plan the v2 move rather than treating the legacy release as interchangeable with v2.

What changed at each trust boundary

App frames must not inherit the trusted relay after navigation

The first advisory is about the web client’s handling of an untrusted App. A page loaded inside the default sandbox could navigate its own frame, and the relay could continue delivering host messages to the replacement document. That means a reviewer could think the app’s approved content security policy (CSP) governed the interaction when the bridge was still talking to a different page. Later tool results passed into the app were among the data at risk.

The patched proxy constructs a frame policy from the app’s approved CSP grants, removes the frame and closes the relay when it detects that the loaded document is being replaced, and signals the host. This is a relay and frame-lifecycle fix; it is not a claim that CSP prevents every browser navigation or that a CSP display proves no network traffic ever left the machine. The project advisory specifically excludes the CLI and TUI, users who do not render Apps, and Apps that use the dedicated-origin path from this issue. Do not apply that exclusion to the separate schema advisory.

Import review, URL opening and preview are distinct controls

The second advisory groups several input-handling issues. An imported registry-style server.json could carry launch arguments not adequately shown in the review interface. The update shows the resolved command before saving and rejects invalid inputs such as empty environment-variable names or unsafe tokens. Treat what appears there as a command review, not as proof that a package or its arguments are trustworthy. Review the publisher, version, arguments and any requested local resources before connecting.

For URL elicitation, the web UI now allows HTTP and HTTPS schemes and rejects other schemes with an explanation. An allowed scheme says nothing about whether the destination is an approved identity provider, so still verify the destination before opening it. The same release also moves the preview’s CSP ahead of document markup. That is a separate control from the Apps tab relay; passing one check cannot close both findings.

Tool schemas are input, not authority

The third advisory concerns denial of service. A connected malicious server can supply a regex in its tool output schema and then return a result that makes synchronous validation expensive enough to stall the Inspector. It depends on the interaction with a server and its tool, not merely having Inspector installed. The advisory does not establish code execution or disclosure from the stall itself.

On v2, the release uses a bounded, linear-time matcher with per-pattern and per-schema limits for tool output and app elicitation schemas. A pattern that cannot be checked within those constraints is reported as unverified instead of evaluated. On v1, 1.0.4 omits server-provided regex checks and reports which checks were skipped; a schema the Inspector cannot safely transform can be reported as not validated. In both cases, do not turn an unverified pattern or skipped check into a validation pass in CI. If an output format is a release requirement, independently validate the requirement against a small test fixture.

Prove the fixed package is the one you are using

1. Locate the actual launcher. Check whether the browser session came from an npx command, a project dependency, a global install, a container or a teammate’s shared test host. Record the launch method and owning process or container, not just a version from an unrelated terminal. Be careful with process arguments and URLs: they can contain secrets.
2. Reconcile the approved package with the launch environment. Inspect the resolved dependency, lockfile or running image ID and approved image digest. A manifest range is a request, a lockfile is a resolution, and neither proves which process is running. A registry integrity value identifies the published tarball, not the bytes served by an old process. The npm registry’s 2.14.0 package record et le tagged manifest give you a reference to compare with your approved source.
3. Confirm the Node version used to launch it. The 2.14.0 manifest declares ^22.23.4 || ^24.22.1 || >=26.12.1. The release describes npm’s EBADENGINE as advisory, so successful startup on an older Node version does not mean it meets the declared floor. Check inside the same runner or container, not just on the host.
4. Restart or recreate the relevant instance. Stop the old Inspector through the team’s normal workflow; account for active test sessions. Launch the approved patched package or recreate the service from the approved image. Refresh the browser after the new listener is up. Capture the new process or container identity and startup time. A healthy response alone does not prove a patch was loaded.

For a locally installed v2 launcher, the tagged launcher documentation says --version exits without starting a client. These commands illustrate different inventory checks; use only the lines matching your installation. Run the version command through the same approved executable or path used to launch the service. It reports that executable’s version, not the version of a different running process.

node --version
npm ls @modelcontextprotocol/inspector --depth=0
npm ls -g @modelcontextprotocol/inspector --depth=0
mcp-inspector --version

The upstream release suggests npx @modelcontextprotocol/inspector@latest for v2 and @v1-latest for legacy v1. Both are moving tags, and npx may install and execute a package. In a controlled rollout, resolve the tag through your approved registry, pin the chosen patched artifact in the appropriate job or environment, and verify that the service restarts from it. This prevents a command run on your laptop from being mistaken for an upgrade to a shared deployment.

Retest in a disposable environment and record what passed

Use an owned, isolated Inspector and a known local MCP test server. Start with synthetic tool results, no production credentials, no host mounts containing developer secrets and no unnecessary outbound access. Retain version, client mode, fixture revision and timestamp for each check. The project’s Docker guidance recommends loopback-only published ports for local work. Upgrading the package does not repair a container or reverse proxy that exposes the service too broadly.

For negative controls, start from the tagged sandbox smoke test, le input-handling patch tests et le v2 pattern-validator tests. Review the fixtures and test environment before running them. An upstream test result for the tagged source and your result for a deployed copy answer different questions.

If you previously tested a server you no longer trust, review which Apps were rendered, what was imported or launched, and whether sensitive results or local credentials could have been exposed. Preserve the relevant evidence, then follow your incident process for any applicable credential rotation or endpoint review. The update addresses the documented paths going forward; it cannot establish what happened in an earlier session.

Keep the Inspector upgrade separate from the assessment of the server it connects to. After this client check, use MCP security testing for authorization, tool permissions and data exposure to evaluate the server, its credentials and its downstream effects. Neither a patched client nor a successful tool call establishes that the connected service enforces your authorization policy.

Method: AI-assisted source review and a proposed defensive validation procedure, prepared November 6, 2026. No Inspector instance, MCP server, production environment or Penligent task was tested for this article.