In the early hours of October 21, 2026, attackers hijacked the release pipeline of LiteLLM, the hugely popular open-source Python SDK and AI gateway that sits in front of OpenAI, Anthropic, Azure and dozens of other model providers, and pushed a poisoned version 1.107.0 to PyPI, Docker Hub and GitHub Container Registry. The malicious wheels were live for roughly two hours, and the container tags latest, main-latest and main-stable pointed at the tainted image for up to about 2.5 hours, long enough for any unpinned build or auto-pulling deployment to grab a credential stealer with a remote code loader attached. With BleepingComputer citing 92 million monthly PyPI downloads and users such as NVIDIA, Netflix, AT&T and Okta, this is one of the most consequential AI supply-chain incidents of the year. Here’s what happened, how to tell if you were hit, and why it matters for every team running AI infrastructure.
The Attack: A Lookalike Repo and Stolen GitHub Tokens
According to LiteLLM’s own incident post, signed by CEO Krrish Dholakia, CTO Ishaan Jaffer and Director of Security Oliver Jensen, the project had meaningfully hardened its release process after a prior compromise in March, moving releases to a private repo, using Trusted Publishers, making Docker tags immutable and signing images. The attacker still got through by chaining several weaknesses:
- Stolen credentials: The attacker held three sets of developer GitHub CLI OAuth tokens, including one belonging to one of the project’s two GitHub organization owners.
- Branch protection override: GitHub branch protection rejected the malicious workflow change at 10:08 UTC, but five seconds later the owner-level token was used to override those protections and force the change in.
- Typosquatted source: The modified workflow built artifacts from Berri-AI/litellm, a lookalike of the real BerriAI/litellm repository differing by a single hyphen, then signed and published them through the legitimate pipeline.
- Covering tracks: A third developer credential was used to delete the production and staging workflow records, limiting the logs available to investigators.
LiteLLM believes the tokens came from its own internal LiteLLM deployment, which was exposed to the internet and contained an unexpected, innocuously named user account. The team says it has observed specific situations in which Claude Code can embed a user’s GitHub CLI OAuth token in a response body, and where response bodies are logged, those tokens may land in LiteLLM logs. The exact initial access route is still unconfirmed, though the team suspects a recently patched vulnerability.
The Payload: Malware That Fires Every Time Python Starts
The clever (and nasty) part is that LiteLLM’s application code was never touched. Researchers at Endor Labs found that a single line added to the build configuration dropped three files, cook.pth, cook.py and sitecustomize.py, into the Python library directory. As Socket researchers explained, “During normal startup, Python processes executable .pth lines and then attempts to import sitecustomize.” That means the stealer runs on any Python launch in the environment, whether or not the app imports LiteLLM, and even when a responder runs pip to investigate.
Socket’s AI scanner flagged the seven malicious wheels within about seven minutes of publication. Per BleepingComputer, Endor Labs and Socket, the malware hunts for:
- Cloud and deployment secrets: AWS, Azure, Google Cloud, Kubernetes and Docker credentials.
- AI provider keys: A dedicated module queries LiteLLM’s own credentials and model tables, so a compromised proxy can leak every provider key it manages.
- Developer secrets: Git, GitHub, npm, PyPI and CI/CD tokens, .env files, and SSH, GPG and TLS keys.
- Browser and host data: Saved logins, cookies, autofill data, environment variables and shell histories.
Stolen data is encrypted with AES-256-CBC wrapped in an RSA-4096 key and shipped to an attacker domain, while sitecustomize.py launches a detached loader that checks a GitHub-hosted pointer every hour for fresh Python code to execute.
Are You Affected? Check These Windows
LiteLLM says you should assume compromise if you used an unpinned install between 11:39 and 13:23 UTC (7:39 to 9:23 AM ET) on October 21, or ran the Docker or GHCR images v1.107.0, latest, main-latest or main-stable between 11:46 and 14:20 UTC (7:46 to 10:20 AM ET). Endor Labs stresses that a deployment pulling latest or main-stable could have received the malicious image without anyone choosing 1.107.0. Customers on the private enterprise registry were not affected, and the official 1.107.0 source tag on GitHub is clean, which means reviewing the tagged source would not reveal the attack.
Cleanup: Don’t Start With pip
LiteLLM’s remediation guidance, credited to researcher Lidor Machluf, is blunt: any Python start in an affected environment re-runs the malware. The recommended order of operations:
- Remove the hooks from the shell: Delete cook.pth, cook.py, sitecustomize.py and matching cached .pyc files from every affected site-packages directory without launching Python.
- Kill the loader: Terminate the detached Python daemon holding /tmp/remote_code_loader.lock.
- Rebuild, don’t patch: Pin to litellm==1.106.2, the last clean release, and preferably rebuild images and virtual environments from scratch.
- Assume exfiltration: If the host had outbound internet access, treat secrets as stolen and rotate the instance IAM role, every provider key in the proxy database, master and virtual keys, the database password and any secret in the process environment.
- Hunt in the cloud: Check CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of that role’s credentials from outside your infrastructure.
Why It Matters for IT Pros
AI gateways are becoming the new crown jewels. A single LiteLLM proxy can hold API keys for every model provider an organization pays for, alongside cloud identities and database strings, making it a one-stop shop for attackers. This incident also shows that signed images and trusted publishing are not enough on their own when privileged developer tokens leak. For MSPs and internal IT teams supporting developers, the lessons are concrete: pin versions and image digests instead of floating tags like latest, keep internal AI tooling off the public internet, scrub tokens from logs, and treat owner-level GitHub credentials with the same care as domain admin.
Looking Ahead
LiteLLM says its investigation is ongoing and that it is distributing an embargoed fix to enterprise customers for a separate vulnerability with a disclosure date scheduled for October 27, so expect another LiteLLM advisory early next week. Security teams should watch for updated indicators of compromise from LiteLLM, Socket and Endor Labs as the post-mortem fills in.
More broadly, this is the second time in 2026 that LiteLLM’s release process has been abused, and it lands in a week already crowded with developer-platform breaches. As AI middleware spreads through enterprise stacks, expect supply-chain attackers to keep targeting the tools that hold the keys, and expect auditors to start asking pointed questions about how AI gateways are deployed, logged and secured.
Sources:
- LiteLLM, October 21, 2026
- Endor Labs, October 21, 2026
- Socket, October 21, 2026
- BleepingComputer, October 22, 2026
- The Hacker News, October 22, 2026
