LiteLLM 1.107.0 Shipped a Credential Stealer on PyPI. Here's What to Rotate (2026)

Quick answer: On October 21, 2026, LiteLLM's release pipeline got hijacked and a malicious litellm==1.107.0 landed on PyPI, Docker Hub and GHCR. All seven PyPI wheels carried a credential stealer (cook.py) that runs on every Python startup and a dormant remote-code loader (sitecustomize.py). PyPI pulled it by 13:23 UTC, roughly two hours after upload. If you installed it, assume your SSH keys, cloud IAM role, AI coding tool tokens and every provider key stored in your LiteLLM proxy are gone — pin to 1.106.2 and start rotating.

You're reading this on a startup directory's blog, not a security vendor's, so here's the honest framing up front: we're not LiteLLM's incident responders and we weren't in the room. What follows is built from LiteLLM's own report, the GitHub issue that broke the news, and three independent technical write-ups we actually read end to end. SaaSCity runs its own modest stack of API keys and provider integrations, same as any SaaS, which is exactly why an incident like this gets our full attention instead of a two-line summary.

Key Takeaways

• Two-hour window, full wheel set: All seven litellm==1.107.0 PyPI wheels, every supported platform, uploaded 11:39:51-11:40:13 UTC and removed by PyPI around 13:23 UTC.
• The payload runs on any Python start, not just LiteLLM imports: cook.pth triggers cook.py at interpreter startup — even a plain pip command in the same environment re-triggers it.
• It reads your AI coding tools too: Claude Code credentials, Codex auth, Gemini OAuth, Cursor's mcp.json — the stealer targets the exact tools most developers now run daily.
• A second, dormant stage exists: sitecustomize.py checks an hourly dead-drop for remote code to execute. It was empty at observation time but can be re-armed with one GitHub commit.
• The git tag and source tarball are clean: The malicious files only exist in the built wheels, so reading the repo tells you nothing.
• Root cause was credential logging, not a code flaw: LiteLLM says a GitHub CLI OAuth token that Claude Code embedded in a response body ended up in its own request logs, and that log sat on an internet-reachable internal deployment.
• This is LiteLLM's second hijacking in 2026: A March 2026 incident used a different unpinned-dependency path. JFrog says there's no evidence linking the two campaigns.

What actually happened on October 21

LiteLLM is the open source gateway that sits between an application and more than 100 LLM providers — Anthropic, OpenAI, Azure, Bedrock, the works. It's genuinely popular: roughly 23 million downloads a week, according to Socket's analysis. Most AI SaaS products that route model traffic through anything other than a single provider's raw SDK are routing it through LiteLLM or something shaped exactly like it.

That popularity is what makes this incident sting. At 11:39:51 UTC, a compromised build pipeline uploaded seven malicious wheels — macOS x86_64 and arm64, manylinux aarch64 and x86_64, musllinux aarch64 and x86_64, and win_amd64 — covering every platform LiteLLM ships for. By 11:46:56, matching Docker images had landed on Docker Hub and GHCR under the tags v1.107.0, latest, main-latest and main-stable, all pointing at the same compromised image digest, sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.

PyPI pulled 1.107.0 around 13:23 UTC. GHCR tags went dark by 13:51, Docker Hub by 14:20. Total exposure window on PyPI: roughly an hour and forty minutes. On Docker: closer to two and a half hours. Anyone who ran docker pull litellm/litellm:latest in that stretch, or had a CI job auto-bumping to the newest version, got the payload without doing anything unusual.

Milestone	Time (UTC, Oct 21)
Branch protection overridden	10:08:34
Staging build from lookalike repo	10:46:39
Production pipeline starts	11:08:53
Wheels uploaded to PyPI	11:39:51-11:40:13
Docker images published	11:46:56
GitHub release page published	11:50:24
Workflow logs deleted	11:53
PyPI removes 1.107.0	~13:23
GHCR tags unavailable	~13:51
Docker Hub tags clean	~14:20

Here's the detail that makes the official git tag useless for checking yourself: the malicious files aren't in the repository at all. According to the GitHub issue that broke the story, filed by Upwind's research team, the tagged source tree at 66c8f5b1a9cefaa7c55b758f86f4ab552f2e859e is clean. The source tarball on PyPI is clean too. One line was added to the sdist's pyproject.toml — data = "cook" under [tool.maturin] — that quietly tells the Rust-based build tool to fold a cook/ directory into the wheel during compilation. That directory doesn't exist in any tagged commit. Someone modified the build tree after checkout, before the wheels were built, and nobody who only reads the repo would ever see it.

The payload: three files, one of which never stops running

Three files land in the root of site-packages, outside the normal litellm/ package folder, which is itself a tell — legitimate packages don't scatter files at that level.

