As reported by BleepingComputer, the LiteLLM project suffered a supply-chain compromise on October 21, 2026, when threat actors hijacked its release pipeline to distribute credential-stealing malware through PyPI package version 1.107.0 and multiple Docker image tags. The malicious artifacts were live for roughly 1.5 to 3 hours before being pulled, but given LiteLLM's 92 million monthly PyPI downloads, the exposure window is significant.
Why This Matters: AI Infrastructure Is a High-Value Target
LiteLLM occupies a strategically valuable position in the modern AI stack — it sits between applications and multiple LLM provider APIs, handling authentication tokens, API keys, and routing configuration. Any compromise at this layer gives attackers a concentrated collection point for credentials across an organization's entire AI provider portfolio. This is not a generic npm/PyPI typosquatting incident; it is a pipeline-level compromise of a widely trusted, 61,800-star project used by NVIDIA, Netflix, AT&T, and Okta.
The attack technique itself is worth noting for its elegance. Rather than modifying LiteLLM's source code — which would have been caught by integrity checks — the attackers injected three files (cook.pth, cook.py, and sitecustomize.py) into the Python library directory at package install time. Python's .pth processing and automatic sitecustomize import execute before any application code runs, meaning the malware activated on every Python launch in the environment. Even defenders investigating suspected compromise would trigger the payload by running pip or Python itself.
What Was Compromised and When
| Artifact | Version/Tag | Exposure Window (UTC) |
|---|---|---|
| PyPI wheels (all 7) | litellm==1.107.0 | Oct 21, 11:39:51 – 13:23 |
| Docker Hub | v1.107.0, latest, main-latest, main-stable | Oct 21, 11:46:56 – 14:20 |
| GHCR (litellm) | v1.107.0, latest, main-latest, main-stable | Oct 21, 11:46:56 – 13:51 |
| GHCR (litellm-database) | v1.107.0, latest, main-latest, main-stable | Oct 21, 11:46:56 – 13:51 |
| GHCR (litellm-non_root) | v1.107.0, latest, main-latest, main-stable | Oct 21, 11:46:56 – 13:51 |
The compromised Docker image index hash is sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Organizations that pulled any of these tags during the exposure window should assume compromise.
What the Malware Targeted
The payload was purpose-built for AI infrastructure environments, exfiltrating:
The targeting of AI-specific credential stores alongside standard cloud secrets suggests the attackers understood LiteLLM's role as an API gateway and deliberately designed the payload to harvest the highest-value material in that environment.
Broader Implications
This incident highlights several systemic issues in open-source AI tooling supply chains:
- Pipeline security is the new perimeter. The attacker did not exploit a code vulnerability — they compromised the CI/CD release process itself. Build pipeline access controls, secrets management, and release signing are now front-line security concerns.
- AI infrastructure components are prime targets. As organizations centralize AI provider access through gateways like LiteLLM, these tools become single points of credential concentration. Compromising one gateway can yield credentials spanning OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and more.
- Python's
.pth/sitecustomizeexecution path remains underappreciated. This is a known technique but defenders rarely monitor for it. Package integrity scanning should flag unexpected.pthandsitecustomize.pyinsertions. - Detection was fast — containment was not instant. Security firms like Socket and Endor Labs detected the malicious package within six minutes, yet the artifacts remained available for over an hour. Automated response integration between detection tools and package registries needs improvement.
Shield53 Recommendations
Immediate Actions
- Identify exposed systems: Check CI/CD logs, container registries, and deployment histories for any pull of litellm==1.107.0 from PyPI or the listed Docker tags/SHA digests during the exposure window. Pin to version 1.106.x or earlier or the patched release once available.
- Rotate all credentials on affected hosts: Assume full compromise of cloud provider credentials, AI API keys, Kubernetes secrets, and any environment variables. Rotate AWS access keys, Azure service principals, GCP service account keys, and all LLM provider API keys that may have been stored in LiteLLM configuration.
- Do NOT run Python or pip on suspected hosts for investigation. The
sitecustomizepayload executes on every Python launch. Use static analysis, container image scanning, or examine the filesystem from a separate environment. - Check for indicator files: Look for
cook.pth,cook.py, and unexpectedsitecustomize.pyin Python's site-packages or library directories. - Review cloud audit logs: Look for anomalous API calls, new IAM users/roles, or unexpected token usage from the exposure window onward. Attackers with cloud credentials often establish persistence within hours.
Longer-Term Hardening
- Pin package versions in all dependency manifests and container builds. Avoid
latesttags in production — this incident demonstrates exactly why. - Implement package provenance verification. Use Sigstore/cosign for container image signing and PyPI package signing where available. Reject unsigned or unverified artifacts.
- Adopt secrets scanning at runtime. Tools that detect credential exfiltration patterns in process network traffic could have caught this payload communicating outbound.
- Network-segment AI gateway infrastructure. LiteLLM instances should run in restricted network zones with egress allowlisting. The exfiltration payload required outbound network access — strict egress controls would have limited or blocked data theft.
- Audit CI/CD pipeline access. Review who has release-publishing permissions, enforce MFA on pipeline service accounts, and implement break-glass procedures with audit logging for all release operations.
This attack is a blueprint for future AI supply-chain compromises. As the ecosystem matures around gateway and orchestration tools, expect more threat actors to target the infrastructure layer rather than individual models or applications. The organizations that treat AI supply chain security with the same rigor as traditional software supply chain will be the ones that avoid the next incident.