Date: March 24, 2026
Target: LiteLLM (Versions 1.82.7 & 1.82.8)
Threat Actor: Suspected TeamPCP (linked to HackerBot-Claw campaign)
⚠️ Live Incident — Updated March 24, 2026: This attack is actively unfolding. PyPI has quarantined the affected versions. If you've used LiteLLM in the last 24 hours, see the Developer Advisory below.
Executive Summary
A widely trusted Python library — LiteLLM — was compromised and distributed with hidden malware.
Anyone installing the affected versions unknowingly:
- Executed malicious code automatically
- Had sensitive credentials silently stolen — SSH keys, cloud tokens, Kubernetes secrets
- Potentially exposed entire cloud environments
The campaign has now expanded from GitHub Actions to include malicious packages on PyPI. PyPI quarantined the affected versions approximately 3 hours after publication — but the window was open long enough.
This wasn't a traditional hack. It was a trust breach at the software supply chain level.
Why This Matters
Modern software is no longer built — it's assembled.
Your application depends on:
- Open-source libraries
- Package registries (PyPI, npm)
- CI/CD pipelines
- Third-party APIs
This attack proves a hard truth:
Your security is only as strong as the weakest dependency you trust.
Recent reporting highlights a growing trend: attackers are increasingly targeting popular Python libraries — not for disruption, but for silent credential harvesting at scale. AI-related tooling is a prime target due to high-value API keys.
1. What is a Supply Chain Attack?
Imagine you run a high-security restaurant:
- Guards at the doors
- Cameras everywhere
- Secure cash handling
You're confident no one can break in.
Now imagine someone poisons your ingredients before delivery.
You trust your supplier — so you let it in.
| Real World | Software World |
|---|---|
| Restaurant | Your company / system |
| Farmer | LiteLLM (trusted library) |
| Poisoned lettuce | Malicious code |
You didn't get hacked. You installed the attack yourself.
2. The Attack: Step-by-Step
Phase 1 — The Breach: Stealing the Keys
Attackers likely obtained a Personal Access Token (PAT) from a maintainer via:
- Scanning CI/CD pipelines
- Exploiting misconfigurations
- Credential leaks in logs or environment variables
This granted them permission to publish code as a trusted maintainer.
Phase 2 — The Infection: The .pth Trick
Instead of modifying obvious code, attackers added a file:
litellm_init.pth
Why this is dangerous:
-
.pthfiles in Python are automatically executed on startup - No
importrequired - No function call required
Just installing the package = executing the malware
This is what made the attack extremely stealthy.
Phase 3 — The Theft: Credential Harvesting
Once executed, the malware scanned for:
Cloud Credentials
- AWS keys
- GCP credentials
- Azure tokens
AI Secrets
- OpenAI API keys
- HuggingFace tokens
Infrastructure Access
- SSH keys
- Environment variables
- Local config files
Phase 4 — The Exfiltration: Data Escape
The stolen data was packaged silently and sent to attacker-controlled servers.
In some campaign variants, secrets were written into public CI logs — acting as a delayed dead drop retrieval system.
Your own infrastructure became the attacker's delivery channel.
3. Why This Attack Was So Dangerous
It Targeted the "Middle Layer"
LiteLLM sits between your app and AI providers (OpenAI, Claude, etc.) — giving it direct access to high-value API keys and billing-sensitive tokens.
It Weaponised Best Practices
Developers are told: "Always keep dependencies updated."
Attackers flipped this into: "Updating your dependency installs malware."
Tag Hijacking: The Silent Killer
Attackers overwrote existing version tags. So even this:
pip install litellm==1.82.7
...was no longer safe. Version pinning alone failed completely.
It Exploited Developer Assumptions
Developers assume:
- "PyPI packages are safe"
- "Pinned versions don't change"
- "Nothing runs unless I import it"
All three assumptions were broken.
🔴 Developer Advisory: Act Now
If you have used LiteLLM in the last 24 hours, take these steps immediately.
1. Pin to a Safe Version
Revert to v1.82.6 — the last known clean version:
pip install litellm==1.82.6
2. Rotate All Secrets
If you installed v1.82.7 or v1.82.8, assume all credentials on that machine are stolen:
- API keys (OpenAI, HuggingFace, etc.)
- Cloud tokens (AWS, Azure, GCP)
- SSH keys
- Kubernetes secrets
Rotate everything. Immediately.
3. Check for Active Infection
Search your Python environment for the malicious file:
find / -name "litellm_init.pth" 2>/dev/null
Its presence indicates an active infection.
4. Monitor Outbound Network Traffic
Check your egress logs for connections to the known exfiltration domain:
models.litellm.cloud
Any traffic to this domain should be treated as a confirmed breach indicator.
🕸️ The Broader Campaign: Shai-Hulud 2.0
Security researchers have linked this attack to a wider campaign dubbed HackerBot-Claw, also referred to as Shai-Hulud 2.0.
Key intelligence:
- Automated bots exploit misconfigured GitHub Actions workflows to steal maintainer tokens
- The same group previously compromised Trivy, a widely used container security scanner
- Attackers use public GitHub repositories — frequently named with
tpcp-docs— as dead drops to store exfiltrated data - This explains the CI log exfiltration technique: your own pipeline becomes the retrieval mechanism
This is not an isolated incident. It is a systematic, automated campaign targeting the open-source toolchain.
4. How to Protect Your Systems
✅ Rule 1: Pin by Hash (Non-Negotiable)
# ❌ Bad
pip install litellm==1.82.7
# ✅ Good
pip install litellm --hash=sha256:<exact_hash>
A hash is an immutable fingerprint. Any code change → hash mismatch → install fails.
This is the single most important control.
✅ Rule 2: Use Scoped Credentials
Most API keys today have too much power. Fix this:
- Use least-privilege access
- Separate keys per service
- Restrict permissions, IP ranges, and usage limits
Example: your chatbot key should cover only inference — not billing, not admin APIs.
Assume every key will leak. Design for containment.
✅ Rule 3: Egress Filtering
Most companies focus on blocking attacks coming in — but ignore data leaving.
- Allow outbound traffic only to known APIs (e.g.,
api.openai.com) - Block everything else by default
If malware tries POST https://models.litellm.cloud/steal → connection denied. Even if compromised, data cannot escape.
✅ Rule 4: Dependency Verification Pipeline
pip install --require-hashes
Also use tools like:
✅ Rule 5: Zero Trust for Dependencies
"Every dependency is untrusted until verified."
- No blind updates
- No implicit trust in maintainers
- Always verify integrity
5. Lessons for Engineering & Leadership
For Engineers
- Stop relying on version pinning alone
- Audit how dependencies execute code
- Treat
.pthfiles, post-install scripts, and hooks as high-risk
For Engineering Leaders
- Enforce secure dependency policies org-wide
- Invest in internal package mirrors and SBOMs (Software Bill of Materials)
- Make security part of CI — not an afterthought
For Non-Technical Leadership
This attack shows you can have perfect internal security and still be compromised via vendors.
This is a business risk, not just a technical one.
Final Takeaway
The LiteLLM attack was not a failure of coding.
It was a failure of trust assumptions in modern software.
| The Old Model | The New Reality |
|---|---|
| "If it installs, it's safe" | "If you didn't verify it, assume it's compromised" |
You don't get hacked because your walls are weak.
You get hacked because you trusted what came through the gate.
Top comments (0)