LiteLLM 1.107.0 supply-chain attack threatens AI credentials
News date: 2026-10-21 · Sources reviewed: 2026-10-23
On October 21, 2026, the LiteLLM team reported a compromise of its software release pipeline. A malicious version 1.107.0 was briefly distributed through PyPI and Docker registries, carrying credential-stealing functionality and remote-code loading capabilities. This was a software supply-chain incident rather than an ordinary LLM configuration issue.
What exactly was impacted?
The official incident report identifies PyPI wheels for litellm==1.107.0 available from approximately 11:39 to 13:23 UTC on October 21. Docker tags 1.107.0, latest, main-latest and main-stable also pointed to malicious images during a defined interval. Affected artifacts have been removed or repointed; the private enterprise distribution was reported as unaffected.
- Check the image digest or package actually executed, not only the currently displayed tag.
- Treat environments that ran affected artifacts as potentially compromised.
- Do not assume all historic LiteLLM releases or deployments were affected.
Why this threatens more than an AI application
AI gateways often hold LLM provider API keys, database passwords and cloud service identities. Malicious code running in that context may collect secrets for later misuse, even after the initially compromised container is replaced.
- Inventory LLM provider keys as well as proxy master and virtual keys.
- Review cloud roles, connection strings and environment variables.
- Identify all other systems reachable by the affected workload.
Isolate and investigate before reinstalling
The vendor warns that launching Python inside an affected environment can re-trigger malicious startup hooks. Incident responders should plan isolation, evidence capture and a clean rebuild. Running a routine pip update inside an untrusted environment is not a safe first step.
- Pause automated deployments using mutable container tags.
- Record image digests, timestamps and actual installations.
- Rotate exposed credentials in a controlled sequence after scoping exposure.
Lessons for private and hybrid LLM platforms
A private AI deployment is not intrinsically secure merely because it runs in a company-controlled environment. Dependency pinning, artifact verification, network segmentation, secrets management and CI/CD access controls remain essential.
- Use version pinning and immutable image digests.
- Apply least privilege to secrets and service identities.
- Separate development workloads from sensitive production data.
VALUE360: Private AI design should include dependency, secrets and pipeline security, not only a choice of language model.
Explore the related VALUE360 service →
Sources
- LiteLLM — Security incident notice
- Datadog Security Labs — LiteLLM compromise analysis
- JFrog Security Research — LiteLLM investigation
Remediation prioritization
Prioritize by actual exposure, affected software versions, privileges and signs of compromise—not headline severity alone. Confirm affected releases and mitigations against the vendor advisory.
Implementation questions
Does this automatically affect our environment?
No. First verify whether the specific product, version and relevant configuration are deployed.
Is a security tool enough on its own?
No. Combine patching, restricted access, logging and tested backups.