On October 21, 2026, a malicious version of LiteLLM (1.107.0) was published to PyPI. LiteLLM is a widely used open-source proxy that connects applications to more than 100 LLM providers.
The compromised release contained an infostealer designed to exfiltrate credentials and a remote access trojan (RAT) capable of downloading and executing additional code. Stolen AWS credentials were reportedly abused within hours of the initial exfiltration.
The malicious PyPI package was quarantined, and compromised Docker tags were removed. The latest reported safe version is 1.106.2.
Organizations that installed or executed the compromised release should treat affected systems as potentially compromised and begin incident response immediately.
How the LiteLLM Supply Chain Attack Happened
The attack originated from a lookalike GitHub repository, Berri-AI/litellm, which was used to introduce malicious files and modify the release pipeline.
The attacker reportedly compromised three engineers’ GitHub accounts using stolen GitHub CLI OAuth tokens. These accounts were used to trigger and approve a release, allowing the malicious version to reach PyPI and Docker registries.
Changes to pyproject.toml and Dockerfiles helped package and execute the malicious payload. The LiteLLM team subsequently revoked the compromised tokens.
What Data Was Stolen?
The infostealer targeted a broad range of sensitive information, including:
- Cloud credentials: AWS, GCP, and Azure tokens and keys.
- AI provider secrets: API keys for OpenAI, Anthropic, Cohere, and other LLM services.
- Developer credentials: GitHub tokens, SSH and GPG keys, package manager credentials, and developer tool secrets.
- Browser data: Saved passwords, cookies, and browsing history.
- Infrastructure secrets: Kubernetes tokens, Docker credentials, CI/CD secrets, and Vault tokens.
- LiteLLM database records: Configured provider credentials and proxy model information.
The stolen data was encrypted before being exfiltrated to www.litellm[.]dev/healthcheck, a lookalike domain impersonating LiteLLM infrastructure.
Post-Exploitation Activity
A separate payload, delivered through sitecustomize.py, attempted to contact a GitHub-hosted dead-drop repository every hour. If supplied with a usable command-and-control domain, it could retrieve and execute additional Python code.
Although no second-stage payload was observed during the initial analysis, the capability remained on infected systems.
The incident also progressed beyond credential theft. On October 21, suspicious AWS activity was observed from 168.100.8[.]57 and 165.227.201[.]8, including credential validation, Amazon Bedrock model enumeration, and IAM discovery. These activities are consistent with attempts to abuse stolen cloud credentials for unauthorized LLM usage and further reconnaissance.
Indicators of Compromise (IOCs)
Security teams should investigate the following indicators alongside their endpoint, network, and cloud audit logs:
- Malicious package:
litellm==1.107.0 - Suspicious domain:
www.litellm[.]dev - RAT dead-drop URL:
raw.githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt - Persistence lock file
: /tmp/remote_code_loader.lock - Stealer sentinel file:
/tmp/.pc_once_72129118c59f5636c0bb - Suspicious source IPs: 1
68.100.8[.]57, 165.227.201[.]8 - Environment variable:
PRIVCOLLECT_ACTIVE=1
These indicators may change or become inactive. Their absence does not prove that a system is clean.
How to Respond to the LiteLLM Compromise
Organizations that installed or executed the malicious release should:
- Upgrade to a verified safe version: Pin LiteLLM to 1.106.2 or another release explicitly confirmed safe by the maintainers.
- Rotate exposed credentials: Replace cloud keys, LLM API keys, GitHub tokens, SSH keys, database credentials, and other secrets accessible to affected hosts.
- Investigate cloud activity: Review AWS CloudTrail for unexpected
sts:GetCallerIdentity,bedrock:ListFoundationModels, and IAM enumeration calls. - Contain affected systems: Isolate compromised hosts and rebuild them from trusted images rather than relying solely on deleting malicious files.
- Inspect CI/CD pipelines: Review GitHub audit logs, release approvals, OAuth token usage, and container image provenance.
- Check downstream deployments: Identify affected containers, Kubernetes workloads, developer machines, and CI runners.
Simply upgrading the package is not sufficient if the malicious code has already executed and exposed credentials.
How Astra Helps Reduce Supply Chain Risk
Supply chain attacks demonstrate how a single compromised dependency can expose cloud infrastructure, developer environments, customer data, and production workloads.
At Astra Security, we recommend combining regular penetration testing, dependency security reviews, and continuous vulnerability management to identify weaknesses before attackers can exploit them.
Regular penetration testing can help uncover excessive permissions, exposed secrets, weak network boundaries, vulnerable APIs, and gaps in incident detection. These weaknesses can turn a compromised dependency into a much larger security incident.
To reduce the blast radius of future compromises, organizations should also enforce least-privilege access, isolate CI/CD environments, use short-lived credentials, maintain strong secret-management practices, and monitor unusual cloud API activity.
A compromised dependency should not automatically mean a compromised organization. Regular security testing and effective containment controls help limit what an attacker can access, how far they can move, and how much damage they can cause.
Astra helps organizations identify exploitable weaknesses through security assessments and penetration testing, strengthening their defenses against supply chain attacks and other emerging threats.
