Security brief: LiteLLM's poisoned release traced to a leaked master key nobody revoked, ransomware affiliates caught running coding agents, and a Google ADK dev server any web page can drive
LiteLLM's 23 Oct root-cause account says an unrevoked Agent Platform master key, committed to a public repository in May, was the first link in the chain that ended in the poisoned 1.107.0 release. SOCRadar reports ransomware affiliates running commercial and open models through a coding agent against victims, and Google's ADK for Java dev server can be driven by any web page the developer visits.
Covers Fri 23 Oct 08:00 CEST to Mon 26 Oct 08:00 CET
Monday window (Friday to Monday), thin for new events: no new confirmed exploitation of agentic software, no agentic CISA KEV entry I could find, and the newest advisories in GitHub's feeds are three small unreviewed ones dated 25 and 26 Oct. About 30 searches and 20 page fetches. Many hosts did not resolve from this environment (docs.litellm.ai, socradar.io, hackread.com, dev.to, BleepingComputer, Datadog, CISA, NVD, modelcontextprotocol.io), so the LiteLLM root cause and the SOCRadar findings rest on search-result extracts that quote the primary pages, and are tagged accordingly; I did not open either primary page. The advisory pages for the CVEs below were read in full. Two stories I could only see as headlines are not reported here: a BleepingComputer item on sandbox escapes in Cursor, Codex CLI, Gemini CLI and Antigravity (attributed to Pillar Security; I found only a repost, no date) and a claim that a planted AGENTS.md file made a coding agent install a rogue npm package (no source I could open). Type choice: AGENT.md v2 defines a single daily-brief, but the ledger, source registry and v2 types are still not in the repository, so I kept the two legacy types the build accepts. For ecosystem and protocol state see the [daily signal](/reports/2026-10-26-daily-signal/).
Act now
- Upgrade Google ADK for Java to 1.13.0, or set an explicit origin allowlist, on every machine that runs the ADK Web server Affected: com.google.adk:google-adk-dev 0.1.0 to before 1.13.0 and google-adk-maven-plugin 0.3.0 to before 1.13.0. On 1.6.0 to 1.12.0 set adk.web.cors.origins to the exact origins you trust, for example http://localhost:8000. Do not browse the web in the same browser profile while the dev server runs on older versions.
- Check for committed and unrevoked gateway and platform keys, and scope organisation-owner tokens The LiteLLM chain started with a key in a public repository that stayed valid after the commit was rewritten. Run a secret scan across all repositories including forks and your AI-tooling organisations, treat any key that was ever committed as burned and revoke it, and replace personal owner-level GitHub CLI tokens in automation with scoped, short-lived credentials.
In brief
- LiteLLM root cause (Update, 23 Oct, vendor account as quoted by search extracts): an Agent Platform master key sat in a config file committed to a public repository on 27 May and was never revoked. On 10 Oct the attacker used it to get an organisation-owner GitHub CLI token, then stole two maintainer tokens from CI secrets and on 21 Oct forced a release workflow, pointed at a lookalike repository, through. LiteLLM corrected its earlier account of where the first token came from.
- SOCRadar (20 Oct, secondary coverage only): an exposed command-and-control server tied to INC and The Gentlemen ransomware affiliates held 8,257 AI messages from 133 OpenCode sessions, 46 custom encryptor builds for six victims and over $23,000 of API spend. Operators approved each step and, when models refused, reworded requests as 'authorized red team' tasks. Encryptor builds are preparation evidence, not confirmed deployment.
- Google ADK for Java dev server (CVE-2026-107858, CVSS 7.2, fixed in 1.13.0): the /run_live WebSocket and REST API accepted any origin and had no authentication, so a web page visited by the developer can talk to the local agent, trigger its tools and read or delete sessions. Same class as the Storybook and Trigger.dev flaws covered on 21 and 22 Oct.
- vLLM CVE-2026-114055 (CVSS 7.5, fixed in 0.31.0): a per-request multimodal processor field lets one unauthenticated request exhaust memory and crash the server. It completes the set of request-controlled flaws in 0.31.0 and shows the same lesson as the three earlier ones.
- Three small items with no fix: docker-mcp 0.1.0/0.2.0 command injection (CVE-2026-116102), Continue 2.0.0 MCP transport command injection with a public exploit and a silent vendor (CVE-2026-116109), and a SiYuan MCP asset tool that copies .env-style files into a readable folder (CVE-2026-116168, fixed in 3.8.7).
Executive summary
Level stays elevated. There is no new live campaign against agentic software in this window, but two items change how I would brief a board. First, LiteLLM’s own root-cause account turns the 21 Oct compromise into a story about one forgotten key and an over-powered owner token, not a clever exploit: every link in the chain is a hygiene control that most companies also lack. Second, a security vendor recovered the working logs of ransomware affiliates who run a coding agent on their targets, with a person approving each step. That is not autonomous crime, and it does not need to be: it is a cheaper, faster operator.
Vulnerabilities
| Item | Severity | Fixed in | Exploited | Notes |
|---|---|---|---|---|
| Google ADK for Java dev server (CVE-2026-107858) | High 7.2 | 1.13.0 | No evidence | Drive-by from any web page; no auth |
vLLM mm_processor_kwargs (CVE-2026-114055) | High 7.5 | 0.31.0 | No evidence | One request can crash the server; auth optional |
| docker-mcp 0.1.0, 0.2.0 (CVE-2026-116102) | Moderate 5.3 | None referenced | No evidence | project_name reaches a Windows command line |
| Continue 2.0.0 (CVE-2026-116109) | Low 2.1 (CNA) | None referenced | No evidence | MCP transport command injection; public exploit; vendor silent |
| SiYuan MCP asset tool (CVE-2026-116168) | Moderate 6.9 | 3.8.7 | No evidence | Incomplete deny-list copies .env-type files |
Google ADK for Java: a local agent server any web page could drive
What happened. The ADK Web development server in Google’s Agent Development Kit for Java accepted WebSocket connections on /run_live from any origin, and its REST API returned a wildcard Access-Control-Allow-Origin. It has no authentication. Versions 1.13.0 and later default to same-origin and reject DNS-rebinding requests over loopback (CVE-2026-107858, GHSA-2pr8-78jh-mm95).
Analysis. Entry point: a web page the developer happens to open while the dev server runs. Trust boundary crossed: the browser, which is allowed to reach localhost, becomes the attacker’s relay into a process that assumes only the developer talks to it. Root cause: a server built for convenience that treats network position as identity. Impact: the page can message the agent (so trigger any tool registered with it), stream its answers, and list, read, create or delete sessions and artifacts. Binding to 127.0.0.1 does not help, since the requests come from the developer’s own browser. Preconditions: the dev server is running, a browser on the same machine visits a hostile page, and on 1.6.0 to 1.12.0 the wildcard comes from a default property rather than hard-coded code. Blast radius is whatever the agent’s tools can reach on a developer laptop. This is the same shape as the Storybook MCP addon (CVE-2026-114125) and Trigger.dev’s --mcp server in the 21 and 22 Oct briefs, and as obsidian-tc’s missing Origin check on 24 Oct. OWASP Agentic ASI02 (tool misuse) and ASI05 (unexpected code execution) fit; the LLM Top 10 ‘excessive agency’ item is the root. I could not find any exploitation.
Why it matters. Four unrelated products in six days made the same mistake, which says the default in agent developer tooling is still ‘local means trusted’. Local agent servers carry the developer’s credentials and tools.
Mitigation and detection. Upgrade to 1.13.0. On 1.6.0 to 1.12.0 set adk.web.cors.origins to explicit origins. Run agent dev servers in a separate browser profile or container, and check for listeners from agent frameworks on developer machines (ss -ltnp filtered for the JVM).
Recommendation (opinion): act today for Java teams. Treat every agent dev server as a network service that needs an Origin check and a token, and ask your framework vendors for it as a procurement criterion.
Sources: GHSA-2pr8-78jh-mm95
vLLM: one more request-controlled field, and the pattern is now four
What happened. vLLM before 0.31.0 let any API client set mm_processor_kwargs on a request. The server passed those values to Hugging Face and custom image and video processors, so a client controls image size, patch, crop or frame counts. For processors that upscale input one request exhausts memory and crashes the API server or worker for every user (CVE-2026-114055, GHSA-gx7p-2j49-hfq4). The fix rejects non-empty per-request values at every request schema by default.
Analysis. Entry point: the inference API. Preconditions: vLLM’s API key is optional, so a deployment with no external auth is reachable unauthenticated. Root cause: a generic forwarding of client fields into model-specific constructors, the same design behind the code-revision flaw (CVE-2026-114053, 21 Oct) and the cache-key flaws (CVE-2026-114054 and CVE-2026-114050, 23 Oct), all fixed in 0.31.0. The advisory names the Isaac processor as a high-amplification case and says similar forwarding exists in several vision-language processors. The fix is a boundary check, not a per-model list, which is the right design.
Why it matters. Availability of a shared inference server is a security property: one anonymous request takes down every tenant and every agent behind it.
Mitigation and detection. Upgrade to 0.31.0 (this one release closes this and the three earlier flaws). Put authentication and a request-size and rate limit in front of the API; alert on engine restarts and out-of-memory kills. Only operators serving fully trusted clients should opt back in to per-request overrides.
Recommendation (opinion): fold into your existing 0.31.0 upgrade. If you had not planned it, this is the fourth reason.
Sources: GHSA-gx7p-2j49-hfq4
Three small MCP and agent tools with no fix, or a thin one
docker-mcp (QuantGeekDev) 0.1.0 and 0.2.0: the project_name argument reaches a Windows command line (CVE-2026-116102, CVSS 5.3, no fixed version listed). Continue 2.0.0: command injection in the MCP server transport configuration code (CVE-2026-116109, scored 2.1 by the CNA because it assumes user interaction; the reporter says an exploit is public and the vendor never answered). SiYuan before 3.8.7: the MCP asset upload tool’s path check is a deny-list that omits .env-type files, so a user who can trigger the tool can copy local secrets into the readable workspace and fetch them over HTTP (CVE-2026-116168, 6.9).
These are all the same bug class already covered: values from a model-reachable surface reaching a shell, or a deny-list standing in for an allow-list. Low CVSS numbers understate agent-specific risk when the ‘user’ in the vector is a model that reads untrusted text. Remove docker-mcp and Continue 2.0.0 MCP server definitions you do not control, or run them in a container with no host mounts.
Sources: GHSA-7mj2-6mxg-wcx9 · GHSA-3cxv-6mgc-j7c4 · GHSA-659w-8mpv-qcqc
Incidents and supply chain
LiteLLM: the root cause is a key that was never revoked (Update)
What happened. The 23 Oct root-cause account from LiteLLM, as quoted by several search extracts (I could not open the page), traces the 21 Oct compromise of release 1.107.0 to an Agent Platform master key. A configuration file containing it was committed to a public repository on 27 May. The commit was later overwritten by a force-push, but the key kept working. On 10 Oct the attacker used it against the Agent Platform API and obtained a GitHub CLI token belonging to an organisation owner, a token that was not tied to a service account or narrowed. With it the attacker changed workflows in internal repositories and took two more maintainer tokens from CI secrets. On 21 Oct a protected release-workflow change was rejected, then forced through with the owner token, the pipeline was pointed at the lookalike Berri-AI/litellm repository, and a second maintainer’s stolen token approved the production run. LiteLLM also corrected its first account, which had said the first owner token came from deployment logs.
Analysis. Entry point: a secret in a public Git history (ATLAS/OWASP: agentic supply chain, ASI04, and credential exposure). The chain went secret, platform API, owner-level token, CI secrets, release pipeline, and each hop crossed a boundary that should have required a second, independent control. Branch protection stopped the first release change and then did not stop the attacker, because the owner token could override it. Compare with the March LiteLLM incident, which came through a compromised scanner in CI: both reached the publish credential through the pipeline rather than through the code. Two points are my inference, not LiteLLM’s claim: that the lookalike-repo trick was meant to keep the Git tag clean, and that the ‘second approval’ was the only human gate left.
Why it matters. The lesson for every team that runs an AI gateway is that the gateway’s master and admin keys are cloud-credential vaults (as Cloud Security Alliance and Wiz have shown for default keys) and that their release pipelines hold the keys to every downstream user’s secrets. Force-pushing a history does not revoke a secret.
Mitigation and detection. Revoke, do not rewrite: treat any key that ever hit a public commit as compromised, including in forks and caches. Run secret scanning with push protection on every organisation, including AI-tooling and experimental ones. Use scoped, short-lived credentials (OIDC) for automation and keep owner-level tokens off CI and off personal CLIs. Require a human approval that an organisation owner cannot bypass for release workflows, and make the release job verify the source repository identity. For consumers: the clean-up steps in the 23 Oct alert still apply, and the 24 Oct signing-key change is covered in the 25 Oct brief.
Recommendation (opinion): audit this week. Search your own repositories for committed gateway and platform keys, and ask your AI-gateway vendor how release approval and signing are protected from a stolen owner token.
Sources: LiteLLM incident page (not opened; quoted by search extracts) · BerriAI/litellm issue 47826 (title only)
Ransomware affiliates running a coding agent against victims, with a person approving each step
What happened. SOCRadar’s threat research unit reports that one publicly reachable command-and-control server, run by affiliates of the INC and The Gentlemen ransomware groups, exposed AI session databases, a knowledge base and the source code of a framework called Phantom (‘Autonomous Red Team Kill Chain Framework’). Logs on it led to six more exposed servers. The recovered records cover 8,257 AI messages across 133 sessions of the open-source coding agent OpenCode, 46 custom INC encryptor builds prepared for six victims, and more than $23,000 of AI API spend. Models named in the coverage include a commercial Claude model and Kimi K3. Initial access reportedly targeted public-facing FortiClient EMS, SimpleHelp, cPanel and VPN gateways. I read this through secondary coverage and search extracts only, not the SOCRadar report; figures and the date range differ slightly between outlets.
Analysis. The reported facts are less dramatic than ‘AI ransomware’ and more useful. Operators approved each step, so this is an assistant, not an autonomous attacker. When commercial models refused a request the operators did not switch models but reworded the request as an ‘authorized red team assessment’, which is a repeatable framing against any model’s refusal logic (ATLAS: jailbreak / role framing). SOCRadar itself separates encryptor builds, which are preparation, from confirmed deployment. It is the same toolchain family as the Cairn campaign covered on 20 Oct, now seen from the operator’s side: agent frameworks on the attacker’s console, public bugs for entry. The cost line, a few tens of thousands of dollars across many sessions, is the point.
Why it matters. Defenders should plan for faster, cheaper tooling around the same initial-access bugs, not for new access techniques. The exposure of the operators’ own server is also a reminder that agent logs are intelligence: the same applies to your own agents’ transcripts.
Mitigation and detection. Patch and isolate the named edge products first (FortiClient EMS, SimpleHelp, cPanel, VPN gateways). Expect faster move times after access and tighten detection on credential use and archive or encryptor staging rather than on specific malware. If you operate a model API, log refusal-then-rephrase sequences from the same account as a signal.
Recommendation (opinion): do not change strategy, shorten timelines. Re-baseline your patch SLA for internet-facing remote-management software, and treat vendor claims of ‘autonomous’ attackers with the same scepticism as this one.
Sources: SOCRadar (not opened) · Hackread (not opened; quoted by search extract)
Policy and research
Nothing new that passes the test in this window. A CISA KEV search found no October entry for agentic software; secondary outlets report the latest AI-infrastructure KEV additions (a LiteLLM authentication flaw, among others) in early September, which I could not check against CISA. OWASP’s agentic resource page lists a 20 Oct entry whose contents I could not read, and I found no MITRE ATLAS change, EU AI Act agent guidance or INCIBE advisory dated in the window.
Sources: OWASP Top 10 for Agentic Applications · GitHub advisory database, MCP