cook.pth is twelve bytes: import cook. Python auto-processes any .pth file it finds in site-packages at interpreter startup, no import statement from your code required. This is the mechanism that makes the whole thing nasty. It's not "import litellm and get owned." It's "start Python in that virtual environment, for any reason, and get owned." Run pip list to check what's installed. Congratulations, you just ran the stealer again.

cook.py, about 22 KB, zlib-compressed and base64-wrapped, calls itself privcollect internally. It spins up in a background thread and works through roughly sixteen collection modules: SSH keys and shell history; AWS, Azure, gcloud, kube, Docker, gh and .netrc credentials; browser-saved passwords and cookies from Chromium and Firefox; .git-credentials, .npmrc, .pypirc, and language-specific credential files for Maven, Gradle, Cargo, Gem and Composer; .env files and any *.pem/*.key/*.pfx; CI secrets for GitLab runners, Jenkins, Vault, Terraform and Packer; the Kubernetes service account token and anything under /run/secrets; and — this is the part that should worry anyone doing AI-assisted development in 2026 — credential files for Claude Code (~/.claude/.credentials.json), Codex (~/.codex/auth.json), Gemini's OAuth tokens, Cursor's mcp.json, plus GitHub Copilot, Windsurf, Kiro, Zed, Continue, OpenCode and Hugging Face tokens.

It also reads /proc/*/environ for every process it can see, which means it's not limited to its own environment variables. And if DATABASE_URL is set — which it is, on basically every real LiteLLM proxy deployment — it queries the LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable directly. That's every upstream provider key the gateway was ever configured to hold, in one database dump.

Everything gets AES-256-CBC encrypted, the key RSA-4096-OAEP wrapped, packaged as a tar.gz, and POSTed to http://www.litellm.dev/healthcheck. Notice the domain. The real project lives at litellm.ai. litellm.dev was registered October 13, 2026, eight days before the attack, specifically to look plausible in a log line. A success marker file, /tmp/.pc_once_72129118c59f5636c0bb, only gets written after the upload returns HTTP 200 — but its absence proves nothing, since container restarts and tmp cleanup wipe it just as easily as a failed upload would.

sitecustomize.py, roughly 25 KB, is the second stage. Python also auto-imports sitecustomize at startup if one exists on the path, same mechanism, same guarantee of execution. It forks a detached daemon, holds a lock at /tmp/remote_code_loader.lock, and every hour fetches https://raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt. If that file names a domain, it hits <domain>/codepy and executes whatever comes back. At the time researchers checked, the file was empty — so this stage was dormant, not disarmed. One commit to that GitHub file and it's live again. The GitHub account letters9813 was created October 13, 2026, same week as the lookalike domain. On Windows, the fork step fails silently, but cook.py still runs fine there.

How a hardened pipeline got hijacked anyway

This is the part that should worry you more than the malware itself. LiteLLM had already been burned once — a March 2026 incident, documented separately by JFrog's research team, traced to an unpinned Trivy 0.69.4 dependency that exposed CI credentials and let attackers ship backdoored 1.82.7 and 1.82.8 releases. After that, LiteLLM moved to a private release repo, Trusted GitHub Publishers, immutable Docker tags and signed images. Real hardening, not theater.

The Monday before this incident, LiteLLM temporarily widened release permissions so two internal engineers could push daily bugfix backports — a normal, bounded operational decision. The attacker had GitHub CLI OAuth credentials for three LiteLLM developers. One belonged to a GitHub organization owner and was used at 10:08 UTC to disable branch protections and force-push a workflow change. A second satisfied the production approval gate at 11:11. A third deleted the production and staging workflow records at 11:53, which is why nobody can fully reconstruct the build logs after the fact. The pipeline itself was pointed at Berri-AI/litellm — one hyphen different from the real BerriAI/litellm — and Docker's build provenance recorded that lookalike repo as the source without anyone flagging it.

Where did three developers' gh tokens come from? LiteLLM's own report says their internal deployment was reachable from the public internet, and its logs held the tokens. The mechanism, per their own disclosure and discussed on the resulting Hacker News thread: Claude Code, in some situations, embeds a user's GitHub CLI OAuth token inside a response body. When that response gets logged — which is a completely ordinary thing to do for debugging an AI gateway — the token lands in plaintext in your own logs. LiteLLM suspects initial entry through a since-patched vulnerability in that exposed deployment.

Credit where it's due: LiteLLM's public incident report names its own CEO, CTO, director of security and lead Rust engineer, posts a minute-by-minute timeline, and commits to two-hour status updates. That's not the move of a team trying to bury a bad week. The failure here wasn't silence. It was architecture — specifically, logging AI agent traffic turned a routine debugging habit into a credential leak, and a credential leak turned into a supply-chain compromise with real teeth.

