Security brief: MCP Python SDK fixes arrive with the audit switch off, a LiteLLM key-reuse bug turns any user into an admin with a shell, and MLflow's default server gets a 9.8

Executive summary

The level stays elevated: no live campaign against agentic software was confirmed in this window, but the week’s pattern is worth a decision. Three of the four most important items are cases where the vendor has already shipped a fix and the exposure remains because the fix is optional, because the default is unsafe, or because nobody was told. The MCP Python SDK’s audience check is the clearest case: the code has been out since 7 September and the advisory only became visible on 27 October. For an agent gateway such as LiteLLM, the same week shows the other recurring root cause, an administrator role that is by design a shell (it can register a stdio MCP server), so any privilege-escalation bug in the proxy is a code-execution bug.

Vulnerabilities

Item	Severity	Fixed in	Exploited	Notes
MCP Python SDK, bearer token audience (CVE-2026-116684)	Moderate 6.8	1.30.0, 2.2.0	No evidence	Fix is opt-in
MCP Python SDK, cross-origin redirects (CVE-2026-116685)	Moderate 5.9	1.30.0, 2.2.0	No evidence	Custom headers and bodies re-sent
MCP Python SDK, server-chosen $ref fetch (CVE-2026-116686)	Moderate 6.5	1.30.0, 2.2.0	No evidence	Client-side SSRF and event-loop stall
MCP TypeScript SDK, no body or batch limit (GHSA-f897-62hf-6gxq)	High 7.5	sdk 1.30.1, server and node 2.1.0, hono 2.0.1	No evidence	No CVE; availability only
LiteLLM proxy admin takeover (CVE-2026-114612)	High 7.7 (v4)	1.100.4 to 1.104.0rc2	No evidence	Ends in command execution
MLflow scorer deserialization RCE (CVE-2026-116692)	Critical 9.8	3.17.0	No evidence	Unauthenticated by default
MLflow prompt-version file read (CVE-2026-116690)	High 7.5	3.17.0	No evidence
MLflow CrewAI autolog key leak (CVE-2026-116691)	Moderate 6.5	3.17.0	No evidence	Keys already logged stay logged
Google Cloud MCP Toolbox, cloud-storage (CVE-2026-93328)	Critical 9.3 (v4)	Not stated	No evidence	1.2.0 to 1.4.0 per description
Google Cloud Run MCP (CVE-2026-85297)	High 7.7 (v4)	1.11.0	No evidence	Bucket squatting
Google ADK for Python FileArtifactService (CVE-2026-115522)	Moderate 5.3 (v4)	1.39.1, 2.7.0	No evidence	Cross-app artifact access
NVIDIA NeMo Agent Toolkit (CVE-2026-65145)	Critical 10.0	Not stated	No evidence	Record gives no versions
Kali-GPT MCP server (CVE-2026-117569)	High 8.5 (v4)	None	No evidence	shell=True; seven siblings below
Strands Agents session storage (GHSA-3w55-933p-8pv5)	High 7.1	1.48.0	No evidence	No CVE

MCP and protocol security

The MCP Python SDK catches up with its TypeScript sibling, and the audience fix is a setting you must turn on

OfficialCVSS 5.9 to 6.8Update · indexed 27 Oct

What happened. On 27 Oct GitHub’s advisory database indexed three advisories for the mcp package on PyPI, CVE-2026-116684 (bearer tokens for another service accepted), CVE-2026-116685 (HTTP clients follow cross-origin redirects with headers and bodies) and CVE-2026-116686 (the client fetches $ref URLs chosen by the server). The repository advisories date from 28 Sep to 5 Oct, and the fixed releases, 1.30.0 and 2.2.0, were published on 7 Sep according to the SDK’s release page. Affected ranges are 1.8.0 to 1.29.1 and 2.0.0 to 2.1.1 (the exact start differs by advisory). The TypeScript SDK’s equivalent trio (CVE-2026-111769, 111771 and the memory exhaustion in 111768) was covered in the 21 Oct brief; this is the Python half, plus a new TypeScript advisory on request size.

Analysis. Three different trust boundaries, one pattern: the SDK behaved as a generic HTTP client or token verifier and trusted whatever the other party handed it.

