LiteLLM 1.107.0 PyPI Release Injected with Infostealer and RAT

Key Takeaways

• The LiteLLM 1.107.0 PyPI package was compromised on October 21, 2026, injecting an infostealer and a remote access trojan.
• Affected systems include developer machines, build runners, and AI services, with malicious code distributed via all seven wheel files and Docker images.
• The malware targets a wide range of sensitive data, including SSH keys, AWS, Google Cloud, Azure credentials, browser passwords, and tokens for AI tools like Claude and GitHub Copilot.
• PyPI has removed the malicious version, but installed instances remain compromised, and stolen credentials are still at risk.
• Defenders must isolate affected systems, revoke all potentially exposed credentials, and rebuild environments from trusted sources.

On October 21, 2026, the popular LiteLLM library, specifically version 1.107.0, was found to be compromised on the Python Package Index (PyPI). This malicious release effectively injected an advanced infostealer and a remote access trojan (RAT) across all seven of its distributed wheel files. The threat extended beyond PyPI, impacting Docker images and consequently endangering developer systems, build runners, and critical AI services.

Security firm Aikido issued a stern warning, advising that any entity which installed the affected release should operate under the assumption that their credentials have been exposed. While PyPI promptly removed version 1.107.0, this action does not mitigate malware already present on systems or invalidate any secrets that attackers may have exfiltrated.

Socket’s investigation revealed that its scanning mechanisms detected all seven malicious wheel files within seven minutes of their publication. This rapid detection underscores the critical importance of speed in identifying supply chain attacks, as automated dependency updates can quickly propagate a poisoned release across numerous environments before human intervention is possible.

How the LiteLLM Malware Operates

The attack leverages Python startup hooks, a sophisticated method that allows the malicious code to execute independently of whether an application explicitly imports LiteLLM. According to Wiz’s technical analysis, the installation process places three critical files—cook.pth, cook.py, and sitecustomize.py—directly into Python’s site-packages directory.

Initial Payload Execution and Data Exfiltration

Upon any Python environment startup, cook.pth initiates cook.py. This script then decodes its embedded malicious code, triggering a comprehensive credential theft routine. This design ensures that even an unrelated Python command can activate the payload post-installation, irrespective of whether the user directly interacts with LiteLLM.

The infostealer is designed to harvest a broad spectrum of sensitive information. This includes system details, browser data, developer secrets, cloud credentials, and authentication files for AI tools. Specifically, targets encompass SSH private keys, AWS, Google Cloud, and Azure credentials, stored browser passwords, and tokens for prominent AI services such as Claude and GitHub Copilot.

Exfiltrated data is encrypted and transmitted via an HTTP POST request to www[.]litellm[.]dev/healthcheck. Wiz identified this destination as attacker-controlled infrastructure, meticulously crafted to mimic legitimate LiteLLM endpoints. Additionally, the stealer attempts to write a unique marker at /tmp/.pc_once_72129118c59f5636c0bb, though this path may encounter issues on Windows systems.

Remote Access Trojan Mechanism

A separate startup file, sitecustomize.py, establishes the remote code loading capability for Linux and macOS environments. This file attempts to retrieve domain.txt from the GitHub repository letters9813/pythonclient-test. The address obtained from this file is then used to download and execute an additional Python script from a /codepy endpoint.

This mechanism provides attackers with a persistent backdoor, enabling them to execute further arbitrary code whenever an affected Python environment restarts. However, Wiz reported that during their analysis, domain.txt was not populated, and the repository was subsequently taken down. This suggests that while the capability for a RAT was present, confirmed active exploitation via this specific channel was not observed at the time of their investigation.

Container Compromise and Supply Chain Concerns

Organizations utilizing containers must also conduct thorough investigations. Wiz identified compromised LiteLLM images on both GitHub Container Registry and Docker Hub, including versions tagged v1.107.0, latest, main-latest, and main-stable. This highlights that relying solely on familiar image tags is insufficient to guarantee a clean deployment.

Public discussions surrounding the incident have also pointed to build records referencing Berri-AI/litellm, a lookalike repository that differs from the legitimate BerriAI/litellm project by a single hyphen. While this finding raises serious questions about the robustness of release source validation, it does not fully establish the complete intrusion path or the identity of the attackers.

This incident marks the second reported supply chain compromise for LiteLLM this year. Previous reports detailed a supply chain attack involving versions 1.82.7 and 1.82.8, which led to investigations into exposed cloud keys and CI/CD secrets. While these earlier findings do not definitively link to the current incident, they underscore how even brief exposure to malicious packages can create long-term security challenges. Removing a compromised release limits new downloads, but comprehensive recovery requires identifying all affected systems, neutralizing backdoors, and revoking stolen access.

What You Should Do

• Isolate Affected Systems: Immediately quarantine any hosts, build runners, or container environments that installed LiteLLM version 1.107.0. Preserve all relevant logs for forensic analysis.
• Assume Compromise: Treat all credentials and secrets accessible from affected systems as potentially stolen. This includes SSH private keys, AWS, Google Cloud, and Azure credentials, browser passwords, and tokens for AI services like Claude and GitHub Copilot.
• Revoke and Rotate Credentials: From a clean, uncompromised system, revoke and rotate all potentially exposed cloud keys, SSH keys, browser sessions, repository tokens, and AI service credentials.
• Thorough Investigation: Conduct a comprehensive investigation covering package installation records, container deployments, Python startup files (especially cook.pth, cook.py, and sitecustomize.py), and outbound network connections to www[.]litellm[.]dev/healthcheck.
• Rebuild Environments: Do not attempt to simply replace the LiteLLM package. Rebuild affected environments entirely from trusted, verified sources.
• Pin Dependencies: For container deployments, pin to verified image digests rather than relying on mutable tags like latest.
• Monitor for Post-Compromise Activity: Review cloud and source control logs for any unexpected access or activity that may have occurred after the installation of the compromised package.
• Use Safe Versions: Wiz identified 1.106.2 as the most recent safe version prior to the compromise. Ensure all LiteLLM installations are either this version or a verified clean subsequent release.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.