On March 24, 2026, someone slipped malicious code into LiteLLM versions 1.82.7 and 1.82.8 on PyPI. LiteLLM gets 95 million downloads per month. It's the library that lets you route requests across LLM providers through a single API.
If you're vibe coding with any AI tool that uses LiteLLM under the hood, this affects you directly.
What Happened
The attacker (tracked as TeamPCP by Endor Labs) injected 12 lines of code into proxy_server.py. The code executes the moment the module is imported. No user interaction needed.
Version 1.82.8 went further: it added a .pth file that runs the payload on any Python invocation, even if you never import LiteLLM. Just having it installed is enough.
The payload runs a three-stage attack:
-
Harvests credentials: SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and
.envfiles - Lateral movement: Deploys privileged pods across Kubernetes clusters
- Persistence: Installs a systemd backdoor that polls for additional binaries
Everything gets encrypted and exfiltrated to an attacker-controlled domain.
Why Vibe Coders Are Most Exposed
This is the part that matters if you're building with Cursor, Lovable, Bolt, or Replit.
No lockfiles. Most vibe coders run pip install litellm without version pinning. Whatever is latest on PyPI is what you get. The compromised versions were live for 46 minutes before being pulled. That's 47,000 downloads.
No dependency auditing. When your AI coding tool adds a package, do you check what version? Do you verify hashes? Most vibe coders don't even know what packages their AI added to requirements.txt.
Trust inheritance. Your AI coding tool has access to your environment variables, API keys, and cloud credentials. A compromised dependency inherits all of that access. The attacker didn't need to break your code. They broke a library your code trusts.
The .pth file trick. This is particularly nasty. Python's .pth files execute at interpreter startup. Security scanners that check import-time execution wouldn't catch it. Static analysis tools that flag exec() and eval() wouldn't catch it either, because the payload uses subprocess.run() instead.
This Isn't an Isolated Incident
TeamPCP has been running a month-long campaign across five ecosystems:
- GitHub Actions: Compromised Aqua Security's Trivy (a vulnerability scanner)
- Docker Hub: Compromised Checkmarx's KICS (infrastructure-as-code analyzer)
- npm: CanisterWorm malware
- OpenVSX: VS Code extension supply chain
- PyPI: LiteLLM (this attack)
Notice the pattern? They're specifically targeting security tools. The tools developers trust to keep them safe are the attack vector.
What You Should Do Right Now
1. Check if you're affected
pip show litellm | grep Version
If you see 1.82.7 or 1.82.8, you need to assume compromise. Rotate ALL credentials immediately.
2. Pin your dependencies
Stop installing latest. Use a lockfile with hashes.
litellm==1.82.6 --hash=sha256:<verified_hash>
3. Audit your requirements.txt
Look at what your AI coding tool added. Do you know what every package does? If not, you have blind trust in your dependency tree.
4. Use pip audit
pip install pip-audit
pip-audit
This checks your installed packages against known vulnerabilities.
5. Scan your deployed app
If you shipped a vibe-coded app to production, scan it. Exposed API keys, missing auth, open endpoints -- these are the things attackers look for first.
VibeCheck on notelon.ai scans for the most common vibe coding security mistakes. Free, no signup.
The Bigger Picture
35 CVEs were directly attributed to AI-generated code in March 2026 alone. Up from 15 in February and 6 in January.
The vibe coding security crisis isn't theoretical anymore. Real attacks are happening against the exact tools and packages vibe coders depend on.
The builders who scan, pin, and audit will survive. The ones running pip install with blind trust are one compromised package away from a full credential dump.
Previously: I Tested Every Vibe Coding Security Scanner (2026) -- ranked #3 on Brave for "best vibe coding security scanner"
Top comments (0)