Yesterday, two versions of LiteLLM, a Python library used by thousands of AI applications to route LLM requests, were published to PyPI with credential-stealing malware baked in. The malicious code harvested SSH keys, cloud credentials, database passwords, Kubernetes secrets, and crypto wallets from every machine that installed the package.
The library gets over 3 million downloads per day. The compromised versions were live for about 3 hours before PyPI pulled them.
Every dev tool that runs inside your application has the exact same risk profile. Here are some learnings for every dev tool builder.
What happened
Here's the short version. A threat group called TeamPCP had been compromising open source security tools for the past week. They started with Aqua Security's Trivy vulnerability scanner on March 19, then Checkmarx's KICS scanner on March 23. LiteLLM used Trivy in its CI/CD pipeline. When Trivy was compromised, it leaked LiteLLM's PyPI publishing token. The attackers used that token to publish two malicious versions, 1.82.7 and 1.82.8.
The clever part: version 1.82.8 used Python's .pth mechanism, a configuration file that executes code every time the Python interpreter starts. You didn't even need to import LiteLLM. Simply having it installed was enough to trigger the malware.
The malware collected everything it could find. Environment variables, SSH keys, AWS/GCP/Azure credentials, database configs, API keys, crypto wallets. It encrypted it all with a 4096-bit RSA key and sent it to an attacker-controlled domain that looked like legitimate LiteLLM infrastructure.
The LiteLLM maintainer had 2FA enabled. It didn't matter. The attack came through a compromised dependency in the CI/CD pipeline, not through the maintainer's account directly.
Why dev tools are high-value targets
LiteLLM isn't just a library. It's an AI gateway. It sits between applications and LLM providers, routing API calls. That position gives it access to API keys for every LLM provider the application uses.
This is why dev tools are attractive targets. Developers trust them implicitly. They often run with elevated access. And a single compromised version reaches thousands of machines before anyone notices.
The pattern is the same across all of these tools:
Trivy is a security scanner. Ironic. The tool meant to find vulnerabilities became the vulnerability. It had access to CI/CD secrets because that's where security scanners run.
LiteLLM is an LLM router. It had access to every LLM API key because that's its job.
Dev tools that run inside your app have access to everything the app has access to. Database connections, auth tokens, environment variables, request bodies. That's what makes them useful. It's also what makes a compromised version devastating.
What every dev tool should be doing
Any dev tool that runs inside your application, whether it's an observability tool, an error tracker, an analytics SDK, or an instrumentation library, has access to everything your app has access to. Database connections, auth tokens, environment variables, request bodies. That's what makes these tools useful. It's also what makes a compromised version devastating.
The question isn't whether the risk exists. It's what the maintainers are doing about it. Here's what every dev tool should be doing:
Minimal dependencies. Every dependency is an attack surface. LiteLLM was compromised through Trivy, a transitive dependency in its build pipeline. The fewer dependencies you ship, the smaller your attack surface.
2FA on package registries. npm and PyPI both support two-factor authentication. This protects against direct account compromise but as LiteLLM showed, it doesn't protect against token theft from CI/CD. It's a baseline, not a solution.
Open source. Every line of code should be auditable. A malicious addition to a closed-source SDK could go unnoticed for months. Open source makes it visible in the diff.
Local-first architecture. If your tool doesn't need a cloud server, don't have one. No cloud means no infrastructure for an attacker to impersonate. The LiteLLM malware exfiltrated data to models.litellm.cloud, a domain that looked official but wasn't. Tools that make no outbound connections eliminate this vector entirely.
No static publish tokens. Use trusted publishing with OIDC instead of long-lived tokens. Tie package publishing to specific CI workflows via short-lived tokens. There should be no NPM_TOKEN or PYPI_TOKEN sitting in a CI/CD secret that can be stolen.
Pinned CI/CD dependencies. Pin every GitHub Action to a specific commit SHA, not a version tag. This is exactly how the Trivy attack propagated. The attackers rewrote version tags to point to malicious code. Pinning to commit hashes prevents this.
What you should check in your own projects
This isn't just about LiteLLM. Every project with third-party dependencies carries supply chain risk. Here's what you can do:
Audit your dev dependencies. Run npm ls or pip list and look at what's installed. Do you know what every package does? Do you know who maintains it? Dev dependencies are often treated as lower risk, but they run on your machine with the same permissions as production dependencies.
Pin GitHub Actions to commit SHAs. If your CI/CD workflow uses actions/checkout@v4, change it to actions/checkout@<specific-sha>. Tags can be rewritten. Commits can't. This is the single most impactful change you can make today.
Review lockfile changes. When package-lock.json or yarn.lock changes in a PR, actually look at what changed. A new transitive dependency or an unexpected version bump is worth investigating.
Check if your tools read .env files. Many dev tools read environment files to auto-configure. That's convenient, but it also means they have access to your secrets. Know which tools read your .env and what they do with the data.
Use npm audit signatures. This verifies that published packages have valid provenance, meaning they were built from a known source repository through a verified CI/CD pipeline.
Keep dev tools in devDependencies. If a tool is only for development, make sure it's in devDependencies, not dependencies. Most production build pipelines strip devDependencies, which means the tool won't be present in your deployed application. This doesn't prevent attacks on your development machine, but it limits the blast radius.
The uncomfortable truth
There's no way to make supply chain attacks impossible. LiteLLM's maintainer did things right. 2FA was enabled, the project was well-maintained, the code was open source. The attack came through a dependency of a dependency in the build pipeline. No amount of vigilance on the maintainer's part would have caught it before it happened.
The open source ecosystem is built on trust. When you run npm install, you're trusting the maintainer, their CI/CD pipeline, every dependency in their build, every GitHub Action they use, and the package registry itself. That chain of trust is long, and every link is a potential point of compromise.
What we can do is add layers of defense. No single measure prevents all attacks. But 2FA plus minimal dependencies plus pinned CI/CD plus trusted publishing plus open source plus local-first architecture makes each successive attack harder to execute and easier to detect.
Links:
Top comments (0)