LiteLLM 1.107.0 was poisoned on PyPI, and the token that opened the door came out of a coding agent's logs
A malicious LiteLLM 1.107.0 sat on PyPI from 11:39 to 13:23 UTC on October 21, and the Docker Hub and GHCR tags like latest and main-stable were compromised from 11:46 to 14:20 UTC. The project says the most recent safe version is 1.106.2. If anything in your stack pulled LiteLLM or its container images in that window, treat the machine as exposed and rotate every key it could read: cloud, CI, LLM provider keys, and agent credentials. Incident page: https://docs.litellm.ai/blog/security-incident-oct-21-2026
The release was a credential stealer, and the target list reads like a map of the agent ecosystem. SafeDep's analysis says it ran at every Python start, even in programs that never import litellm, and went after tokens for Claude Code, Claude Desktop, Cursor, Windsurf, Copilot, Gemini CLI, Codex and opencode, MCP config files, and the provider keys stored in a LiteLLM proxy database. Wiz says the code shows strong signs of LLM-aided development. The upstream GitHub source was clean; the bad wheels came out of the release pipeline itself.
The root cause is the part every agent team should read twice. LiteLLM's maintainers wrote that they had seen specific situations where Claude Code embeds a user's GitHub CLI OAuth token in a response body, and when response bodies are logged, those tokens can land in LiteLLM logs. An internal LiteLLM deployment exposed to the internet had an innocuously named account nobody expected. The attacker pulled tokens from those logs and used one account to change the release pipeline and another to approve it. Two-person release control, defeated by two leaked tokens. No Anthropic response to the claim was found by press time. Root-cause thread: https://github.com/BerriAI/litellm/issues/47826
The gateway is the box every harness sits behind, which makes it the best place to collect everyone's secrets. Logging full request and response bodies felt like good observability until the bodies started carrying credentials. Agent teams now need a redaction step between the agent and the log as standard practice, and LiteLLM has already flagged a separate embargoed fix due for disclosure on October 27.
← Back to all articles
The release was a credential stealer, and the target list reads like a map of the agent ecosystem. SafeDep's analysis says it ran at every Python start, even in programs that never import litellm, and went after tokens for Claude Code, Claude Desktop, Cursor, Windsurf, Copilot, Gemini CLI, Codex and opencode, MCP config files, and the provider keys stored in a LiteLLM proxy database. Wiz says the code shows strong signs of LLM-aided development. The upstream GitHub source was clean; the bad wheels came out of the release pipeline itself.
The root cause is the part every agent team should read twice. LiteLLM's maintainers wrote that they had seen specific situations where Claude Code embeds a user's GitHub CLI OAuth token in a response body, and when response bodies are logged, those tokens can land in LiteLLM logs. An internal LiteLLM deployment exposed to the internet had an innocuously named account nobody expected. The attacker pulled tokens from those logs and used one account to change the release pipeline and another to approve it. Two-person release control, defeated by two leaked tokens. No Anthropic response to the claim was found by press time. Root-cause thread: https://github.com/BerriAI/litellm/issues/47826
The gateway is the box every harness sits behind, which makes it the best place to collect everyone's secrets. Logging full request and response bodies felt like good observability until the bodies started carrying credentials. Agent teams now need a redaction step between the agent and the log as standard practice, and LiteLLM has already flagged a separate embargoed fix due for disclosure on October 27.
Comments