A compromised LiteLLM release distributed credential-stealing malware and a remote access mechanism through Python packages and container images on October 21. Version 1.107.0 on PyPI contained malicious code in all seven wheel files, exposing developer workstations, CI runners and AI services that installed or automatically upgraded to the release.

PyPI has removed the package, but deletion from the registry does not clean systems that already installed it or revoke credentials the malware may have collected. Security firm Aikido advises users of the affected version to assume accessible secrets were exposed. Socket reported detecting the seven poisoned wheels seven minutes after publication, illustrating how quickly automated dependency workflows can spread a malicious update.

Python startup hooks trigger the payload

The malware does not wait for an application to import LiteLLM. Analysis by Wiz found that installation writes cook.pth, cook.py and sitecustomize.py into Python’s site-packages directory. Python processes startup files automatically, so running an unrelated Python command in the compromised environment can activate the payload.

The cook.pth file imports cook.py, which decodes hidden code and launches the information stealer. Reported collection targets include system data, browser passwords, SSH private keys, cloud credentials for AWS, Google Cloud and Azure, and authentication material associated with developer and AI tools such as GitHub Copilot and Claude.

Stolen information is encrypted and sent by HTTP POST to a domain designed to resemble legitimate LiteLLM infrastructure. The stealer also writes a marker file under /tmp to avoid repeating part of its work, although that path may fail on Windows. Defenders should not rely on the marker alone because it may be deleted, blocked or changed.

A second component supports remote code loading

The installed sitecustomize.py creates an additional execution path on Linux and macOS. It attempts to retrieve a domain from a GitHub repository and then download and run another Python script from a /codepy endpoint. This design could allow an operator to add new capabilities after the initial compromise.

During Wiz’s analysis, the remote domain file had not been populated and the repository was later removed. That distinction matters: the backdoor had the capability to retrieve further code, but available reporting does not establish that every infected system received a second-stage payload.

Container users are also affected. Investigators identified compromised LiteLLM images on GitHub Container Registry and Docker Hub, including tags such as v1.107.0, latest, main-latest and main-stable. Re-pulling a familiar moving tag is therefore not a reliable remediation strategy unless its digest and provenance are verified.

Containment must include credential rotation

• Isolate workstations, runners and services that installed LiteLLM 1.107.0 or affected images.
• Preserve package logs, container metadata and network telemetry before rebuilding.
• Search site-packages for the reported startup files and review Python process activity.
• Rotate cloud keys, SSH keys, repository tokens, browser sessions and AI provider credentials from a clean system.
• Review cloud, source-control and identity logs for suspicious access following installation.

Replacing the package without revoking secrets leaves the most durable part of the compromise intact. An attacker who obtained a cloud key or repository token can return through the external service even after the malicious Python environment has been deleted. Teams should also look for new credentials, modified policies, unfamiliar applications and persistence created with the stolen access.

Wiz identified 1.106.2 as the most recent safe version in its analysis. Affected environments should be rebuilt from trusted sources rather than cleaned in place, and container deployments should be pinned to reviewed digests. CI systems deserve particular scrutiny because they often hold broad credentials and can propagate compromised artifacts downstream.

This is the second reported LiteLLM supply-chain incident this year, following problems involving versions 1.82.7 and 1.82.8. The recurrence reinforces basic dependency controls: require review for sensitive upgrades, retain software bills of materials, monitor package provenance and prevent build jobs from receiving more secrets than necessary. Fast registry removal limits new infections, but recovery depends on finding every installed copy and invalidating every credential it could read.