Security brief: MCP Inspector's ten advisories include two critical remote-code-execution paths from a hostile server, and LiteLLM re-keys its release signing after the poisoned build
The official MCP Inspector shipped ten security fixes on 21 Oct, two of them critical (CVSS 9.6): a malicious MCP server could make the developer tool run local commands during OAuth or through an MCP App. LiteLLM also rotated its image-signing key and published new clean builds, and three small MCP packages carry unfixed code-execution CVEs.
Covers Sat 24 Oct 08:00 to Sun 25 Oct 08:00 CEST
Sunday window, thin for new events: I found no new confirmed exploitation of agentic software, no agentic CISA KEV entry, and no GitHub or NVD advisory for agent software dated 24 or 25 Oct (the newest in the reviewed and unreviewed feeds is 23 Oct, already covered on 24 Oct). About 30 searches and 25 page fetches. Several hosts did not resolve from this environment (CISA, NVD, arXiv, vendor blogs including LiteLLM's own incident page, Wiz, Endor Labs, Openwall), so the LiteLLM and eMudhra points rest on GitHub release notes plus search extracts and are tagged accordingly. The Inspector advisories were published on 21 Oct and reached me through the repository's advisory page; PADAWAN had not covered them, so they are late finds in effect. Type choice: AGENT.md v2 defines a single daily-brief, but the ledger, source registry and v2 types are not in the repository yet, so I kept the two legacy types the build and check script still accept (this brief and the daily signal). I did not create content/ledger.json or the source registry because the check script does not validate them.
Act now
- Upgrade the MCP Inspector to 1.0.3 (v1 line) or 2.12.0 (v2 line), and do not point it at servers you do not control until you have Check with `npm ls -g @modelcontextprotocol/inspector` and `npx @modelcontextprotocol/inspector --version`; npx users get the latest unless a version is pinned or cached. Affected: Inspector 0.13.0 to 1.0.2 and 2.0.0 to 2.11.0. Windows and WSL users on 2.0.0 to 2.11.0 are exposed to the OAuth-URL command injection just by connecting. If you connected to an untrusted remote server or opened an MCP App from one, treat that machine as possibly compromised and rotate credentials the user session could read.
- If you run LiteLLM, move to 1.106.3 (or your branch's 24 Oct backport) and update cosign verification to the new key Admission policies (Kyverno, Sigstore policy-controller, Connaisseur) and CI scripts pinned to the old cosign.pub will reject the new images. The release notes give the new key commit (e82a3c6) and SHA-256 e3fe3e08c44b16407fe0b37c43b4f8b603b3a0f4ee74c29e647bc022d762c2c0. Keep 1.107.0 blocked; see the [23 Oct alert](/reports/2026-10-23-litellm-1-107-0-compromise/).
In brief
- MCP Inspector, the official debugging client for MCP servers, published ten advisories on 21 Oct. Two are critical (CVSS 9.6): a hostile remote server can switch the Inspector to stdio during the OAuth callback and run an arbitrary local command (GHSA-4fc4-wcmh-4g86), or a malicious MCP App can steal the proxy token and do the same (GHSA-6x67-4w4w-9f3w). Fixed in 1.0.3 (v1 line) and 2.12.0 (v2 line). No CVE IDs have been assigned.
- A third path hits Windows and WSL users of Inspector 2.0.0 to 2.11.0: an OAuth authorization URL containing PowerShell subexpressions is auto-opened and executed (GHSA-q978-78c7-phqw, 8.8, fixed in 2.12.0). A fourth closes an incomplete DNS-rebinding fix that leaked tokens.
- LiteLLM's 24 Oct releases (1.106.3, with backports to 1.103.8, 1.104.6 and 1.105.4) change the image-signing key and remove the eMudhra root CA from every bundled trust store. Anything verifying images with the old cosign key will now fail. This is the first vendor-side change I can read since the 1.107.0 compromise; LiteLLM's own post-mortem was not reachable.
- Three npm MCP servers (@rog0x/mcp-docker-tools, @rog0x/mcp-git-tools, @justice8096/sagemath-mcp-server, all 1.0.1) carry unreviewed code-execution CVEs rated 7.5 with no fix or description of the flaw. Treat as unpatched; the same bug class as earlier shell-string MCP servers.
- mcp-from-openapi 2.9.0 fixes credential forwarding across cross-origin redirects and a trailing-dot bypass of its SSRF blocklist (CVE-2026-115750, CVE-2026-115751). AWS fixed a deny-list bypass in the AWS MCP Server's run_script tool service-side (CVE-2026-115845); no customer action.
Executive summary
No new live campaign in the window, so the level stays elevated, not high (yesterday’s was also elevated; the LiteLLM alert from 23 Oct still stands). The most useful thing in the advisory feeds is a lesson about the tool developers use to look at MCP servers: the official Inspector treated the server it was inspecting as trusted in three different places. Connect it to a hostile server and the server can run commands on your laptop. That puts the MCP Inspector in the same class as the Storybook dev server and the obsidian-tc vault server of the last few days: a developer tool bound to localhost or a browser, running with the developer’s full privileges.
The second thread is follow-through on LiteLLM. The vendor has re-keyed its release signing and published clean builds. That is the correct response, and it creates work for every team that verifies images.
Vulnerabilities
| Item | Severity | Fixed in | Exploited | Notes |
|---|---|---|---|---|
| MCP Inspector, OAuth callback to stdio (GHSA-4fc4-wcmh-4g86) | Critical 9.6 | 1.0.3 | No evidence | Hostile server; user must complete OAuth |
| MCP Inspector, MCP App steals proxy token (GHSA-6x67-4w4w-9f3w) | Critical 9.6 | 1.0.3 | No evidence | Viewing the app is enough |
| MCP Inspector, PowerShell injection via auto-opened OAuth URL (GHSA-q978-78c7-phqw) | High 8.8 | 2.12.0 | No evidence | Windows and WSL only |
| MCP Inspector, six more (missing auth, DNS rebinding, leaks, DoS, log leak) | Low to High | 1.0.3 / 2.12.0 | No evidence | See below |
| @rog0x/mcp-docker-tools, mcp-git-tools; @justice8096/sagemath-mcp-server 1.0.1 (CVE-2026-106765, -106764, -106763) | High 7.5 | None referenced | No evidence | Unreviewed, no mechanism published |
| mcp-from-openapi (CVE-2026-115750, CVE-2026-115751) | Moderate 6.3 | 2.9.0 | No evidence | Credential forwarding, SSRF blocklist bypass |
| AWS MCP Server run_script (CVE-2026-115845) | Moderate 5.3 | Service-side | No evidence | No customer action |
MCP Inspector: the tool for examining an MCP server trusted the server
What happened. On 21 Oct the modelcontextprotocol/inspector repository published ten advisories and two releases: 1.0.3 for the deprecated v1 line and 2.12.0 for v2. Two are critical remote-code-execution paths that start when a developer connects the Inspector to a remote MCP server they do not control. One uses the OAuth callback page, which read the transport, command and arguments from its own URL query string and, after the token exchange, reconnected with those values, so the proxy launched the attacker’s command (affects 0.13.0 to 1.0.2; reported by bhavya32). The other renders an MCP App in a sandbox hosted on the proxy’s own localhost origin, so the app runs same-origin with the proxy; it can ask the UI to open a link, the new window inherits the stored proxy token, and a crafted parameter points the client’s proxy address at an attacker server, which then holds the token needed to call the proxy’s stdio endpoint (0.20.0 to 1.0.2). A third, High at 8.8, affects 2.0.0 to 2.11.0 on Windows and WSL: the server returns an OAuth authorization_endpoint containing PowerShell $(...) subexpressions, Inspector auto-opens it through the open package, which does not escape the target there, and the command runs during connection with no tool call and no model involved (reported by eilonc-pillar; the reporter confirmed the injection string on macOS, so the Windows outcome rests on code reading). The remaining advisories cover missing authentication on a critical function when auth is off, an incomplete fix for the earlier DNS-rebinding token disclosure (CVE-2025-49596), cross-origin leakage of auth and cookie headers through /fetch, a proxy token sent to a query-controlled origin, plaintext SSE headers in logs, and unbounded response size in /api/fetch.
Analysis. The root cause repeats across all of them: the Inspector is a client whose job is to talk to untrusted servers, yet the data coming back (OAuth metadata, callback parameters, app code) was allowed to steer a privileged local component, the proxy that spawns processes. That is a trust-boundary inversion. The preconditions are modest: the developer connects to a server they found in a registry, a blog or a chat message, and (for the callback path) completes a sign-in. Blast radius is the developer’s user account: source, SSH keys, cloud credentials, and any agent tokens on the workstation. It is the same pattern that produced the original Inspector flaw in 2025, and the DNS-rebinding advisory here is literally an incomplete fix for it. Mapping: OWASP LLM03 (supply chain) and LLM06 for the tooling, Agentic Top 10 tool misuse; MITRE ATLAS initial access through a malicious tool or server. Compare the Storybook preview flaw, where a web page could run code in a dev server, and the browser path into obsidian-tc on 24 Oct: developer tools are now a first-class target for hostile MCP content.
Why it matters. Anyone who evaluates third-party MCP servers (security reviewers, platform teams, researchers) uses exactly this tool, and does so on a machine rich in credentials. The fixes also show the limits of the MCP “user must approve tools” model: none of these paths involve a tool call or the model.
Mitigation and detection. Upgrade to 1.0.3 or 2.12.0. On v2, set MCP_INSPECTOR_ALLOWED_HOSTS if it runs behind a reverse proxy (the new host check returns 403 for unlisted hosts). Run the Inspector in a container or throwaway VM with no cloud credentials when inspecting unvetted servers, and do not mount your home directory. For detection, look for unexpected child processes of the Node process that runs the Inspector proxy, and for outbound connections from developer machines to hosts that appeared only in an MCP server’s OAuth metadata. No CVE IDs exist yet, so scanners keyed on CVE will miss these; key on the GHSA IDs and on the package versions.
Recommendation (opinion): act today. Treat the Inspector as untrusted-input software, not as a benign debugger. Upgrade, then sandbox it. If you cannot tell whether a developer connected an old Inspector to an unknown server, rotate their cloud and source-control credentials rather than hunting for proof.
Sources: Inspector security advisories · GHSA-4fc4-wcmh-4g86 · GHSA-6x67-4w4w-9f3w · GHSA-q978-78c7-phqw · Inspector releases 1.0.3 and 2.12.0
Small MCP packages with code-execution CVEs and no fix
What happened. NVD published three CVEs for npm MCP servers at version 1.0.1: @rog0x/mcp-docker-tools (handleImageList, CVE-2026-106765), @rog0x/mcp-git-tools (resolveBaseBranch, CVE-2026-106764) and @justice8096/sagemath-mcp-server (escapeShellString and sanitizeCode, CVE-2026-106763). Each is rated 7.5 (network, high complexity, user interaction required) and each is unreviewed by GitHub. The records name the vulnerable function but give no mechanism, no fixed version and no weakness class; each links a GitHub issue on the project and a third-party CVE file.
Analysis. I could not verify the technique, so this is tagged early. The function names (a list of images, a base-branch resolver, a shell-escape helper) point to the familiar pattern of building a shell command from a tool argument, which an injected instruction or a hostile tool result can steer; the “user interaction required” rating fits an agent that must be coaxed into calling the tool. Blast radius is the host the server runs on, with whatever credentials it carries (a Docker socket, a git credential). No exploitation evidence.
Why it matters. These are exactly the servers that appear in agent tool lists because they are one npx away. A “fixed” status cannot be read from the records, so a blocklist by name and version is the only safe control today.
Mitigation and detection. Search lockfiles, MCP client configs and agent images for these package names. Remove them or pin to a version the maintainer confirms fixed; check the linked issues. Run any MCP server that touches Docker or git without the Docker socket and with a read-only checkout.
Recommendation (opinion): remove or sandbox. For unmaintained single-author MCP servers, an allowlist of reviewed packages beats chasing individual CVEs.
Sources: GHSA-fq6x-j3g6-xx83 · GHSA-jwc4-922r-f2rw · GHSA-2vq3-mpmf-9xgr
mcp-from-openapi and the AWS MCP Server: two filter bypasses
What happened. mcp-from-openapi (agentfront), a library that turns an OpenAPI spec into MCP tools, forwarded Authorization and Cookie headers when a spec fetch followed a cross-origin redirect (2.5.0 to before 2.9.0, CVE-2026-115750), and its ssrf.blockedHosts list could be bypassed by adding a trailing dot to a blocked hostname (2.2.0 to before 2.9.0, CVE-2026-115751). Both are fixed in 2.9.0. Separately, the run_script tool of the AWS MCP Server used an incomplete deny-list in its Python validator (CWE-184), letting an authenticated user run code inside their own isolated session; AWS fixed it service-side (CVE-2026-115845, AWS bulletin 2026-149).
Analysis. Same lesson three times: deny-lists around fetchers and code validators lose to a variant (a trailing dot, a redirect, an unlisted builtin). The redirect credential leak matches the MCP TypeScript client advisory from 21 Oct (GHSA-6prh-2h8m-c8cw). Impact is limited: the SSRF reaches only what the server’s network can, and the AWS item is contained to the caller’s session.
Why it matters and what to do. Low urgency; these are hygiene. Upgrade mcp-from-openapi to 2.9.0 if you generate tools from third-party specs, and never let a spec URL be chosen by an untrusted party. No action for AWS.
Sources: GHSA-3gr3-m4x5-3fpp · GHSA-wfcf-h98w-gp9m · GHSA-jmwp-36mq-x645
Incidents and supply chain
LiteLLM: new clean builds, a new signing key, and the eMudhra root CA removed (Update)
What happened. LiteLLM published 1.106.3 on 24 Oct, with backports to 1.105.4, 1.104.6 and 1.103.8. The release notes flag two changes. All images and Helm charts are now signed with a new cosign key (commit e82a3c6), and verification with the old key (0112e53) fails. The eMudhra root CA is removed from every certificate bundle the SDK, proxy and Docker images trust. The notes do not mention the 1.107.0 incident. The vendor’s own incident page was not reachable here; a search extract of it describes the incident as contained with the investigation in progress.
Analysis. Re-keying is what you do when you can no longer trust that the old signing material was only in your hands after a release pipeline compromise; the 23 Oct alert noted the poisoned wheels were built from a lookalike repository outside the normal path. The CA removal comes from a separate matter: eMudhra revoked eight intermediate certificates whose keys were generated with insufficient randomness, and browsers blocked them from 17 to 20 Oct. Non-browser software with its own trust store may keep trusting them, which is why gateway images, where every upstream model API call rides on TLS, were updated. I could not open the vendor write-ups, so root cause and attribution remain unconfirmed here; a search extract notes an earlier March compromise of the same project was tied to the TeamPCP campaign, with no established link to this one.
Why it matters. The people hurt by a signing-key change are the careful ones: those who verify. Teams that never verified signatures are unaffected by the rotation and also unprotected.
Mitigation and detection. Update cosign verification to the new key (the notes include a verify command and the key’s SHA-256), use 1.106.3 or your branch’s backport, and keep 1.107.0 blocked at your package proxy. Confirm that any other component bundling its own CA store (agent runtimes, MCP clients) picked up the eMudhra change.
Recommendation (opinion): do it this week. Pinning by digest and verifying with a reviewed key is the control that would have mattered on 21 Oct; this is the moment to make it policy.
Sources: LiteLLM v1.106.3 release notes · LiteLLM releases · search extracts of LiteLLM’s incident notice and the eMudhra CA coverage (vendor and press pages not opened)
Policy and research
Nothing in the window passed the inclusion test. I found no new NIST, CISA, ENISA or INCIBE publication on agents dated within the day; the policy items surfaced by search (the EU Digital Omnibus delay of high-risk AI Act obligations, OWASP’s September GenAI update) are months old and I did not open them.