On March 24, 2026, Andrej Karpathy posted a warning that most developers in the AI space saw within hours: a simple pip install litellm exfiltrated SSH keys, cloud credentials, Kubernetes secrets, API keys, crypto wallets, and more from any machine that ran it. He called it “software horror.” Given the scale, LiteLLM has 3.4 million downloads per day, that's not an overstatement.
The good news: this attack is exactly the kind of thing a well-configured artifact management setup is built to stop.
LiteLLM is an open-source Python library that acts as a universal API gateway for large language models. Instead of writing separate integration code for OpenAI, Anthropic, Google, and dozens of other providers, developers use LiteLLM to call all of them through a single standardized interface. It's a natural fit for any team building AI-powered applications, which is why it's become something close to infrastructure, with close to 100 million downloads per month.
That position in the AI stack, sitting between applications and every LLM provider, is also what made it an attractive target. A package with that kind of access to API keys and environment variables is worth compromising.
The threat group behind this, known as TeamPCP, didn't find a bug in LiteLLM's code. They worked their way up the supply chain: first compromising Trivy, a widely used open-source security scanner (CVE-2026-33634), then using that foothold to steal LiteLLM's PyPI publishing credentials. With those credentials, they uploaded two backdoored versions of LiteLLM directly to PyPI. This required no pull request, no code review, and nothing to inspect.
Standard integrity checks passed. The packages were published using legitimate credentials, so there was no hash mismatch, no suspicious metadata, no misspelled package name. The malicious versions were live for roughly three hours before PyPI quarantined them.
Three hours is a narrow window, but it's wide enough. And as Karpathy noted, the attack was only discovered because a bug in the malware crashed a researcher's machine.
The more unsettling detail is how far the blast radius extends. The contagion spreads to any project that depends on LiteLLM. This includes teams using it directly and anyone running pip install dspy or any other package with LiteLLM in its dependency tree. Most developers have no visibility into what their dependencies depend on, let alone controls over it.
The LiteLLM attack didn't require beating sophisticated defenses. It required developers pulling packages directly from a public registry with no organizational governance layer in between.
That's the gap Cloudsmith closes. It makes sure that your team doesn’t pull directly from PyPi without a policy check first.
Here's how that works in practice, mapped to the specific failure modes in this attack.
Route pip install through Cloudsmith, not PyPI.
Cloudsmith acts as a proxy between your developers and upstream registries like PyPI. Packages don't arrive on developer machines directly from PyPI, they pass through Cloudsmith first, where your organization's policies apply. This one change puts every subsequent control within reach.
Apply a quarantine window to new package versions.
Cloudsmith lets you configure a cooldown policy that holds newly released versions in quarantine before they enter your environment and get served to your team. This gives the security community time to identify problems before your developers install anything. The policy applies organization-wide; it doesn't depend on individual developers remembering to check a release date or configuring pip correctly. The three-hour window that defined the LiteLLM attack becomes irrelevant if new versions don't reach your developers for 7 to 14 days.
Use CI/CD pipelines as a second gate.
Even on disciplined teams, a developer working quickly on their laptop might pull directly from PyPI. That's why your CI/CD pipelines should point to Cloudsmith independently of workstation configuration. Code that pulls a bad version locally doesn't survive the build pipeline because it gets caught before it reaches staging, production, or any shared infrastructure.
The LiteLLM attack is a useful reminder that AI tooling is software, and software has a supply chain. As AI agents take on more autonomous roles in development – installing dependencies, running builds, pulling packages – the same governance principles apply whether the consumer is a human or an agent. Controlling what packages enter your environment is part of running AI infrastructure responsibly.
If you'd like to understand your current exposure, book a demo with Cloudsmith for a custom assessment of your software supply chain.