1. Audience. The server-side verifier checked that a token was valid, not that it was issued for this server. If one authorization server mints tokens for several services (the normal case in a company with a single identity provider), a token stolen from any low-value service works against your MCP server. Preconditions: HTTP transport with the SDK’s AuthSettings and token_verifier, a shared issuer, and a verifier that does not check aud itself. Blast radius is whatever the MCP tools can do as the token’s user. OWASP LLM06 (excessive agency) and Agentic ASI03 (identity and privilege abuse) apply; this is the confused-deputy class.
2. Redirects. Streamable HTTP and SSE clients, and the OAuth discovery, registration and token requests, followed redirects to any host, re-sending custom headers (an X-API-Key) and, on 307 or 308, the body. A bare Authorization header was not exposed, because the HTTP library already drops it across origins. A malicious server gains nothing, since it already receives the traffic; the risk is a trusted endpoint that gets redirected, by a compromised CDN, an open redirect, or DNS or proxy tampering.
3. Schema references. When a connected server declared an output schema for a tool, the client validated each result with a resolver that fetched any $ref it could not resolve locally. A malicious server could name an internal URL or a file path, so every call to that tool made the client request it from the client’s network position, and a target that accepted the connection and then went silent could freeze every session in the process, because the fetch ran on the event loop with no timeout. The fetched content was not returned to the server, so this is blind SSRF plus a stall, not data theft.

The detail that matters most is the first fix’s shape. validate_token_resource is off by default in 2.2.0; to benefit you must set it, set resource_server_url to the audience your authorization server uses, and make verify_token() return that audience as AccessToken.resource. Setting only the first switch makes every request return 401. The advisory says the default becomes True in 3.0. This is the same stance the TypeScript SDK took with expectedResource in 2.3.1, which I reported on 22 Oct: the safe behaviour exists and ships disabled so as not to break existing deployments.

The TypeScript advisory published alongside (GHSA-f897-62hf-6gxq, High 7.5, no CVE) is smaller: HTTP-reachable servers had no limit on POST body size or on the number of messages in a JSON-RPC batch, so one unauthenticated request could exhaust memory or block the server. Fixed in @modelcontextprotocol/sdk 1.30.1 and the server, node and hono 2.x packages; bodies over 4 MiB now get 413 and batches over 100 get 400. A body parser such as express.json() does not help, because it does not cap batch length.

Why it matters. Both SDKs now have the same three classes fixed, which tells you what the maintainers consider the baseline for an MCP server on the open network: audience-bound tokens, same-origin redirects, no network fetch driven by the peer’s schema, bounded input. If you wrote your own MCP server or client before reading these advisories, check it against that list. Note also that the Python fix landed seven weeks before the advisories were visible, so automated advisory scanners could not have told you to upgrade.

Mitigation and detection. Upgrade as in the act-now item and enable the audience check; test with a token issued for a different resource and confirm a 401. For clients, pass your own HTTP client with follow_redirects=False if you cannot upgrade, and rotate credentials that may have followed a redirect to a host you do not control. Detect: MCP gateway logs showing a client request to a host different from the configured endpoint; a Python agent process with outbound requests to link-local, private or file targets right after a tool call.

Recommendation (opinion): act this week. Treat ‘upgraded’ and ‘configured’ as separate checks. Add a test to every MCP server’s CI that presents a valid token for another audience and asserts rejection; that test would have caught this and the TypeScript twin. Do not wait for 3.0 to make the default safe.

Sources: GHSA-w4fh-qvv9-3v23 (audience) · GHSA-5h93-6whr-6q8j (redirects) · GHSA-rwrf-2pqf-9j8j ($ref) · GHSA-f897-62hf-6gxq (TypeScript limits) · Python SDK releases

Vulnerabilities in agent infrastructure

LiteLLM: one key for two jobs, and an admin role that is a shell

OfficialCVSS 7.7 (v4)Published 30 Sep · indexed 27 Oct

What happened. The LiteLLM advisory GHSA-7hp6-4w63-5g45 (CVE-2026-114612) describes a privilege escalation in the proxy: an authenticated user with the internal_user role can become proxy_admin and run arbitrary commands on the host. The repository advisory is dated 30 Sep, NVD published on 22 Oct and GitHub’s database on 27 Oct. Releases from 1.91.0 are exploitable in the default configuration; 1.87.0 to 1.90.x only if EXPERIMENTAL_UI_LOGIN=true was set. Patched lines are 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2. Credit goes to Haruna38 (reporter) and Hoa X. Nguyen of OPSWAT Unit 515.

