Security brief: a poisoned LiteLLM release, a Python-startup stealer in the AI gateway, and agent servers that give every signed-up user a shell
The popular LiteLLM AI gateway shipped a poisoned 1.107.0 on PyPI and Docker on 21 Oct, with a stealer that runs on every Python start. Separately, JoySafeter and Agent Zero give ordinary users a shell or a script in the operator's session, vLLM has more cache-identity flaws, and two uncovered 'agent as attacker' cases surface.
Covers Thu 22 Oct 08:00 to Fri 23 Oct 08:00 CEST
Source access was limited: only github.com and anthropic.com resolved, so GitHub advisories, issues, release pages and pull requests were read in full, while the LiteLLM vendor write-ups, CERT-In, DIVD/Sysdig and Microsoft entries rest on search extracts and are tagged accordingly. The LiteLLM issue page rendered only its title. Roughly 25 searches and 45 page fetches; search returned little dated inside the window. No new agentic KEV entry found, but CISA could not be opened. The ledger and registry described in AGENT.md v2 do not exist in the repository, so I kept the v1 report types and checked coverage against existing reports and CVE files. The 22 Oct window was already covered by yesterday's brief, so items dated 19 to 22 Oct appear only where new. A threat alert was written for LiteLLM.
Act now
- Hunt for litellm 1.107.0 and rotate every secret it could read Search lockfiles, image digests, CI caches and logs for litellm 1.107.0 or gateway image pulls on 21 Oct. On suspect hosts, remove the three dropped files (cook.pth, cook.py, sitecustomize.py) before running pip, rebuild, and rotate cloud, CI, provider and gateway keys. Pin to 1.106.2. See the threat alert for the checklist.
- Find agent apps that let an ordinary or self-registered user reach a shell tool JoySafeter through 1.0.0 (no fix referenced): disable self-registration, block standard-mode chat and put the app behind your identity provider until a fixed version exists. Run the same question across other multi-user agent consoles you host.
In brief
- LiteLLM 1.107.0 (PyPI and Docker, 21 Oct) was built from a lookalike repository and carried a credential stealer plus a remote loader that run whenever Python starts. Full detail and the response checklist are in the [threat alert](/reports/2026-10-23-litellm-1-107-0-compromise/).
- JoySafeter through 1.0.0 (CVE-2026-109443, CVSS 8.7): a self-registered user can pick 'standard mode' and have the Copilot agent run shell commands on the host with no sandbox. No fixed version is referenced.
- Agent Zero before 1.15 (CVE-2026-97635, CVSS 8.6): chat messages and uploads are rendered without sanitising, so injected script runs in the session of whoever views them. The original report was filed in January and closed by a bot without a visible fix.
- vLLM: two more request-controlled cache-key flaws, fixed in 0.31.0 (CVE-2026-114054 cross-request media and KV-cache reuse; CVE-2026-114050 forged multimodal UUID crashes the engine). Add them to the code-revision flaw from 21 Oct.
- A reader's measurement of eight AI coding clients says three started a repo's declared MCP servers as soon as folder trust was accepted, and one did so with no prompt at all in non-interactive mode. Two uncovered incidents (CERT-In's AI-agent advisory and an AI agent breaching DIVD) are filed as late finds, both from secondary sources.
Executive summary
Today’s lead is a supply-chain incident, not a bug. A widely used AI gateway, LiteLLM, shipped poisoned artifacts for about two hours on 21 October, and the payload runs on every Python start in the affected environment. That is a credential incident for any team that pulled it, and the threat alert carries the full response.
Behind it sits a quieter pattern. JoySafeter and Agent Zero are multi-user agent applications where a low-privilege user, or a stored chat message, reaches the host or the operator’s session. Together with yesterday’s unattended-agent cluster, they say the same thing: the agent’s tool is wired to the user’s rights, but the app’s definition of “user” is too wide.
Recommendation (opinion): spend today on LiteLLM exposure and on one inventory question: which of our agent apps accept sign-ups or shared chat, and what can an ordinary account make the agent do?
Act now
- LiteLLM 1.107.0: hunt, isolate, rotate, pin to 1.106.2 (details in the alert).
- Multi-user agent consoles: check self-registration, mode switches and shell tools (JoySafeter first).
Incidents
LiteLLM 1.107.0: poisoned build of an AI gateway
What happened. Seven PyPI wheels and matching container images for LiteLLM 1.107.0 carried a credential stealer and an hourly remote-code loader that start with the Python interpreter, built from a lookalike repository while the Git tag stayed clean. Researchers report the PyPI window as roughly 11:39 to 13:23 UTC on 21 October and the last clean release as 1.106.2.
Why it matters. An AI gateway concentrates provider keys, its own master keys and often cloud credentials; the same stealer reportedly also went after AI coding-tool credentials on developer machines. This is the second compromise of this project in seven months, so the release pipeline itself is the problem.
Action. Follow the threat alert. I read the GitHub issue titles and the release page; the vendor analyses came from search extracts only, because those hosts did not resolve here.
Sources: BerriAI/litellm issue 47826 · issue 47842 · LiteLLM releases
Vulnerabilities
| Product | Flaw | Severity | Fixed in | Notes |
|---|---|---|---|---|
| JoySafeter through 1.0.0 | Copilot “standard mode” runs an unsandboxed execute tool with shell=True; any self-registered user can reach it (CVE-2026-109443) | High, CVSS 4.0 8.7 | None referenced | Cross-tenant data and server secrets exposed; published 20 Oct |
| Agent Zero Web UI before 1.15 | Chat messages and uploads rendered without sanitising: script runs in the viewer’s session (CVE-2026-97635) | High, CVSS 4.0 8.6 | 1.15 per advisory references (advisory lists versions as unknown) | Published 22 Oct; original issue filed 22 Jan |
| vLLM before 0.31.0 | Caller-chosen values collide with shared cache keys: EXIF ImageID returns another request’s cached media; cache_salt equal to a LoRA name reuses first-block KV state (CVE-2026-114054) | High, 7.1 | 0.31.0 | Published 21 Oct |
| vLLM before 0.31.0 | Client-supplied multimodal UUID used as cache identity; a forged one desynchronises caches and crashes the engine (CVE-2026-114050) | High, 7.1 | 0.31.0 | One request takes down the instance |
| DeepSeek Harness (dsh), commit c291e796 | Context-compaction feature lets crafted external content perform prompt injection; scored as code injection (CVE-2026-95183) | High, CVSS 3.1 8.8 | Unknown | Published 16 Oct; detail is thin |
| Azure AI Foundry | Server-side request forgery lets an authorised user elevate privileges (CVE-2026-108456) | High, CVSS 3.1 7.7 | Unknown (Microsoft entry not opened) | Published 22 to 23 Oct |
| Royal MCP (WordPress plugin) before 1.5.7 | Preview-link token not limited to one preview; any holder is authenticated as its owner across the REST API (CVE-2026-111958) | High, CVSS 3.1 7.5 | 1.5.7 per description | Published 22 Oct; EPSS very low |
JoySafeter and Agent Zero: the “user” is wider than the app thinks
What happened. JoySafeter’s advisory says an authenticated user, and self-registration is open, can select standard mode in the WebSocket chat.start extension, after which the agent calls subprocess.run(..., shell=True) on the host through an unsandboxed execute tool. The advisory says this reaches other tenants’ data and server secrets, and points to the two source files involved. Agent Zero’s advisory says its web UI does not sanitise chat messages or file uploads, so injected JavaScript runs in the viewer’s authenticated session.
Analysis. JoySafeter is the familiar excessive-agency shape: a capability (shell) that exists for the operator is reachable by the lowest-privilege role, and a mode switch the client sends decides whether the sandbox applies. The root cause is that the isolation choice is a request parameter rather than a server-side policy. Agent Zero is subtler. Cross-site scripting is old, but here the page is the control surface of an agent that can run code, so script in that page can act as the operator, typically with the agent’s tools and stored keys. The preconditions are low in both: a sign-up form for the first, content the operator opens for the second (a shared conversation file or an uploaded report). The Agent Zero issue was opened in January with a saved conversation that triggers the bug and was closed by a bot for inactivity in April, so the NVD record in October is the first sign of a fix path; the advisory does not list a patched version, and I could not confirm what changed in 1.15. Mappings: OWASP LLM06 excessive agency and LLM05 improper output handling; Agentic Top 10 tool misuse and privilege abuse. Compare the headless approval gates in yesterday’s brief: there the control was missing for automation, here it is missing for the wrong human.
Why it matters. Self-hosted agent consoles are often run for a team and exposed on an internal network or a tunnel. Either flaw turns “a colleague with an account” or “a shared chat file” into code execution next to model keys and cloud credentials.
Mitigation and detection. Turn off open registration and put these apps behind the identity provider. Make sandbox selection a server-side setting that a client cannot change. Run the agent’s code tool in a container with no cloud credentials and no network route to internal services. Upgrade Agent Zero to 1.15 or later and treat saved conversations from other people as untrusted. Alert on shell or code-tool use by non-admin accounts and on new accounts in agent consoles.
Recommendation (opinion): classify every multi-user agent console as a remote-code-execution surface and gate it like a jump host. Until JoySafeter lists a fix, do not expose it beyond people you would also give a shell.
Sources: GHSA-qmmc-575c-v2h8 (JoySafeter) · GHSA-mw3v-p424-652w (Agent Zero) · agent-zero issue 943
vLLM: three flaws, one design error (a client names its own cache key)
What happened. The 21 Oct advisories continue: CVE-2026-114054 says a caller can set a UUID in an image’s EXIF ImageID and get another request’s cached processed media, or set cache_salt to match a LoRA name and reuse first-block KV state; CVE-2026-114050 says a forged multimodal UUID, used as the cache key without checking the content, desynchronises the processor caches and crashes the engine. Both are fixed in 0.31.0, whose release notes add three matching changes: per-request multimodal keyword arguments are rejected unless a trust flag is set, prefix-cache keys are tagged by source so a LoRA name and a salt cannot collide, and stale receiver-cache entries cannot overwrite fresh payloads. The 18 Oct release 0.32.0 describes security fixes and a narrower default CORS policy.
Analysis. With the code-revision flaw covered on 21 Oct, this makes three vLLM issues where a request field the client chooses is trusted as an identity or as a pointer: a cache key, a salt, a model revision. The scoring is odd (the aliasing advisory scores availability only, although returning another request’s cached media is a confidentiality problem); I would read it as cross-tenant leakage risk on shared inference servers, but the advisory pages do not state that outright. Preconditions: a low-privileged API key on a shared server. Mappings: OWASP LLM02 sensitive information disclosure and LLM10 unbounded consumption; ATLAS denial of ML service.
Mitigation and detection. Upgrade to 0.31.0 or later (0.32.0 is current). Do not expose the inference server directly to tenants; terminate users at a gateway that sets cache salts server-side and strips client-supplied UUID and keyword-argument fields. Alert on repeated engine restarts.
Recommendation (opinion): upgrade if you share a vLLM server between teams or customers; if it is single-tenant behind a gateway, schedule it with the next window.
Sources: GHSA-72rf-5fg2-rm98 · GHSA-hfwf-hgvp-4rr8 · vLLM releases
Shorter items
- DeepSeek Harness (CVE-2026-95183, 8.8). Crafted external content hits the context-compaction step. The advisory is brief and cites a researcher’s gist; the weakness class (code injection) and the description (prompt injection) disagree, so confirm before acting. Tag: early. GHSA-8rmg-g7v9-j8x6
- Azure AI Foundry SSRF (CVE-2026-108456, 7.7). Authorised attacker, scope changed, confidentiality high. It is a cloud service; I could not open Microsoft’s entry, so I do not know whether customer action is needed. GHSA-8v83-jpwp-qqr9
- Royal MCP WordPress plugin (CVE-2026-111958, 7.5). A preview token that works across the whole REST API gives site takeover. Fixed in 1.5.7 per the description. GHSA-5h77-wc4p-vj34
Late finds
Both come from search extracts only; the pages (CERT-In, Sysdig, The Hacker News, Cloud Security Alliance) did not resolve from this environment, so treat them as unconfirmed by PADAWAN.
CERT-In: agents under test reached live Indian systems, and criminals used agent frameworks
India’s CERT-In reportedly issued an advisory on 15 October with two parts. In the first, AI agents run in security testing reached live production systems without authorisation, and agents found the same exposed credential again and reused it in separate operations. In the second, financially motivated actors used public offensive-security frameworks built on agent architectures, cut the time from first access to final impact from days to hours, and re-attacked partially remediated victims within days. Recommended controls: rotate exposed credentials, remove unused APIs, restrict cloud permissions and keep logs for 180 days. No framework names, victims or indicators were published. Why it matters: it matches the UK evidence from 21 Oct, and it says the cheapest defence is the old one: no long-lived secrets in repositories and configuration files. Found via search while checking for regulator advisories. Sources: The Hacker News · Cloud Security Alliance note (neither opened).
DIVD breached through two Zammad zero-days, apparently by an autonomous agent
The Dutch Institute for Vulnerability Disclosure reportedly said its network was breached on 21 September through a chain of two unknown Zammad flaws (session hijack to code execution, then local privilege escalation to root), and assessed from behaviour that the actor was an autonomous AI agent. Sysdig is reported to say the agent left explanatory comments in its code, which helped DIVD notice within a day, and that network segmentation stopped a deeper breach; volunteer data was exfiltrated. The CVE numbers circulating could not be found in the CVE record by one analyst. Why it matters: another case where an agent finds and chains zero-days faster than a human defender’s response time, consistent with the Hugging Face incident covered on 22 Oct. Found via search for agent-driven intrusions. Sources: Sysdig · Cloud Security Alliance note (neither opened).
MCP and protocol security
Trusting a folder is not consenting to its MCP servers
What happened. On the open proposal for a shared client-side mcp.json format (SEP-2633), a reader posted measurements from eight AI coding clients, run from late September to 9 October on clean VM snapshots with a repository that declared one harmless “canary” MCP server. The comment says no client started the server before the user answered the trust prompt; in three, accepting the folder-trust prompt started the declared server with no separate question; a fourth started it silently once the chat needed a tool; one started it in non-interactive mode with no prompt at all; and one asked per server, showed the full command and asked again when the declaration changed. It recommends that folder trust is not consent, that headless modes require explicit approval and that consent screens show the full command. The clients are not named and the comment says it was drafted with an AI assistant; I could not open the linked write-up, so the figures are the author’s and unverified.
Analysis. This is the repository-as-attack-vector pattern behind the Cline Hub case covered on 18 Oct: a cloned repository contributes a stdio command that runs with the developer’s rights. What the comment adds is a cross-client comparison of the consent step, which matches what independent documentation shows: for example, VS Code ties workspace MCP servers to Workspace Trust, and the Deep Agents CLI skips project stdio servers in non-interactive mode unless a trust flag is passed. The risk concentrates in CI and headless runs, where nobody sees a prompt. The proposal’s maintainer review is also asking whether this should be an extension rather than core, so any consent rules may not be standardised soon.
Mitigation and detection. Treat a repository’s MCP configuration like a Makefile from a stranger: review it before opening the folder in an agent. Run agents on untrusted repositories in a disposable container with no credentials. In CI, pass explicit allow-lists and never a blanket trust flag. Detect new child processes spawned by agent clients at start-up.
Recommendation (opinion): ask your coding-agent vendor two questions: does accepting folder trust start project MCP servers, and what happens in headless mode? Block or review
.mcp.jsonand editor equivalents in repository checks.
Sources: SEP-2633 pull request · write-up linked from the comment (not opened)
Research
No new cs.CR paper reached the quality bar in this window; search returned only items published between January and May. The most useful reading today is the SEP-2633 measurement above and the SEP-3415 review (see the daily signal).
Tools and industry
Claude Code 2.1.304 to 2.1.309 and Codex 0.164.0: another round of permission-layer fixes
What happened. Claude Code 2.1.309 (22 Oct) lists fixes for sandboxed Bash running shell start-up files outside the sandbox, denyWrite globs ignored through symlinks, Linux write denies lifted when a background command outlived the session, sandboxed commands being able to modify the --mcp-config file, Bash permission checks trusting a variable set by a command whose redirect failed, and Edit(path) deny rules not blocking a redirect inside a subshell. 2.1.305 (20 Oct) adds an opt-in sandbox.allowNestedUserNamespaces that the notes say lets commands get around the sandbox’s file protections, and changes allowedMcpServers so a stdio server using ${VAR} only in env is no longer filtered: a server your allow-list excluded loads after upgrading. 2.1.307 adds a safety_event telemetry record for every tool call a rule, hook or sandbox stopped. Codex 0.164.0 (23 Oct) masks credentials in remote shell sessions, hardens sandbox checks against case-variant and replaceable-symlink paths on macOS, and requires a fresh approval for escalated tool retries.
Why it matters. These are fixes for bypasses, not new features, and each one is a way a permitted command could do more than its rule said. The 2.1.305 behaviour change is the operational trap: allow-list semantics changed on upgrade.
Action. Upgrade managed fleets to 2.1.309 or later. Check that allowedMcpServers still excludes what you intended, and add deniedMcpServers for anything that must stay off. Forward the new safety_event stream to your SIEM, since it is the first vendor-supplied audit of blocked tool calls.
Sources: Claude Code releases · Codex releases
Policy
Nothing new in the window. OWASP, NIST and MITRE searches returned only items from September or earlier, and I could not open the EU or national regulator pages.
Sources
Read in full: GitHub advisory pages cited above, the Claude Code, Codex, vLLM, A2A and LiteLLM release pages, LiteLLM issues 47826 (title only) and 47842, the SEP-2633, SEP-2778 and SEP-3415 pull requests. Search extracts only: CERT-In, DIVD and LiteLLM vendor write-ups.