What happened
MCP Inspector is a developer tool for testing Model Context Protocol servers. According to Vibe Incidents’ report, the maintainers released version 2.14.0 on November 4, 2026, and published three medium-severity security advisories fixed in that release. The report also says version 1.0.4 was released for the deprecated v1 line, fixing one of the three issues there. The source identifies no reports that these or the earlier advisories have been exploited.
The three new advisories cover different failure modes. GHSA-2fw8-7jmw-r937 concerns a stall triggered by a malicious tool-output-schema regular expression; it affects v2 releases through 2.13.0 and is fixed in 2.14.0, while the v1 fix is 1.0.4. GHSA-h9j8-vj8g-v3gg concerns an MCP App escaping its content security policy by navigating its own frame. GHSA-rwv7-mh2c-ff2p concerns unvalidated fields in imported server.json data and an unvalidated URL scheme in an elicitation URL modal. The report gives CVSS 3.1 scores of 6.5 and 6.1 for the first two, respectively, and describes the third as medium severity.
The report’s continuing concern is GHSA-wmjf-2m46-2352. Its affected-version range lists v1 releases, but its advisory write-up also identifies Inspector 2.5.0 as vulnerable. Vibe Incidents says it reproduced the behavior on versions 2.13.0 and 2.14.0: with the DANGEROUSLY_OMIT_AUTH setting enabled, a POST request to /api/mcp/connect without an Origin header returned successfully and launched a process. The report says no v2 release fixes this behavior.
The stated conditions matter. The report says the default origin allowlist and a Host check added in 2.12.0 block the browser route; the remaining exposure requires a local client able to reach the loopback port or an operator who broadens ALLOWED_ORIGINS, as well as authentication being disabled. Its practical advice is to upgrade to 2.14.0 or 1.0.4 for the issues those releases fix, and not to disable authentication. It says there is no version to upgrade to that closes the missing-Origin behavior.
The finding sits against a larger disclosure batch. On October 21, maintainers published nine advisories, including two critical issues rated CVSS 3.1 9.6, both on the v1 line and fixed in 1.0.3. The report says v2’s October fixes were in 2.12.0. The additional November fixes therefore do not erase the distinction between patched issues and the still-reproducible behavior under the specified configuration.
What the archive adds
Our Agno 3.1.9 note covered browser-origin access to an MCP server, a related security boundary but a different product and event. The MoLing MCP Server note covered a separate MCP vulnerability. This is a new Inspector-specific finding, not a restatement of either incident.
Trend signal
This incident supports agent security moves to runtime boundaries: safety depends on the runtime’s authentication, origin checks and reachable process-launch routes, not merely on what a model or user is told to do. The report’s caveat is important: the reproduced path requires authentication to be deliberately disabled and local reachability or broadened origins, so it does not establish exposure in default configuration.
Why now
The report was updated on November 5 after the November 4 releases of 2.14.0 and 1.0.4. That timing makes the distinction operationally relevant: teams can install fixes for the three new advisories now, while the report says the missing-Origin behavior has no fixed v2 release.
Why it matters
Security updates are not a single yes-or-no signal. A team that sees “2.14.0 fixes three advisories” could mistakenly infer that the Inspector’s reported process-launch risk is closed too. The report instead describes two separate decisions: upgrade to address the newly disclosed issues, and keep authentication enabled because the specific bypass reportedly remains possible when that safeguard is removed.
For teams that run Inspector to inspect untrusted MCP servers, the configuration is part of the threat model. The source describes the residual path as requiring both disabled authentication and a reachable local interface or widened origin policy; it does not claim that every default installation can be remotely exploited. That qualification avoids overstating the finding, but does not make the unsafe setting advisable. Operators should treat any relaxation of authentication or origin controls as a consequential exposure, rather than a convenience toggle, and verify their actual deployment settings.
The broader engineering lesson is to track remediation by advisory and affected version, not just by the newest release number. A patched release can close several vulnerabilities while leaving a separate behavior unresolved. Security reviews and internal upgrade notes should preserve that distinction, particularly for tools that can launch processes while connecting to external servers.
Limits and uncertainty
This account relies on the supplied Vibe Incidents report. It does not include independent reproduction by New Runtime, a maintainer response to the reported v2 behavior, or a release that fixes it. The source says exploitation has not been reported; absence of reports is not proof that exploitation did not occur. The described reproduction depends on DANGEROUSLY_OMIT_AUTH and stated reachability conditions, so it should not be generalized to default deployments. The report also describes advisory ranges and reproduction details that do not align cleanly for GHSA-wmjf-2m46-2352; that discrepancy is central to the claim and warrants maintainer clarification.
Reader takeaway
Upgrade Inspector to receive the fixes in 2.14.0 or 1.0.4, but do not treat that upgrade as closing every reported issue. The remaining behavior described by the source depends on authentication being disabled and has no fixed v2 release identified there. Keep authentication on and assess origin and local-port exposure in the configuration you actually run.