[Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised — full timeline and status #24518
Description
[LITELLM TEAM UPDATES]
- Compromised packages have been deleted (v1.82.7, v1.82.8)
- Compromise came from trivvy security scan dependency
- All maintainer accounts have been rotated (new maintainer accounts: @krrish-berri-2 , @ishaan-berri)
- Proxy Docker image users were not impacted, all dependencies are pinned on requirements.txt
- No litellm releases will be out until we have scanned our chain and make sure it's safe
Next Steps
- Review all berriai repo's for impact
- Scan circle ci builds to understand blast radius, and mitigate it
- We've engaged Google's mandiant.security team, and are actively working on this with them
We are actively investigating this issue. Please reach out to us on support@berri.ai, if you have any questions / concerns.
Summary
The litellm PyPI package was compromised by an attacker who gained access to the maintainer's PyPI account. Malicious versions were published that steal credentials and exfiltrate them to an attacker-controlled server.
Original detailed analysis: #24512
Hacker News discussion: https://news.ycombinator.com/item?id=47501729
What happened
- The maintainer's PyPI account (
krrishdholakia) appears to have been hijacked by an attacker (teampcp) - The attacker published malicious versions to PyPI that were never released through the official GitHub CI/CD
- GitHub releases only go up to
v1.82.6.dev1— versions 1.82.7 and 1.82.8 on PyPI were uploaded directly by the attacker
Affected versions
| Version | Method | Trigger |
|---|---|---|
| 1.82.7 | Payload embedded in litellm/proxy/proxy_server.py |
Triggered on import litellm.proxy |
| 1.82.8 | Added litellm_init.pth (34,628 bytes) + payload in proxy_server.py |
Any Python startup — no import needed |
Other versions may also be affected and should be audited.
What the malicious code does
- Collects: SSH keys, environment variables (API keys, secrets), AWS/GCP/Azure/K8s credentials, crypto wallets, database passwords, SSL private keys, shell history, CI/CD configs
- Encrypts: AES-256-CBC + RSA-4096 (hardcoded public key)
- Exfiltrates:
curl POSTtohttps://models.litellm.cloud/
The exfiltration domain litellm.cloud (NOT the official litellm.ai) was registered on 2026-03-23 via Spaceship, Inc. — just hours before the malicious packages appeared.
Current status
- PyPI: The entire litellm package has been suspended/removed. All versions currently return "No matching distribution found." We reported the malware to PyPI via the official "Report malware" form.
- GitHub Issue [Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer #24512: Contains the original detailed technical analysis (currently closed by the attacker's spam — see below).
- Attacker behavior: The attacker appears to be publishing hundreds of spam comments to suppress discussion. If this continues, we recommend moderating via the Hacker News thread linked above.
Recommendations for affected users
- Check if
litellm_init.pthexists in yoursite-packages/directory - Rotate ALL credentials that were present as environment variables or config files on any system where litellm 1.82.7+ was installed
- Pin dependencies to exact versions and verify against GitHub releases
- Monitor for unauthorized access using any potentially leaked credentials
References
- Original analysis: [Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer #24512
- Hacker News: https://news.ycombinator.com/item?id=47501729
- Attacker's exfil domain WHOIS: registered 2026-03-23, Spaceship Inc., privacy-protected
litellm_init.pthSHA256:ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
ghost commentedon Mar 24, 2026
Pypi has put the project in quarantine. this should block additional downloads.
thenoblet commentedon Mar 24, 2026
Our entire deployment has failed due to this issue. Pypi quarantined it, and I am just finding out. Such a bummer!!
DanielRuf commentedon Mar 24, 2026
This was probably caused by the compromised trivy project:
https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy&type=code
https://ramimac.me/trivy-teampcp/#phase-09
litellm/ci_cd/security_scans.sh
Line 16 in 9343aee
The full timeline contains more details.
akx commentedon Mar 24, 2026
Note that it's not just PyPI... See e.g. https://github.com/krrishdholakia/blockchain/commit/556f2db38e98bff4495ced183ea6253c5a68bfe0 (unrelated repo) (and other recent activity).
DanielRuf commentedon Mar 24, 2026
Yes, the trivy project contained a credential stealer and the threat actors used PATs and other secrets extracted via CI / CD.
This means full rotation after cleanup for all involved secrets and connected services (PyPi etc).
dkindlund commentedon Mar 24, 2026
The Attack Chain: Trivy → LiteLLM PyPI
Based on the ramimac writeup and issue #24518:
1. March 1: Aqua Security (Trivy's maintainer) suffered an initial breach
2. Incomplete credential rotation left tokens available to the attacker (TeamPCP)
3. TeamPCP compromised Trivy — poisoned v0.69.4-v0.69.6, force-pushed all 76+ trivy-action tags, and pushed malicious Docker images directly to Docker Hub
4. March 23: Attacker registered litellm.cloud domain (exfiltration target)
5. March 24 ~08:30 UTC: Published malicious litellm==1.82.7 and 1.82.8 to PyPI using the compromised maintainer account krrishdholakia
The connection: the Trivy compromise likely gave the attacker access to the LiteLLM maintainer's PyPI credentials (either harvested from CI secrets via the compromised Trivy runs, or through the broader credential-stealing payload).
GitHub Source Code: NOT Compromised
- No malicious code in any GitHub tag from v1.82.3-stable through v1.82.6.rc.2
- No v1.82.7 or v1.82.8 tags exist on GitHub — the attacker published directly to PyPI
- The base64 and subprocess usages in proxy_server.py across all tagged versions are legitimate (config handling, callbacks)
- No .pth files, no litellm.cloud references, no exec(base64.b64decode(...)) patterns in the source
- The simple_pypi_publish.yml workflow was last modified July 2025 — not tampered with
- Last legitimate CI-published version was March 13
LiteLLM's Trivy Usage — Potential Exposure Vector
LiteLLM's ci_cd/security_scans.sh installs Trivy via apt from aquasecurity.github.io/trivy-repo/deb without version pinning — it pulls whatever the latest version is. If a CI run occurred during the Trivy compromise window, it would have installed the poisoned Trivy, which could have exfiltrated CI secrets including the PYPI_PUBLISH_PASSWORD.
hdnh2006 commentedon Mar 24, 2026
Your account is compromised dude:
119 remaining items
mihaimaruseac commentedon Mar 25, 2026
It already does. Trusted publishing is a thing. https://www.pyopensci.org/python-package-guide/tutorials/trusted-publishing.html
fix(security): pin litellm<=1.82.6 — supply chain attack on 1.82.7+
fix(security): pin litellm<=1.82.6 — supply chain attack on 1.82.7+ (#…
fix(security): pin litellm<=1.82.6 — supply chain attack on 1.82.7+ (#48
fix(security): pin litellm<=1.82.6 — supply chain attack on 1.82.7+ (#95
krrish-berri-2 commentedon Mar 25, 2026
mihaimaruseac commentedon Mar 25, 2026
Yeah, it assumes you are publishing from a secured GitHub repo, not from your machine.
For extra, you can publish from an action in a separate repo (separate owner is better), so an attacker has to compromise more systems.
litellm1.82.7/1.82.8(4-hour window, limited impact) agentscope-ai/CoPaw#2209AsteriskZuo commentedon Mar 25, 2026
I created a tool that can scan locally to see if there is a problem version of the library. https://github.com/AsteriskZuo/scan-litellm-safely
SECURITY: Pin litellm to safe versions (supply chain attack)
idreesmuhammadqazi-create commentedon Mar 25, 2026
i got redirected from https://litellm.cloud to
https://manpages.wtf
bro doesnt have whois privacy enabled
though the email is throwaway
https://www.whois.com/whois/manpages.wtf