LiteLLM’s release pipeline was compromised on October 21, 2026, allowing an attacker to publish a malicious version of the AI gateway software through PyPI, Docker Hub and GitHub Container Registry.
The affected release, LiteLLM v1.107.0, harvested credentials and other secrets from systems where it ran, according to findings from Aikido and Wiz relayed by The Hacker News. Wiz subsequently observed attempts to validate stolen AWS credentials from compromised CI runners and Kubernetes nodes.
LiteLLM disclosed the incident in a Wednesday advisory. The company placed the intrusion at around 4:00 a.m. PST on October 21, 2026.
Which packages and container tags were affected
The compromised artifacts included:
- PyPI package LiteLLM v1.107.0
- Docker/GHCR tag v1.107.0
- Docker/GHCR tag latest
- Docker/GHCR tag main-latest
- Docker/GHCR tag main-stable
For PyPI, the reported exposure window covers users who installed an unpinned LiteLLM package with pip between 11:39 a.m. and 1:23 p.m. UTC.
The container exposure window ran from 11:46 a.m. to 2:20 p.m. UTC for users who pulled or otherwise used the listed image tags. Because several mutable tags were involved, checking only a deployment’s configured tag may not establish which image actually ran; defenders should verify the exact artifact or image used.
Stolen GitHub tokens enabled a poisoned release
According to LiteLLM’s account, the attacker had access to three sets of developer GitHub CLI credentials. One set could trigger GitHub workflows, while a token belonging to an organization owner was used to turn off branch protections and force-push malicious changes.
The compromised workflow was redirected from the legitimate BerriAI/litellm repository to a lookalike named Berri-AI/litellm. That substitution caused the resulting malicious packages and images to pass through the project’s signing and publishing process.
Two days earlier, on October 19, 2026, LiteLLM had temporarily expanded release permissions for two internal engineers tasked with issuing daily bug-fix backports for customers.
The company suspects the GitHub tokens may have been exposed through logs from an internet-accessible internal deployment where it found an unexpected, innocuously named account. LiteLLM said Claude Code can place a user’s GitHub CLI OAuth token inside a response body; if those bodies are recorded, the token can consequently appear in LiteLLM logs. The company presented this as a suspected route rather than an established initial entry point.
LiteLLM said it had introduced additional release protections after a separate incident in March 2026, including moving releases to a private repository, making Docker release tags immutable and signing container images. In the October compromise, the attacker was nevertheless able to manipulate the workflow responsible for producing and publishing signed artifacts.
The malware collected secrets and maintained an hourly backdoor
Aikido and Wiz described two Python execution mechanisms embedded in the compromised release.
The first used cook.pth, which imported a Python module named cook. Its corresponding cook.py script deobfuscated itself and launched a credential-stealing routine called privcollect.
The stealer targeted secrets associated with:
- Operating systems
- Web browsers
- Development tools
- Cloud environments
- AI tools
Collected information was sent through an HTTP POST request to:
litellm[.]dev/healthcheck
On Linux and macOS, a second component named sitecustomize.py attempted to retrieve domain.txt from a GitHub dead drop associated with github[.]com/letters9813. A valid response supplied the address from which the malware could download and execute a second-stage Python script at <domain>/codepy.
The component also forked a background process, created the lock file /tmp/remote_code_loader.lock, and entered a loop that checked the dead drop every hour before attempting to run the remote payload again. Aikido characterized this mechanism as a remote access trojan.
Wiz said GitHub removed the dead-drop text file at around 1:30 p.m. UTC. Before its removal, the file reportedly contained only initial test values.
AWS credentials were tested hours after exfiltration
Wiz reported that abuse began approximately 4.5 hours after credential exfiltration. Between 4:20 p.m. and 5:01 p.m. UTC on October 21, 2026, the attacker tested AWS instance-role credentials obtained from CI runners and Kubernetes nodes.
Each credential was checked with:
sts:GetCallerIdentitybedrock:ListFoundationModels- A
ListModelscall
Wiz assessed that activity as consistent with LLMjacking, in which stolen cloud credentials are tested for access to hosted AI services. In a small number of environments, the attacker also performed IAM and infrastructure discovery using operations such as ListRoles, ListUsers, ListAccessKeys, ListAccounts and DescribeTrails.
The credential-validation traffic was associated with:
168.100.8[.]57
165.227.201[.]8
Although the use of a .pth file resembles the March 2026 attack attributed in the reporting to TeamPCP, Socket found no public evidence establishing that the two incidents shared an operator. Socket noted differences in the embedded RSA public keys, exfiltration code and backdoor behavior. It also said the available evidence does not establish whether credentials stolen in March contributed to the October compromise.
What LiteLLM users should do now
Organizations that installed or ran LiteLLM 1.107.0, including through the affected container tags, should treat the host and credentials accessible to that process as potentially compromised.
Recommended actions include:
- Remove LiteLLM 1.107.0 from machines and deployment environments.
- Isolate affected hosts while investigating what the package accessed.
- Search for:
cook.pthcook.pysitecustomize.py/tmp/remote_code_loader.lock
- Block and investigate connections to:
litellm[.]dev/healthcheckgithub[.]com/letters9813raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt
- Investigate any attempted or successful execution of
/codepy. - Review AWS logs for activity involving the reported IP addresses and API calls.
- Rotate every credential reachable from an affected environment, including cloud, developer, browser and AI-service secrets.
- Rebuild affected systems from trusted artifacts rather than relying only on removal of the malicious files.
JFrog researcher Guy Korolevski also advised organizations to confirm the exact wheel installed and to vet package versions before they enter build systems. Where 1.107.0 executed, JFrog’s recommendation is to rotate all credentials it could reach and rebuild the affected environment.