Analysis. The proxy used a single encryption key for two jobs: sealing secrets at rest and minting session tokens. An internal user can ask for a new API key with a crafted metadata field whose “secret” value is a forged admin credential; the proxy encrypts that payload and returns it. Presented as a bearer token, the proxy decrypts it and trusts the identity inside. That is key reuse across a domain boundary (CWE-345, CWE-441), the same class as using one secret for signing and for encryption in a web framework. The second half is what turns it from an authorization bug into an execution bug: LiteLLM’s admin can register MCP servers, including stdio servers, which are commands the proxy launches. In agent gateways the administrator role is therefore equivalent to a shell on the gateway host, and the gateway host holds provider keys, virtual keys for every team and often cloud credentials.

I read the advisory only; I did not reproduce it, and the exploit steps above are as the advisory describes them. Compared with the 21 Oct compromise of LiteLLM 1.107.0 (a supply-chain attack), this one needs an authenticated insider rather than a poisoned package, so it matters most where many teams share one proxy and each gets an internal_user key. The two combine badly: if you run a shared proxy, you have now had a package-level and a role-level reason to rebuild it in the same week.

Mitigation and detection. Upgrade to the patched line for your series. Interim workaround from the advisory: EXPERIMENTAL_UI_LOGIN=false, which also breaks CLI SSO and Claude Code gateway login. After patching, rotate the salt key (rotation invalidates stored encrypted values, so plan the migration), list admins and MCP server registrations and remove any you did not create, and review keys created by internal users with unusual metadata. Detect: new proxy_admin activity from a user who was internal_user; a stdio MCP server registered outside change windows; a child process spawned by the proxy that is not in your known server list.

Recommendation (opinion): act today for shared proxies. Treat the gateway’s admin role as root. Limit it to two named people, require that stdio MCP servers come from a reviewed allow-list baked into the image, and do not give teams internal_user keys on a proxy that also holds production provider keys.

Sources: GHSA-7hp6-4w63-5g45 · PADAWAN: LiteLLM 1.107.0 compromise

MLflow: a 9.8 on the server many teams use to trace agents

OfficialCVSS 9.8Published 9 to 13 Oct · indexed 27 Oct

What happened. MLflow 3.17.0 fixes three advisories indexed on 27 Oct. CVE-2026-116692 (9.8, 3.12.0rc0 to before 3.17.0): during scorer deserialization the server imports a module path supplied by the caller, and only the package prefix is checked, so descendants of an allowed prefix pass. CVE-2026-116690 (7.5, 3.10.0 up to 3.17.0): path validation in the prompt branch of CreateModelVersion ran only when the source had a URL scheme, so a value like ../../../tmp was stored and the artifact endpoint served files from it. CVE-2026-116691 (6.5, 2.19.0 to 3.16.x): mlflow.crewai.autolog() serialised a CrewAI agent’s LLM object, including its api_key, into trace spans and exported OTLP telemetry. A related SSRF (CVE-2026-115886) was indexed on 23 Oct.

Analysis. MLflow matters here because teams use it as the trace store, prompt registry and evaluation harness for agents, and because mlflow server has no authentication by default. For the 9.8, the attacker uses the experiment, run and artifact-upload endpoints to place a module inside a writable scorer package, then triggers scorer invocation; the import happens before trace ids are validated, so the code runs even though the request fails. With basic auth on, the attacker needs an account that can create experiments, runs and artifacts, and the scorer-invoke endpoint also skips a resource-level permission check. The advisory’s reproduction used the official v3.14.0 image, which runs as root; it says a read-only container filesystem or a package directory owned by another non-writable user blocks the placement step. The file read exposes the server’s databases, including the auth database and admin password hash on basic-auth deployments. The key leak is the quietest and may be the most common in practice: the trace store becomes a second place where provider keys live, readable by everyone with trace access and by any OTLP destination. Same shape as the control-plane flaws in the 27 Oct brief: AI-adjacent tooling that ships without a login and holds provider keys. I have no evidence of exploitation.

Mitigation and detection. Upgrade to 3.17.0 (it does not clean existing data). Do not expose the tracking server without a proxy that authenticates; run the container read-only and non-root. If crewai.autolog() was on, rotate every provider key held by a CrewAI LLM object and purge or redact traces in MLflow and downstream telemetry stores; the workaround is mlflow.crewai.autolog(disable=True). Detect: unexpected new files under the scorer package directory, model-version sources containing .., and trace attributes matching your key prefixes.

Recommendation (opinion): act this week. Put MLflow behind the same authentication as your other internal tools and search your trace store for key patterns now; do it before the upgrade, because the upgrade removes the evidence of how long keys sat there.

Sources: GHSA-26p8-2jq9-3vq9 (9.8) · GHSA-m65p-9j7q-6w33 (file read) · GHSA-j7qq-vr8c-xvw3 (keys in traces)

