← All incidents

MCP Inspector's Oct 21 advisories closed the v1 line, but one record understates a missing-Origin bypass that still works on 2.14.0

Vulnerability · MCP Inspector · HIGH

Summary

On Oct 21, 2026, the maintainers of MCP Inspector, the developer tool for testing MCP servers, published nine GitHub security advisories for the npm package @modelcontextprotocol/inspector and recorded patched versions for all nine that day: 1.0.3 reached npm about 33 minutes before the first advisory, and 2.12.0 reached it 3 minutes 51 seconds after the last v2 advisory. Five of the nine affect only the deprecated v1 line and are fixed in 1.0.3. Two affect only the v2 line, every release from 2.0.0 through 2.11.0, and are fixed in 2.12.0. One, the /fetch size cap, affects both lines. The ninth, GHSA-wmjf-2m46-2352, is the one that is not closed. Its range field says 0.14.1 through 1.0.2, fixed in 1.0.3, but its own write-up lists inspector@2.5.0 as a confirmed vulnerable version with a reproduction, and we reproduced it on 2.13.0 and again on 2.14.0: with authentication disabled through DANGEROUSLY_OMIT_AUTH, a request with no Origin header reaches the process-launch route and the process runs. 2.14.0 fixes three new advisories but not the absent-Origin bypass, and npm's latest as of Nov 4, 2026, 7:17:31 PM ET is 2.14.0, so for that half there is still no fixed release to move to and the advice is configuration, not a version. The two most serious advisories, GHSA-4fc4-wcmh-4g86 and GHSA-6x67-4w4w-9f3w, are rated Critical at CVSS 3.1 9.6 and both end in attacker-chosen commands running on the developer's machine after they connect to or view a malicious MCP server, with nothing else to click. Both affect only the v1 line, 0.13.0 through 1.0.2 and 0.20.0 through 1.0.2, so nobody who stayed on v2 was exposed to them. Two of the nine are described in their own advisories as incomplete fixes for CVE-2025-49596, the critical Inspector proxy flaw from June 2025: GHSA-wmjf-2m46-2352, recorded against v1, and GHSA-vcc9-3xgm-p9v4, recorded against v2. The repo's advisory index carries those two 2025 records as well, GHSA-7f8r-222p-6f5g for CVE-2025-49596 and GHSA-g9hg-qhmf-q45m for CVE-2025-58444, which is why it lists eleven advisories and not nine. None of the nine has a CVE ID. The advisories credit bhavya32 for both criticals, and four more carry credit under five other names: sondt99 for GHSA-2rq8-f55p-j2jp, CloneOfAlex for GHSA-m5pj-3536-3xcp, eilonc-pillar for GHSA-q978-78c7-phqw, and 0xParth and hackyhunter for GHSA-vcc9-3xgm-p9v4. Three carry no credit, and the 1.0.3 release notes name five reporters for those three: andesyteoss and lemohangkhaile-blip for GHSA-wmjf-2m46-2352, ayaangazali and GEONWOOHAN for GHSA-f6mc-jg3x-vq53, and dodge1218 for GHSA-8qgq-27v6-55w3. The 2.12.0 notes also thank imran-siddique alongside 0xParth and hackyhunter for GHSA-vcc9-3xgm-p9v4, though that advisory's own credit lists only 0xParth and hackyhunter. The v2 high GHSA-q978-78c7-phqw is the PowerShell injection through a remote server's OAuth address that we recorded in our Oct 19 entry on OpenCode, and the underlying flaw in the open package has since been published as CVE-2026-119025. On the evening of Nov 4, 2026 the maintainers published three more medium advisories, all fixed in 2.14.0: GHSA-2fw8-7jmw-r937 (CVSS 3.1 6.5, a stall on a malicious tool output schema regex, also fixed in 1.0.4 on v1), GHSA-h9j8-vj8g-v3gg (CVSS 3.1 6.1, an MCP App escaping its CSP by navigating its own frame), and GHSA-rwv7-mh2c-ff2p (medium, unvalidated runtimeArguments and identifier in server.json import, and an unvalidated URL scheme in the elicitation URL modal). KillerX345 is credited on GHSA-2fw8-7jmw-r937 and CloneOfAlex on GHSA-h9j8-vj8g-v3gg; GHSA-rwv7-mh2c-ff2p lists no credit. None of those three outranks the absent-Origin finding, and none of them closes it. We found no reports that any of the nine, or these three, has been exploited.

Severity

Timeline