What is actually clean

If you're staring at a lockfile wondering what's safe to pin, here's the full confirmed-clean list from LiteLLM and the independent researchers who checked wheel contents directly, not just version numbers.

Package	Clean versions
litellm	1.103.6, 1.103.7, 1.104.4, 1.104.5, 1.105.2, 1.105.3, 1.106.0, 1.106.1, 1.106.2, 1.107.0rc1, 1.107.0rc2
litellm-proxy-extras	0.4.108, 0.4.109, 0.4.110
litellm-enterprise	0.1.69.post2, 0.1.73.post1, 0.1.76.post1

LiteLLM's own recommendation is to pin 1.106.2. Enterprise customers on the private registry weren't touched by this at all — that registry is currently carrying an embargoed fix for an unrelated vulnerability, scheduled for disclosure October 27, which is a separate matter entirely and not part of this incident.

The rotation checklist, in the right order

Do not run pip first. Any Python start in an affected environment re-triggers cook.pth, including the pip command you'd use to fix the problem.

Step	Action
1	Do not run pip, python, or anything in the affected venv/container yet.
2	Manually delete cook.pth, cook.py, sitecustomize.py and matching __pycache__ entries from every affected site-packages directory.
3	Kill the detached python process holding /tmp/remote_code_loader.lock.
4	Rebuild the image or venv from scratch, pinned to litellm==1.106.2 or a reviewed digest. Don't patch in place.
5	If the host had outbound internet access while 1.107.0 was installed, assume exfiltration happened. A missing marker file proves nothing.
6	Rotate the instance or task IAM role.
7	Rotate every provider key stored in the LiteLLM proxy database, plus master and virtual keys.
8	Rotate the DATABASE_URL password and any other secret present in any process environment on that host.
9	Check CloudTrail for GetCallerIdentity calls around install time, since the stealer validates stolen AWS credentials that way before exfiltrating them.

A provider key with no spend limit is a credit card with no limit. A cloud IAM role is the whole account. One .pth file in one container handed over the model budget, the database, the CI tokens and the deploy keys, all at once, to a process that started the moment someone ran pip list.

The structural fixes worth making regardless

Beyond this specific incident, a few habits generalize to any dependency you pull into a system that holds secrets:

• Pin digests, not floating tags. latest and main-stable are exactly the tags that got silently repointed at a compromised image for two and a half hours.
• Treat your AI gateway as a secrets system, not a routing utility. It holds every provider key you've ever given it, often unencrypted in a database row.
• Keep provider keys in a vault the gateway reads at runtime instead of storing them in the gateway's own database.
• Allowlist egress so a POST to an unfamiliar domain fails closed instead of succeeding quietly.
• Verify wheel RECORD contents and startup hooks before trusting a package that ships compiled Rust bridges or anything with build-time code generation.
• Never let CLI OAuth tokens land in request logs. If your AI coding assistant embeds tokens in response bodies, logging those bodies is logging credentials, full stop.

If you're a founder shipping an AI product and wondering what you should actually publish about your own security posture, this incident is a decent template: name the people responsible, give exact timestamps, say precisely what was and wasn't affected, and commit to a cadence of updates instead of one vague statement. That kind of transparency is also exactly what buyers go looking for before they connect your product to their provider keys — it's a big part of why a listing page, not just a marketing site, is often where someone checks you out first. We built SaaSCity as a gamified startup directory with a live city map and human editorial review for that reason: every founder gets a free listing page and a building on the map, and adding the SaaSCity badge to your site earns a dofollow backlink plus a Monday launch slot. Quick Pass ($19.99) goes live within 24 hours, Premium ($39.99) adds a written launch post with three dofollow links, and the domain sits at DR 66 as of our last Ahrefs check in October 2026. None of that replaces a real incident response plan, but a product people can actually find and vet tends to be a product people trust with their keys.

This is also a good moment to remember LiteLLM isn't the only recent reminder that your dependency tree is an attack surface, not a shopping list — see the zod npm supply chain attack for a different flavor of the same lesson, and the Supabase exposed-database incident for what happens when the thing holding your data is misconfigured instead of backdoored.

The thought worth sitting with

Nobody in this story was lazy. LiteLLM hardened its pipeline after March, named names in its report, and shipped updates every two hours while still mid-incident. The thing that broke wasn't effort. It was the assumption that a gateway holding every provider key you own is just infrastructure, logged the same casual way as everything else. If your AI stack's most privileged component is also the one nobody's threat-modeled this year, October 21 is the reminder to go fix that before someone else finds the gap for you.