Two tampered versions of LiteLLM, a widely adopted Python library, were uploaded to the official Python Package Index (PyPI) by a malicious actor. Before being taken down, the corrupted packages were downloaded roughly 47,000 times in under an hour.

LiteLLM serves as a unified interface layer allowing developers to connect with multiple AI providers through a single API — making its broad user base a high-value target.

How It Was Found

Security researcher Callum McMahon stumbled upon the issue after his system crashed and began spawning uncontrolled processes. Tracing the problem back to a cached dependency, he notified both PyPI and the LiteLLM team. PyPI moved quickly to quarantine the offending packages.

The two affected versions — 1.82.7 and 1.82.8 — were live for roughly five hours starting at 10:39 UTC.

What the Malicious Packages Did

The attacker appears to have gained direct PyPI publishing access, most likely through a compromised maintainer account, bypassing normal release controls entirely.

Once installed, the payload quietly collected sensitive data including environment variables, SSH keys, cloud provider credentials (AWS, GCP, Azure), Kubernetes service tokens, and database secrets — all of which were sent to an attacker-controlled server at models.litellm.cloud, unrelated to the real LiteLLM project.

Only developers using unpinned dependencies were at risk. Those with locked versions or explicit version pins were unaffected. The LiteLLM Cloud service and its official Docker image were not touched.

The Root Cause: A Compromised Trivy Pipeline

The LiteLLM incident traces back to an earlier attack on Trivy, Aqua Security’s open-source vulnerability scanner.

On March 19, a threat group known as TeamPCP exploited leftover credentials from a previous, incompletely patched Trivy breach. They used this foothold to tamper with GitHub Actions workflows, redirecting version references within automated pipelines to point at attacker-controlled artifacts. Any CI/CD system pulling from those references unknowingly ran malicious code — which in turn harvested credentials believed to have been used to access LiteLLM’s release pipeline.

Broader Damage

Beyond credential theft, the malicious packages also planted tools enabling lateral movement inside Kubernetes clusters and persistent backdoor access — giving attackers ongoing visibility into containerized infrastructure.

Palo Alto Networks, which investigated the Trivy campaign, described it as among the most sophisticated supply chain attacks ever directed at a security tool. The operation wove together credential theft, version poisoning, binary tampering, persistence, and self-propagating behavior that spread into adjacent ecosystems including npm.

Response and Recommendations

The LiteLLM maintainers responded by halting new releases, rotating all credentials, rebuilding their trusted maintainer group, and bringing in Mandiant to audit the build pipeline.

The broader lesson, as McMahon noted, comes down to fundamentals: pin your dependencies, use lock files with cryptographic verification, and treat every package update as something that needs to be reviewed before it reaches production.

The Bigger Picture

This incident is a clear illustration of transitive supply chain risk — where a single upstream compromise ripples outward into entirely separate projects. Rather than attacking end users directly, the threat actors targeted the infrastructure used to build and distribute software itself.

For security teams, the takeaway is straightforward: CI/CD pipelines, package registries, and dependency workflows deserve the same level of hardening and monitoring as any production system.


cybersecurity researcherFileDNA and ObtainDNA approach file security from the inside out. Where traditional antivirus tools scan for known signatures and move on, these platforms take a deeper approach — dissecting each file’s internal structure, stripping out concealed threats, and reconstructing a clean version before it ever reaches its destination.
Files enter organizations through countless channels: inboxes, shared storage, data pipelines, third-party transfers. Each one is a potential vehicle for hidden malware, embedded payloads, or weaponized metadata. FileDNA and ObtainDNA treat every file as untrusted by default, subjecting it to thorough analysis and sanitization regardless of where it came from.
The end result is not just detection — it’s delivery of verified, threat-free files that slot seamlessly into existing workflows. No disruption, no friction. Just a quiet but formidable barrier between incoming content and the systems that depend on it.