1. Jun 13, 2025, 11:01 AM ET
   GHSA-7f8r-222p-6f5g (CVE-2025-49596) is published, Critical, for Inspector before 0.14.1. The proxy ran without authentication between the client and the proxy.
2. Sep 6, 2025, 4:53 PM ET
   GHSA-g9hg-qhmf-q45m (CVE-2025-58444) is published, High, for an XSS reached through a malicious redirect URI that could reach the proxy and run commands. Fixed in 0.16.6.
3. Mar 27, 2026, 2:33 AM ET
   a pull request, #1161, proposes rejecting requests with a missing Origin header in v1's origin validation middleware, the change that would have closed this case.
4. Aug 19, 2026, 5:18 PM ET
   the maintainers close #1161 unmerged. Their reasoning is in the how-it-happened section.
5. Aug 24, 2026, 12:20 AM ET
   1.0.2 is published to npm, the last v1 release before the batch.
6. Oct 14, 2026, 12:45 AM ET
   2.11.0 is published to npm, the last v2 release before the batch.
7. Oct 21, 2026, 2:12 AM ET
   1.0.3 is released, and it reaches npm at 2:20:11 AM ET. It is a security release for the deprecated v1 line and fixes seven advisories, including GHSA-wmjf-2m46-2352.
8. Oct 21, 2026, 2:53 to 2:57 AM ET
   six advisories are published, all recorded against the v1 line: GHSA-8qgq-27v6-55w3, GHSA-wmjf-2m46-2352, GHSA-4fc4-wcmh-4g86, GHSA-6x67-4w4w-9f3w, GHSA-f6mc-jg3x-vq53 and GHSA-2rq8-f55p-j2jp.
9. Oct 21, 2026, 2:13 PM ET
   2.12.0 is released, and it reaches npm at 2:35:58 PM ET. Its notes say it fixes three vulnerabilities that affect every v2 release from 2.0.0 through 2.11.0.
10. Oct 21, 2026, 2:31 to 2:32 PM ET
    three more advisories are published: GHSA-q978-78c7-phqw and GHSA-vcc9-3xgm-p9v4 for the v2 line, and GHSA-m5pj-3536-3xcp for both lines.
11. Oct 28, 2026, 3:00 PM ET
    2.13.0 reaches npm. It does not change the absent-Origin behaviour.
12. Nov 4, 2026
    we reproduced the GHSA-wmjf-2m46-2352 bypass on 2.13.0 from the published package, and this entry is added.
13. Nov 4, 2026, 6:28 PM ET
    1.0.4 is released, and it reaches npm at 6:34:10 PM ET. It is a security release for the deprecated v1 line and fixes GHSA-2fw8-7jmw-r937. npm moves the v1-latest tag to 1.0.4.
14. Nov 4, 2026, 6:44:10 PM ET
    GHSA-2fw8-7jmw-r937 is published, medium (CVSS 3.1 6.5), for a stall on a malicious tool output schema regex. Range covers 2.0.0 through 2.13.0 (fixed in 2.14.0) and v1 through 1.0.3 (fixed in 1.0.4). Credited to KillerX345.
15. Nov 4, 2026, 6:55 PM ET
    2.14.0 is released, and it reaches npm at 7:17:31 PM ET. Its notes say it fixes three vulnerabilities reported against v2. npm moves the latest tag to 2.14.0.
16. Nov 4, 2026, 7:28 to 7:29 PM ET
    two more medium advisories are published: GHSA-h9j8-vj8g-v3gg (CVSS 3.1 6.1, credited to CloneOfAlex) and GHSA-rwv7-mh2c-ff2p (no credit listed), both covering 2.0.0 through 2.13.0 and fixed in 2.14.0.
17. Nov 5, 2026
    we reproduced the GHSA-wmjf-2m46-2352 bypass on 2.14.0 from the published package. The absent-Origin request still returns 200 and the process runs. This entry is updated for 1.0.4, 2.14.0 and the three new advisories.

How it happened

MCP Inspector is a local tool, so every one of these flaws is about who can reach the local services it starts and what those services will do when asked.

The two criticals on v1 share a root cause: a local proxy that starts processes on request, reachable from the browser page the developer is looking at.

GHSA-4fc4-wcmh-4g86: Inspector reads its own connection settings, including the transport type, the command and its arguments, from query parameters on the page URL. Those are meant for the command line. The OAuth callback page also reads them, and it only extracts the code. So when a malicious remote MCP server runs an OAuth challenge and points the browser at Inspector's callback address with transport=stdio and a serverCommand appended, the page initialises as a local stdio connection to the attacker's command, and on reconnect the proxy runs it. The advisory says connecting to an unknown MCP server can trigger code execution without any further interaction with tools. 1.0.3 stops the callback page from taking connection settings from its URL at all, reconnects only with the connection saved in that tab before the redirect, and never over stdio.