Google and NVIDIA agent tooling: four records, few details

OfficialCVSS 5.3 to 10.0Late finds · 26 to 28 Oct

What happened. All four are GitHub-mirrored records marked unreviewed, so read them as pointers. Google’s Cloud MCP Toolbox for Databases has CVE-2026-93328 (9.3, v4): the cloud-storage source has path traversal and missing authorization, so an unauthenticated remote caller who makes a crafted tool invocation can send host files to an attacker-chosen Cloud Storage bucket and overwrite local files. The description names 1.2.0 through 1.4.0; the record lists no fixed version and points to googleapis/mcp-toolbox pull request 3454. Google Cloud Run MCP has CVE-2026-85297 (7.7): bucket squatting through predictable identifiers, fixed in 1.11.0, which per the advisory lets an attacker intercept proprietary source code and run code. Google ADK for Python’s FileArtifactService (CVE-2026-115522, 5.3, fixed in 1.39.1 and 2.7.0) left app_name out of artifact paths, so two apps sharing a storage root and a user_id could list, read, overwrite or delete each other’s artifacts; 2.6.0 fixed writes only and kept a legacy read fallback. NVIDIA NeMo Agent Toolkit has CVE-2026-65145 (10.0): missing authentication for a critical function, with no versions or component in the record (NVIDIA bulletin 5912). NVIDIA TensorRT-LLM also has three records from 27 Oct (CVE-2026-24269, 65120 and 65119: two SSRF and a router tokenizer issue); I read only the first (7.1, local vector, versions unknown).

Analysis and why it matters. The Toolbox flaw is the one to act on: a tool server that takes file paths and bucket names from the caller, with no authentication, is both a read and a write primitive reachable by prompt injection as well as directly. The Cloud Run MCP bug is a deploy-time trust problem: the tool uploads source to a storage location whose name an attacker can predict and claim first. These are the same two shapes as the reference-server bugs I reported on 27 Oct (a path boundary that fails, a network boundary that fails), now in vendor-run servers. I could not read NVIDIA’s bulletins or Google’s own advisories, so I cannot say whether either vendor treats the score as accurate. Do not rate the NeMo item from the number alone: a 10.0 with no component named may be a deployment-specific path.

Mitigation and detection. Inventory these products (pip show, image tags, Cloud Run deployments that use cloud-run-mcp). Upgrade ADK to 1.39.1 or 2.7.0 and give each app its own artifact root until then. For the Toolbox, keep the service off any network a user or agent can reach until you have confirmed a fixed build with Google; enable authentication and restrict the storage source to specific buckets. Pre-create the buckets your deploy tooling expects.

Recommendation (opinion): verify, do not assume. Read the vendor bulletins for the NeMo and Toolbox records before deciding. If you cannot establish whether you run an affected version within a day, treat the service as exposed and restrict it.

Sources: GHSA-2gc9-c85v-5vwr · GHSA-cg86-fr78-hv98 · GHSA-hjvp-7px2-52j7 · GHSA-8mjc-3v3w-78r7 · GHSA-mx93-gv2q-hr6f

Small items

MCP servers with command injection and no fix (27 Oct). GitHub mirrored a run of records for MCP servers that pass tool arguments to a shell. I read Kali-GPT (CVE-2026-117569, 8.5 v4, through commit a608c74): execute_tool() passes target, ports, domain, wordlist and url to subprocess.run with shell=True, so metacharacters let an MCP client or a prompt-injected agent run commands as the server user; it cites a VulnCheck advisory and an open repository issue. The same day, by title only (I did not open them): hagent (CVE-2026-117573), mcp-ffmpeg (117568), esp-mcp (117567), sf-mcp (117561), the ai-sdlc plugin’s MCP server through 0.31.2 (117558), an ATXP Gemini CLI extension (117560), DroidMind through 0.4.0 (117559, command injection by MCP clients) and an allow-list validation flaw in nmap-mcp (117570). None lists a fix. Same bug class and same advice as the 25 Oct brief: treat as unpatched, do not wire them to an agent that reads untrusted content, and prefer servers that call programs without a shell. Offensive-security MCP servers (Kali-GPT, nmap-mcp) deserve extra caution, since their purpose is to run attack tools on instruction. Sources: GHSA-qqg8-6hv5-w2xr · unreviewed MCP advisories list

