LiteLLM Compromised – Hackers Injected an Infostealer and RAT in the Latest 1.107.0 PyPI Release

LiteLLM version 1.107.0 was compromised on PyPI on October 21, 2026, spreading a credential stealer and a remote access trojan through all seven distributed wheel files. The malicious release also reached Docker images, putting developer systems, build runners, and AI services at risk.

Aikido warned that anyone who installed the affected release should assume credentials were exposed. PyPI removed version 1.107.0, but taking down the package does not remove malware already installed or invalidate secrets attackers may have stolen.

Socket’s investigation said its scanner flagged all seven wheels seven minutes after publication. Detection speed matters because automated dependency updates can pull a poisoned release into multiple environments before a human reviews the package change.

How the LiteLLM Malware Runs

The attack uses Python startup hooks rather than relying on an application to import LiteLLM. According to Wiz’s technical analysis, installation places three files, cook.pth, cook.py, and sitecustomize.py, directly inside Python’s site-packages directory.

When Python starts, cook.pth imports cook.py, which decodes its hidden code and starts the credential theft routine. This means an unrelated Python command can trigger the payload after installation, even when the user never opens LiteLLM directly.

The stealer searches for system information, browser data, developer secrets, cloud credentials, and authentication files used by AI tools. Reported targets include SSH private keys, AWS, Google Cloud, and Azure credentials, browser passwords, and tokens for tools such as Claude and GitHub Copilot.

Collected information is encrypted and sent through an HTTP POST request to www[.]litellm[.]dev/healthcheck. Wiz identifies the destination as attacker controlled and designed to resemble LiteLLM infrastructure. The stealer also writes a marker at /tmp/.pc_once_72129118c59f5636c0bb, although that path can fail on Windows.

A separate startup file, sitecustomize.py, provides the remote code loading path on Linux and macOS. It tries to retrieve domain.txt from the GitHub repository letters9813/pythonclient-test, then uses the returned address to download and execute another Python script from a /codepy endpoint.

This gives attackers a route to run additional code when affected Python environments start again. However, capability should not be confused with confirmed activity. Wiz reported that domain.txt had not been populated during its analysis and that the repository was subsequently taken down.

Container users also need to investigate. Wiz identified affected LiteLLM images on GitHub Container Registry and Docker Hub, including v1.107.0, latest, main-latest, and main-stable. A familiar image tag therefore does not establish that a deployment is clean.

The public incident discussion also points to build records naming Berri-AI/litellm, a lookalike repository that differs from the legitimate BerriAI/litellm project by one hyphen. That finding raises questions about release source validation, but does not establish the full intrusion path or attacker identity.

Teams that installed LiteLLM 1.107.0 should isolate affected hosts and runners, preserve relevant logs, and treat accessible secrets as potentially stolen. Investigations should cover package installation records, container deployments, Python startup files, and outbound connections to the reported collection endpoint.

Rotate and revoke exposed cloud keys, SSH keys, browser sessions, repository tokens, and AI service credentials from a clean system. Replacing only the LiteLLM package is not enough when stolen credentials can still provide access elsewhere.

Wiz identified 1.106.2 as the most recent safe version in its report. Rebuild affected environments from trusted sources and pin container deployments to verified image digests rather than relying on moving tags. Review cloud and source control logs for unexpected access after installation.

This is LiteLLM’s second reported supply chain compromise this year. Cyber Security News previously covered the LiteLLM supply chain attack involving versions 1.82.7 and 1.82.8 and the later investigation into exposed cloud keys and CI/CD secrets.

Those earlier findings do not prove the same attackers caused this incident. They show why brief package exposure can create a much longer security problem. Removing a malicious release limits new downloads, while recovery still depends on finding affected systems, removing startup backdoors, and cutting off stolen access.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post LiteLLM Compromised – Hackers Injected an Infostealer and RAT in the Latest 1.107.0 PyPI Release appeared first on Cyber Security News.