GHSA-6x67-4w4w-9f3w: the sandbox that renders MCP App content served to it sits on the proxy's own origin. Browsers send no Origin header on a same-origin GET, and v1's process-launch route is a GET, so the proxy's origin check let those requests through. window.open from the sandbox also inherited the tab's sessionStorage, which holds the proxy auth token. The advisory's chain opens a link that points the Inspector address at an attacker server with MCP_PROXY_FULL_ADDRESS set, sends the token with it, and then calls the stdio endpoint directly. 1.0.3 opens app links with noopener and noreferrer and only for http and https addresses, and the proxy now rejects same-origin browser requests to its API unless the operator opts in with the new DANGEROUSLY_ALLOW_SAME_ORIGIN_API setting.

The advisory that is not closed, GHSA-wmjf-2m46-2352, is worth reading in its own words. CVE-2025-49596 was fixed in 0.14.1 by adding two middleware layers to the sensitive routes, a session token and an Origin allowlist. The advisory says the fix is incomplete: "When authentication is intentionally disabled via DANGEROUSLY_OMIT_AUTH, the remaining Origin validation fails open for requests with no Origin header." It is explicit that the flag is not the bug. "The bug is not the existence of DANGEROUSLY_OMIT_AUTH. It is that the flag removes one defense, but the second defense is implemented as if authentication were always present."

That framing matters, because the obvious objection is that a flag named DANGEROUSLY_OMIT_AUTH turning off authentication is not a vulnerability. The advisory answers it directly: the Origin check is a second, separate control, and the code describes it as DNS-rebinding protection, so it is meant to hold on its own and instead fails open. What happens next is the part we did not expect. In March 2026 someone proposed exactly this fix for v1 in #1161, adding a missing-Origin rejection alongside the existing disallowed-Origin rejection. It was reviewed, and closed unmerged in August 2026. The maintainer's closing explanation is that a request with no Origin still has to present the session token, so origin validation is defence in depth here rather than the guard standing in front of the proxy, and that "the missing-Origin path is not an unauthenticated bypass". He also noted that v2's middleware has the same shape deliberately, that v2's README documented the skip as intentional, describing the API token as "the only guard" for non-browser clients, and that the change would break curl, Postman and CI scripts and leave the two lines disagreeing on a security default. Every one of those points holds while authentication is on. The advisory is about what is left when the flag turns it off, and in that configuration the token check is gone and the Origin check is the only control standing.

The record then contradicts its own range, which is the part that made this easy to miss. GHSA-wmjf-2m46-2352's range field covers 0.14.1 through 1.0.2 with the fix at 1.0.3, and only v1 packages, so read at the field level it is a v1 advisory like the other five from that morning. Its body says otherwise. It lists inspector@0.14.3, inspector@1.0.2 and inspector@2.5.0 as versions confirmed vulnerable, with a reproduction against each, and a results table showing 2.5.0 returning 200 and spawning a process. We checked the current release rather than take either half on trust, and 2.14.0 behaves the same way. The Origin middleware in 2.14.0 reads the Origin header and compares it only when one is present, so a request that omits it reaches the route. With DANGEROUSLY_OMIT_AUTH set, POST /api/mcp/connect with no Origin header returned 200 with a session id and the process ran. With an unrecognised Origin it returned 403, and with authentication left on it returned 401.

How reachable that is depends on the line, and the difference is the HTTP method. On v2 the process-launch route is a POST. Browsers append an Origin header to any request whose method is neither GET nor HEAD, same-origin requests included, so a page on another origin gets the 403 and cannot make this request silently. A page served from the proxy's own origin does pass, because the default allowlist is built from that origin; it fails only once an operator narrows the list with ALLOWED_ORIGINS. The pages Inspector hands a guest are on other origins, the sandbox on its own port and the app-document host on another, and under the default allowlist both are rejected: their origins returned 403 in the same run. That default holds the line, but with authentication disabled the allowlist is what does it: adding the app-document origin to ALLOWED_ORIGINS reopens the route, and in a test of exactly that configuration the request returned 200 and the process ran. From 2.12.0 the server also validates the Host header and refuses a Host that is not ours, which closes the DNS-rebinding shape even for a request that arrives without an Origin: a spoofed Host returned 403 on 2.13.0. So under default settings the browser route is closed in practice: nothing Inspector serves a guest comes from its own origin, and the pages it does serve are on other origins, which the default allowlist rejects. Under those defaults, what is left is a non-browser client that can already reach port 6274 on the loopback interface, or a page that somehow got itself served from that origin, which nobody has demonstrated; in other words, something already running on the machine. On 2.5.0, the version the advisory names, there is no Host check at all, and the same spoofed-Host request returned 200 and spawned, so on that release the path was reachable by a name-based request too.