Strands Agents session storage (GHSA-3w55-933p-8pv5, 7.1; GHSA-763v-5pjm-fx36). The default FileSessionManager stored sessions in a world-writable temp directory with predictable paths, and its write routine followed symlinks. A local user can redirect a write to another file the agent’s user owns, or plant a crafted session file that the SDK loads without an integrity check, which persists an injected prompt across runs. A second advisory notes the default storage is world-readable on shared systems. Fixed in strands-agents 1.48.0 (I read the first advisory; I did not open the second). Relevant to shared build hosts and notebooks. Set an explicit private session directory. This follows the 24 Oct Strands A2A context-sharing flaw. Source: GHSA-3w55-933p-8pv5

GitPython file read via a branch name (GHSA-23mf-xhv8-69c2, 7.1 v4, fixed in 3.2.0). Head.checkout() guards option-like keyword arguments but not the positional branch name, so a repository whose default branch is named like --pathspec-from-file=/etc/passwd can return file contents in an exception when a consumer clones it and checks out. The advisory does not mention agents; I include it because agent tooling that clones user-supplied repositories (code review, repo import, scanners) uses this library. Call checkout only with names you generated. Called an incomplete fix of CVE-2026-78679. Source: GHSA-23mf-xhv8-69c2

hydra-core legacy target blacklist (GHSA-wf6j-7hvr-gr93, 7.8, fixed in 1.3.8 and 1.4.0rc3). instantiate() can be pointed at yaml.unsafe_load when a configuration is untrusted, which runs code. The advisory’s example is a model repository that ships a malicious configuration; it states this does not mean all models are affected. Relevant if you load third-party model configs through Hydra. Source: GHSA-wf6j-7hvr-gr93

Incidents and threat intelligence

CrowdStrike: four actors with offensive agent frameworks (late find, early-tagged)

EarlyLate find · first published 21 Oct

What happened. Per search-result extracts from several outlets (the CrowdStrike page itself did not open), CrowdStrike published research on 21 Oct on four previously unreported actors that used AI agents to make decisions and run commands in intrusions between May and August 2026. Reported details: a Spanish-speaking operator with a supervisor-and-executor design built on Claude Code, reportedly derived from the open-source PentestGPT project and extended with MCP servers and skills, compromised at least 15 Argentine healthcare organisations (one Spanish-language outlet; credentials and medical records taken from at least one victim); a Chinese-speaking actor with a larger multi-agent system that fell back to other models when Claude was unavailable; an Indonesian-speaking actor using public GitHub skills with little orchestration. The actors’ frameworks were visible in open web directories, which is how the researchers saw them. One account says all four convinced models they were running authorised penetration tests.

Analysis. Unconfirmed beyond the extracts: victim counts, the 51-agent figure and the attribution of the framework lineage. What is consistent across the extracts is the mechanism, and it is the same as the Hermes, Cairn and Strix toolchain in the 20 Oct brief: commodity agents plus a workflow, with the model asked to act as a penetration tester. The control that fails is the model provider’s refusal layer, because ‘I am an authorised tester’ is a claim the model cannot check. Defenders see the result, not the prompt. OWASP LLM01 and MITRE ATLAS initial-access and execution techniques apply on the attacker’s side; for victims the relevant weakness is ordinary internet exposure that agents now probe at scale. What is new for defenders is cost and tempo, not technique.

Why it matters. It adds a second independent vendor to the picture of agent-driven intrusion with exposed attacker infrastructure, and the exposed directories are a detection opportunity for providers and researchers. The healthcare angle is the reason not to dismiss it as lab-grade.

Mitigation and detection. Nothing new beyond patch speed on internet-facing systems, egress monitoring and credential hygiene; time-to-patch matters more when the attacker iterates at machine speed. Ask your model provider and your own SOC how they would detect an agent session on your network (many tools, rapid sequential scans, unusual user agents).

Recommendation (opinion): watch. Do not change controls on this report alone. When CrowdStrike’s page or a second primary source is readable, check whether indicators or attacker prompts are published.

Sources: Search extracts: CrowdStrike blog title and summaries (not opened) · PADAWAN 20 Oct brief

Research and policy

Nothing new in the window passed the inclusion test. The only research I could confirm by title is an arXiv paper on Unicode tag-block concealment of MCP tool metadata across three server implementations (arXiv 2607.05744, July), which is outside the window; I did not read it. I found no new OWASP, NIST, CISA or ENISA agent-security publication in the window; the most recent OWASP item the search surfaced is the September Agent Control Standard announcement and NIST’s agent identity work is still at concept-paper stage per secondary sources. I report none.