You were one pip install away from a breach. Chainguard customers weren’t.
The attack
On March 24, 2026, hackers compromised litellm, a popular AI library with ~97 million monthly downloads. They published two compromised versions directly to PyPI, which remained active in the registry for nearly three hours. The releases bypassed the dependency’s normal release cycle to ship 1.82.7 and 1.82.8, designed to exfiltrate developer secrets. Hidden inside these versions was a malicious .pth file (code that executes automatically on Python startup), turning a routine dependency install into a full system compromise. From there, the attack escalated quickly. The payload harvested sensitive data, including SSH keys, cloud credentials, .env files, Kubernetes configs, and shell history, encrypted it, and exfiltrated it to an attacker-controlled domain. It attempted lateral movement by accessing Kubernetes service account tokens, reading cluster secrets, and deploying privileged pods across nodes, while also establishing persistence locally.
Several known packages depend on or integrate litellm, including:
smolagents (Hugging Face)
The risk here is clear: a single transitive dependency relied on by millions of developers could expose all your most critical environment secrets.
The real problem
Open source's interconnectedness is both its greatest feature and its greatest weakness, making it a high-value target for supply chain attacks. This attack is a potential continuation from TeamPCP, the attackers who exploited Trivy, have been propagating CanisterWorm across npm over the last few days, and exploited Checkmarx’s KICS open source security tool.
Today’s development workflows rely heavily on open source and deeply nested dependency trees, where you don’t need to install something malicious directly to be impacted. To be exploited, you just need to implicitly trust third-party maintainers to adhere to your organization’s strict security standards. Attackers take advantage of this inherent trust. When maintainers are compromised, and new malicious releases can exfiltrate the keys to the kingdom for other open source libraries, the size of every attack balloons out of control.
Why Chainguard customers were protected
Chainguard Libraries are designed to eliminate this exact type of open source library supply chain risk. Instead of pulling pre-packaged artifacts directly from public registries at install time, Chainguard provides curated, cryptographically verified artifacts. Every package is built from source in an SLSA L3-compliant environment and includes signed provenance and SBOMs. You always know that what you are running matches its source code bit-for-bit because you know who made it, how it was built, and what’s inside.
In this case, because the malicious versions of litellm lacked publicly verifiable source code, Chainguard did not rebuild them. This means that Chainguard Libraries for Python customers never pulled it into their applications or projects, simply because these compromised versions didn’t exist.
In turn, you avoid the scramble. There’s no need to rotate keys or search for malware, because your team wasn’t exposed. While some organizations were one pip install away from a breach, Chainguard Libraries customers weren’t.
A secure-by-default approach
This is the fundamental shift: moving from reactive security to systems that are secure by default. The industry’s response to incidents like this is to rotate credentials, audit logs, and patch forward. However, if this is your approach, you’re already behind and dealing with the consequences. Preventing untrusted artifacts from ever reaching production environments shifts the equation to proactive prevention rather than reactive response.
Attacks like this are only going to become more common as adversaries continue to target the software supply chain with growing success. The question isn’t whether a dependency available on a public registry will be compromised; it’s whether your systems are built to proactively prevent the storm from entering your environment when the next one strikes.
Learn more about how Chainguard Libraries for Python can help protect you against the next breach.
Share this article
Related articles
- security
Secure-by-default: Chainguard customers unaffected by the Trivy supply chain attack
Reid Tatoris, VP of Product
- security
Going deep: Upstream distros and hidden CVEs
Chainguard Research
- security
Chainguard + Second Front: A faster, more secure path into government markets
Ben Prouty, Principal Partner Sales Manager, Chainguard, and Veronica Lusetti, Senior Manager of Partnerships, Second Front
- security
This Shit is Hard: The life and death of a CVE in the Chainguard Factory
Patrick Smyth, Principal Developer Relations Enginee
- security
npm’s update to harden their supply chain, and points to consider
Adam La Morre, Senior Solutions Engineer
- security
Protect your AI workloads from supply chain attacks
Anushka Iyer, Product Marketing Manager