LiteLLM Supply Chain Attack Steals Credentials via Malicious .pth File

Major Supply Chain Attack Hits Popular LiteLLM Python Package

The Python ecosystem is reeling from a sophisticated supply chain attack targeting LiteLLM, a popular open-source library for standardizing calls to various large language models. On March 24, 2026, security researchers discovered that versions 1.82.8 and 1.82.7 published on the Python Package Index (PyPI) contained a malicious file designed to steal sensitive credentials automatically upon any Python interpreter startup.

This incident underscores the escalating threat to open-source software infrastructure, where a single compromised package can lead to widespread credential theft across development, CI/CD, and production environments. The attack's stealth and automated execution mechanism make it particularly dangerous.

The Attack Vector: A Malicious .pth File

The core of the attack was a file named litellm_init.pth, included in the litellm-1.82.8-py3-none-any.whl wheel on PyPI. Python's .pth files, placed in a site-packages directory, are executed automatically by the Python interpreter at startup. This means the malicious code ran without requiring an explicit import litellm statement.

The file contained a double base64-encoded payload. When decoded, it launched a subprocess that executed a comprehensive credential-stealing script. Researchers confirmed that version 1.82.7 was also compromised, with the malicious code hidden within proxy/proxy_server.py instead of a .pth file.

Scope and Scale of Data Theft

The malware was designed to cast a wide net, systematically harvesting a staggering array of sensitive information from the infected system. The script operated in two main stages.

The first stage involved aggressive information collection. It gathered system data like hostname, user identity, network configuration, and all environment variables—a primary target for API keys and secrets. It then targeted credential stores across the entire development and infrastructure stack.

• Cloud & Infrastructure: AWS, Google Cloud, Azure, Docker, and Kubernetes configuration files and service account tokens.
• Developer Tools: SSH keys, Git credentials, and shell history files (bash, zsh).
• Databases & Services: PostgreSQL, MySQL, Redis, and LDAP config files.
• Financial Data: Private keys for cryptocurrency wallets including Bitcoin, Ethereum, and Solana.
• Miscellaneous Secrets: SSL/TLS private keys, CI/CD configuration files (like .gitlab-ci.yml), and webhook URLs.

Sophisticated Exfiltration and Attribution

Following collection, the malware moved to stage two: encryption and exfiltration. The stolen data was written to a temporary file, encrypted using a randomly generated AES-256 session key, and then that key was itself encrypted using a hardcoded 4096-bit RSA public key.

The final encrypted archive, tpcp.tar.gz, was sent via a HTTP POST request to https://models.litellm.cloud/. Security analysts noted the domain litellm.cloud is a lookalike, not the official litellm.ai domain. The attack has been attributed to a cloud-focused cybercriminal operation known as TeamPCP.

This group is suspected in a parallel, large-scale campaign dubbed "GlassWorm," which has compromised over 400 code repositories across GitHub, npm, and VSCode extensions. Their modus operandi involves using stolen credentials to publish malware that then compromises more accounts in a self-spreading worm-like fashion.

Broader Supply Chain Context and TTPs

The LiteLLM incident is not isolated. It follows a similar pattern observed in attacks against other tools like the Trivy vulnerability scanner, where compromised npm accounts were used to publish backdoored versions. In those cases, attackers employed a stealthy "tag manipulation" technique, force-pushing existing version tags to point to malicious commits instead of creating new releases, thereby bypassing notification systems.

As one security researcher quoted in the sources stated, "This is the point where the attack goes from 'compromised account publishes malware' to 'malware compromises more accounts and publishes itself.'" This creates a dangerous, automated propagation cycle where every infected developer or CI/CD pipeline with accessible publishing tokens becomes an unwitting attack vector.

Immediate Response and Mitigation

The discovery triggered an urgent community response. Major downstream projects like MLflow quickly moved to pin their LiteLLM dependency to version 1.82.6 or earlier to mitigate the threat. The primary recommendations for affected users are severe, reflecting the breadth of the potential damage.

First, all systems that installed the compromised versions must be scanned for the presence of the litellm_init.pth file and the malicious code in proxy_server.py. Second, and most critically, organizations must assume all credentials present on those systems are compromised.

This necessitates a full rotation of API keys, cloud access tokens, SSH keys, database passwords, and any other secrets that were stored as environment variables or in the config files listed by the malware. The maintainers of LiteLLM must also urgently audit their PyPI publishing credentials and CI/CD pipeline for signs of compromise.

Long-Term Implications for Open Source Security

This attack highlights fundamental challenges in open-source security that cannot be easily patched. As discussed in analyses of Model Context Protocol (MCP) security, LLMs and automated systems struggle to distinguish between trusted instructions and malicious content injected into tool metadata. This creates persistent risks in increasingly automated development environments.

The incident serves as a stark reminder of the trust placed in package repositories and the catastrophic impact of a breach. It reinforces the need for robust software supply chain security practices, including diligent dependency pinning, automated scanning for suspicious package behaviors, and a zero-trust approach to credential management on developer workstations and build servers.