LiteLLM Open-Source LLM Gateway Distributes Credential-Stealing…

Two PyPI versions of the litellm package were compromised by malware that abuses Python .pth files to exfiltrate credentials to an attacker-controlled domain.

On March 24, 2026, two versions of the Python package litellm — a widely used open-source tool that serves as a universal gateway for LLM APIs — were published to PyPI from a compromised maintainer account. Versions 1.82.7 and 1.82.8 contain malware that activates automatically at Python interpreter startup, harvests credentials from local and cloud environments, and exfiltrates them to an attacker-controlled domain. The incident exposes a paradox of the modern supply chain: a security scanning tool became the vector that compromised the publishing pipeline itself.

Key Takeaways

PyPI versions 1.82.7 and 1.82.8 of litellm contain malware: the first injects a payload into proxy/proxy_server.py, the second exploits the 34,628-byte litellm_init.pth file for automatic execution without any import
The payload collects environment variables, SSH keys, AWS/GCP/Azure/Kubernetes credentials, crypto wallets, SSL keys, shell histories, and Slack/Discord webhooks, encrypting data with AES-256-CBC and a session key protected by a hardcoded RSA-4096 public key
Exfiltration targets the domain litellm.cloud, registered March 23, 2026 via Spaceship, Inc.: a name deliberately chosen to resemble the official litellm.ai domain
PyPI has quarantined the entire package, causing installation failures even for legitimate versions; the probable root cause is the compromise of Trivy, a security scanning tool, which exposed CI/CD publishing credentials

How the Attack Works: Abusing .pth Files

The malware in version 1.82.8 exploits a little-known but documented Python mechanism: .pth files (path configuration files). Placed in installed package directories, these files execute automatically at Python interpreter startup, without the user performing any explicit import.

The file litellm_init.pth, at 34,628 bytes, contains code that launches a Python subprocess with a doubly base64-encoded payload. The double encoding hides the content from static analysis tools and superficial filesystem audits. Once decoded, the script gathers sensitive data from the host environment and transmits it via HTTP to litellm.cloud with the header Content-Type: application/octet-stream.

Version 1.82.7, published a few hours earlier, uses a different vector: the payload is injected directly into proxy/proxy_server.py and triggers on module import, requiring an explicit interaction distinct from the silent execution of the .pth file.

"The litellm==1.82.8 wheel package on PyPI contains a malicious .pth file (litellm_init.pth, 34,628 bytes) that automatically executes a credential-stealing script every time the Python interpreter starts — no import litellm required." — Technical analysis, issue #24512

Account Hijack and the Compromised Publishing Pipeline

The PyPI account of maintainer krrishdholakia was hijacked by an actor identified as teampcp, according to the LiteLLM team. The malicious versions correspond to no tag in the official GitHub repository: the latest documented release is v1.82.6.dev1, while 1.82.7 and 1.82.8 were uploaded directly to PyPI by the attacker.

This discrepancy between source repository and published artifacts is a classic indicator of publishing-account compromise, not source-code compromise. The exfiltration domain litellm.cloud was registered on March 23, 2026, the day before the malicious versions were published, timing that suggests deliberate planning rather than opportunism.

The LiteLLM team has engaged Google's Mandiant group for forensic investigation, as stated publicly: "We've engaged Google's mandiant.security team, and are actively working on this with them."

The Trivy Paradox: When the Security Scanner Becomes the Vulnerability

The most significant technical finding is the identified root cause: the compromise of Trivy, Aqua Security's open-source tool for scanning vulnerabilities in containers and dependencies. Trivy typically runs in CI/CD pipelines before publishing; if compromised, it can expose distribution-repository credentials.

This creates a paradox of the modern supply chain: the tool tasked with ensuring software security becomes the point of failure that compromises its integrity. Security scanning tools have been mentioned in supply-chain incidents before, but the explicit documentation of this vector in the LiteLLM case confirms its operational relevance.

The dossier does not specify whether Trivy was the sole compromise vector or if other pipeline entry points were involved. The audit is ongoing and the team has indicated that versions prior to 1.82.7 should also be verified.

Immediate Actions

Priority steps for anyone who used the package during the incident window:

Verify installations: check whether litellm==1.82.7 or litellm==1.82.8 appear in lockfiles, pip caches, containers, or Docker images; the file litellm_init.pth with SHA256 hash ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg is a confirmed indicator of compromise
Rotate all exposed secrets: environment variables, AWS/GCP/Azure keys, Kubernetes credentials, SSH keys, service tokens, webhooks, and SSL keys present on systems where the package was installed or where the Python interpreter was started

Inspect CI/CD pipelines

Monitor for exfiltration: review network logs for connections to litellm.cloud over recent months, with particular attention to periods after March 24, 2026

PyPI Quarantine Impact and Recovery Limits

PyPI responded by quarantining the entire litellm package: all versions currently return a No matching distribution found error. This measure protects against accidental installation of compromised versions, but also breaks legitimate installations of prior versions, creating downstream impact for dependent projects.

The exact download count for the malicious versions before quarantine is not available in the sources. There is no confirmation that exfiltrated credentials have been used for unauthorized access, nor that the real identity of attacker teampcp has been attributed. The full outcome of the Mandiant investigation remains pending.

Why This Case Resets Python Supply-Chain Assumptions

The LiteLLM incident is not an isolated account compromise, but a case study in how overlapping security tools can generate unexpected vulnerabilities. The .pth mechanism has been known in the Python community for years, but its potential abuse in supply-chain scenarios remains underestimated in most build pipelines.

The boundary between official and malicious domain — litellm.ai versus litellm.cloud — is designed to deceive human operators and bypass automated pattern-matching checks. The AES-256 encryption with a session key protected by RSA-4096 indicates design oriented toward forensic resistance, not an improvised operation.

For organizations using LiteLLM as a production LLM gateway, the incident demands verification not only of their own perimeter, but of the complete publishing chain and the third-party tools embedded in CI/CD.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references

github.com