On v1 the process-launch route is a GET, and browsers send no Origin header on a same-origin GET. That is the same fact GHSA-6x67-4w4w-9f3w is built on in this batch. The consequence is that on a v1 release with authentication disabled, a page served from the proxy's own origin can reach the route with no Origin header at all. 1.0.3 is what closes it, including against a plain GET with no Accept header: 200 and a spawned process on 1.0.2, 403 "Missing origin (required when authentication is disabled)" on 1.0.3. So the v1 half of this advisory is fixed, and the v2 half is not.

The remaining advisories are smaller and all closed: GHSA-2rq8-f55p-j2jp: the stored proxy token was sent to whatever proxy address a URL supplied, and that address was then saved.

GHSA-f6mc-jg3x-vq53: the /fetch proxy followed cross-origin redirects and kept sending Authorization and Cookie headers. The advisory calls it a regression from the SSRF hardening in 1.0.0.

GHSA-8qgq-27v6-55w3: the proxy logged SSE auth and custom headers word for word, so credentials ended up in logs.

GHSA-q978-78c7-phqw: a remote server picks the OAuth authorization address, Inspector opens it with the open package, and open 10.2.0 placed that address inside a PowerShell double-quoted string with no escaping. Windows and WSL evaluate $( ) inside those strings, so the address runs as code. 2.12.0 restricts opening to http and https, opens the checked URL rather than the raw input, and moves to open 11.0.4. This is the same underlying flaw as CVE-2026-119025, published Oct 29, 2026, which names Inspector 2.0.0 before 2.12.0.

GHSA-vcc9-3xgm-p9v4: the advisory says CVE-2025-49596's fix does not hold on v2 either. The Origin middleware trusts requests with no Origin header, there is no Host validation, and GET / serves the API token unauthenticated. The advisory walks a DNS-rebinding chain that reads the token and then stored OAuth tokens and local client config files. It notes that the process-launch route is a POST, which browsers send with an Origin header, so the chain stops at information disclosure. That is the same reasoning we applied above. 2.12.0 validates the Host header against an allow list and answers 403 outside it, with MCP_INSPECTOR_ALLOWED_HOSTS for reverse proxies. The Origin middleware itself is unchanged in 2.12.0 through 2.14.0 and still lets requests with no Origin header through, so the Host check is what closes the browser route, and what stops the chain at information disclosure today is the method, not the Origin check.

GHSA-m5pj-3536-3xcp: the fetch proxy, /api/fetch on v2 and /fetch on v1, reads the upstream response whole with no byte cap and re-encodes it, so an untrusted or misbehaving MCP server can exhaust the Inspector backend's memory with a large or unbounded response. The advisory's range covers both lines, v1 0.21.2 through 1.0.2 and v2 2.0.0 through 2.11.0, but its own wording is that v1 was not reviewed, and the finding was a static review of 2.7.0 with no live exploit run. So the v2 exposure is the documented one and the v1 half is the record's range, not a confirmed finding. Both lines ship a cap in their fixes: 5 MiB in 1.0.3 and 4 MiB in 2.12.0.

On the evening of Nov 4, 2026 the maintainers published three more medium advisories, all with range 2.0.0 through 2.13.0 and fixed in 2.14.0: GHSA-2fw8-7jmw-r937, credited to KillerX345, a stall on a malicious tool output schema regex (also on v1 through 1.0.3, fixed in 1.0.4); GHSA-h9j8-vj8g-v3gg, credited to CloneOfAlex, an MCP App escaping its CSP by navigating its own frame; and GHSA-rwv7-mh2c-ff2p, with no credit listed, unvalidated runtimeArguments and identifier in server.json import plus an unvalidated URL scheme in the elicitation URL modal. 2.14.0 fixes those three and does not close the absent-Origin bypass.

How to check your app

