Product

Resources

Company

Forced upgrades are a critical attack vector.

litellm just proved it.

TeamPCP didn't need a CVE. They needed one unpinned dependency. On March 24, they got it — and walked out with your SSH keys, cloud tokens, and Kubernetes secrets.

⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ● ⚠ ACTIVE INCIDENT | litellm 1.82.7 + 1.82.8 | March 24, 2026 | Rotate your credentials now ●

What Happened

One .pth file. Every credential on your machine.

TeamPCP poisoned Trivy, the security scanner in litellm's own CI/CD pipeline, to steal the maintainer's PyPI publishing token. Then they pushed two malicious versions directly to PyPI. No tag. No PR. No CVE.

The payload executed automatically on every Python process startup.

No import. No interaction. If litellm was installed, it ran.

Collect

SSH keys, cloud tokens, K8s configs, DB passwords, env vars, cloud metadata endpoint.

Exfiltrate

AES-256-CBC encrypted, posted to models.litellm.cloud — attacker-controlled, zero affiliation to litellm.

Persist

K8s service account token present? Secrets enumerated across all namespaces. Privileged pods deployed on every node. Backdoor installed.

Note: litellm is a transitive dependency for AI agent frameworks, MCP servers, and LLM orchestration tools. You may have been hit without ever running pip install litellm yourself.

Am I Affected?

Two commands. 30 seconds.

bash
pip show litellm | grep Version
# 1.82.7 or 1.82.8 = affected
bash
pip install litellm==1.82.6

If affected, rotate all of these: SSH keys · AWS/GCP/Azure tokens · K8s service account tokens · Database passwords · Git credentials · AI provider API keys · Any secret in env vars

IOCs Domain: models.litellm.cloud · Backdoor: /root/.config/sysmon/sysmon.py · K8s pods: node-setup-*

Analyst Perspective

"

The litellm incident isn't an edge case — it's a signal. Attackers no longer need a CVE to compromise your environment. The organizations that get ahead of this are the ones rethinking detection at the dependency layer, not just the vulnerability layer.

James Bartholomy
Latio

How Root Handles This:

Traditional response: 7–17 days. Root: 8–24 hours.


Phase
Traditional
Root
Detection
Day 0: malicious release published
Hour 0: anomalous release flagged — no tag, no attestation
Triage
Day 2–4: manual environment audit
Hour 2–4: automated — which containers pulled 1.82.7/1.82.8
Remediation
Day 4–7: credential rotation
Hour 4–8: pinned to 1.82.6, containers rebuilt
Verification
Day 7–10: rebuilds, persistence hunting
Hour 8–24: IOCs checked, rotation initiated


3 differentiators No guesswork on blast radius. Root knows exactly which environments pulled the bad version. Pin without dependency hell. Known-good versions, no breaking changes, no forced upgrades. Detect before CVEs exist. Root monitors release attestations and PyPI anomalies, not just CVE databases.

Get Protected

The next one wont announce itself either.

TeamPCP hit Trivy on March 19. KICS on March 23. litellm on March 24. They are not done. Root closes the window.

Book a same-day call

Root maintains a verified, uncompromised build of litellm 1.82.6. Pull directly. No manual pinning. No PyPI exposure.