• Find the version you are actually running. If Inspector is installed globally, npm ls -g @modelcontextprotocol/inspector prints it. If you start it with npx and no version, we suggest passing @latest explicitly, because npx can otherwise reuse a copy it cached earlier.
• On v1, 1.0.4 is the current fixed release and it is on npm under the v1-latest tag. v1 is deprecated and receives security fixes only, so we suggest moving off it. Upgrading does matter on this line: 1.0.3 closed the missing-Origin case as well as the two criticals, and 1.0.4 also closes GHSA-2fw8-7jmw-r937.
• On v2, 2.12.0 or later closes the three Oct 21 advisories with a fixed version, and adds the Host check. Every release from 2.0.0 through 2.11.0 carries at least one of them. 2.14.0 closes the three Nov 4 medium advisories. Upgrading to 2.14.0 does not close the absent-Origin item, and we want to be plain about that: 2.14.0 fixes three new advisories but not the absent-Origin bypass, and there is no v2 release that does.
• Do not set DANGEROUSLY_OMIT_AUTH. That flag is the difference between this being a defence-in-depth gap and being a way to run a command. If you must turn authentication off, treat the Inspector port as a local command-execution surface: keep it bound to loopback, do not expose it through a proxy or a tunnel, do not run an Inspector session in a browser on a machine you would not hand a shell to, and shut it down when you are done. On 2.12.0 through 2.14.0 the Host check blocks name-based requests, and it does not block a client that is already on the machine.
• If you are on 1.0.2 or older and you ran with authentication disabled, a page could reach the process-launch route without an Origin header, so update to 1.0.4 rather than relying on network position.
• Treat Inspector as what it is: a tool for connecting to servers you do not yet trust. Run it on a machine you would not mind losing, keep it off internal networks while you point it at unknown servers, and on Windows or WSL be aware that a server can choose the OAuth address it hands your browser.
• If you connected a v1 Inspector, 1.0.2 or older, to a remote MCP server you do not control, the criticals need no further clicks, so we suggest treating that machine as possibly compromised, checking what the OAuth provider issued to it, and rotating anything it could reach.

Sources

• GitHub advisory GHSA-4fc4-wcmh-4g86
• GitHub advisory GHSA-6x67-4w4w-9f3w
• GitHub advisory GHSA-q978-78c7-phqw
• GitHub advisory GHSA-vcc9-3xgm-p9v4
• GitHub advisory GHSA-m5pj-3536-3xcp
• GitHub advisory GHSA-wmjf-2m46-2352, the open half
• GitHub advisory GHSA-2rq8-f55p-j2jp
• GitHub advisory GHSA-f6mc-jg3x-vq53
• GitHub advisory GHSA-8qgq-27v6-55w3
• GHSA-7f8r-222p-6f5g, CVE-2025-49596, the June 2025 critical the incomplete fixes refer to
• GHSA-g9hg-qhmf-q45m, CVE-2025-58444, the September 2025 XSS to command execution
• The repo's advisory list, the index these eleven come from
• Pull request #1161, the missing-Origin fix for v1, closed unmerged
• Inspector 1.0.3 release notes, which name each fix and the reporters
• Inspector 2.12.0 release notes
• Inspector 2.13.0 release notes
• GitHub advisory GHSA-2fw8-7jmw-r937, Nov 4 medium
• GitHub advisory GHSA-h9j8-vj8g-v3gg, Nov 4 medium
• GitHub advisory GHSA-rwv7-mh2c-ff2p, Nov 4 medium
• Inspector 1.0.4 release notes
• Inspector 2.14.0 release notes
• npm package page, for dist-tags, publish times and the v1 deprecation notice
• Fetch Standard, the algorithm that appends the Origin header, for when a browser sends one and when it does not
• NVD: CVE-2026-119025, the open package flaw behind the v2 PowerShell advisory
• The open package fix commit for the PowerShell escaping

Corrections and updates

1. Nov 4, 2026
   Corrected within minutes of publication. The first version said the pages Inspector serves a guest are on other origins and are rejected, without saying what rejects them. Veritas showed, and Noctis reproduced, that adding the app-document origin to ALLOWED_ORIGINS returns 200 and runs the process. The paragraph now says the default allowlist is what holds the line and says plainly that one configuration line undoes it. No other part of the entry changed.
2. Nov 5, 2026
   Updated for the Nov 4, 2026 releases. 1.0.4 is now v1-latest and 2.14.0 is latest. Three new medium advisories are listed (GHSA-2fw8-7jmw-r937, GHSA-h9j8-vj8g-v3gg, GHSA-rwv7-mh2c-ff2p), all fixed in 2.14.0, with GHSA-2fw8-7jmw-r937 also fixed in 1.0.4. We reproduced the absent-Origin bypass on 2.14.0, and 2.14.0 does not fix it. The default allowlist and own-origin behaviour are unchanged from 2.13.0.