LiteLLM 1.82.8 ships malicious .pth credential stealer on PyPI
Compromised LiteLLM 1.82.7 and 1.82.8 wheels executed a malicious .pth file at install time to exfiltrate credentials, and PyPI quarantined the releases. Treat fresh-package installs and AI infra dependencies as supply-chain risk, and check startup hooks on affected systems.
TL;DR
- LiteLLM versions 1.82.7 and 1.82.8 on PyPI were reported as compromised releases, and the core issue report says PyPI quarantined them after a malicious wheel was found with a credential-stealing startup hook issue report.
- The payload was not just a bad import path: Hacker News discussion around the incident says the exploit lived in a Python
.pthfile, which can execute arbitrary code during install or interpreter startup HN discussion. - The affected wheel reportedly targeted high-value secrets including environment variables, SSH keys, and cloud credentials, which makes this more than a broken package update for teams using LiteLLM as an AI gateway or proxy layer issue report HN thread.
- A separate incident writeup says AI-assisted analysis helped identify the poisoned package, trace the
.pthbehavior, and get to public disclosure in 72 minutes, but follow-on discussion also flagged that models can still hallucinate about low-level execution details response transcript HN reactions.
What was compromised and how did it run?
[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer
The GitHub issue reports a critical security vulnerability in the litellm==1.82.8 PyPI wheel package, which contains a malicious litellm_init.pth file (34,628 bytes) that steals environment variables, SSH keys, cloud credentials, and other sensitive data upon installation via pip. The issue is open, created on 2026-03-24, with high engagement (765 thumbs up). Team updates are tracked in issue #24518. Versions 1.82.7 and 1.82.8 are affected; PyPI has quarantined the package. Not an official release.
The package report describes a malicious litellm_init.pth file inside the LiteLLM 1.82.8 wheel, sized at 34,628 bytes, and says it could steal "environment variables, SSH keys, cloud credentials" and other secrets when the package was installed via pip issue report. The same report says both 1.82.7 and 1.82.8 were affected and that the releases were quarantined on PyPI issue report.
Discussion around Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
Thread discussion highlights: - zahlman on Python .pth execution: The exploit is directly contained in the .pth file; Python allows arbitrary code to run from there... what malware can do is put something in a .pth file like `import sys;exec(...)` - getverdict on AI tooling supply-chain risk: Supply chain compromises in AI tooling are becoming structural, not exceptional... the blast radius keeps growing as these tools get embedded deeper into production pipelines. - postalcoder on package release-age defenses: npm/bun/pnpm/uv now all support setting a minimum release age for packages... `exclude-newer = "7 days"`
The important mechanic is the .pth execution path. In the Hacker News thread, one commenter explained that "Python allows arbitrary code to run" from a .pth file, and that malware can drop code like import sys;exec(...) there HN discussion. That matters because the compromise was not framed as a normal runtime bug inside LiteLLM itself; it was a supply-chain attack embedded in Python packaging behavior before an app even starts serving traffic.
That raises the blast radius for AI infra teams. The original HN post explicitly called out how this kind of poisoned dependency can propagate through "proxy packages and agent frameworks" that sit deep in production pipelines HN thread.
What does this change for AI tooling and incident response?
My minute-by-minute response to the LiteLLM malware attack
The page provides a Claude Code conversation transcript detailing the author's real-time response to discovering the LiteLLM 1.82.8 supply chain attack on March 24, 2026. It covers a timeline from 10:52 UTC (poisoned package upload) to 12:04 UTC (public disclosure), including investigation of a fork bomb from 11k processes, malware analysis revealing a .pth file that harvests credentials and exfiltrates data, notifications to PyPI and LiteLLM support, and rapid blog post publication. Highlights AI tools accelerating detection and response, reducing disclosure time to 72 minutes.
A separate postmortem-style transcript turns the incident into a concrete case study for AI-assisted security response. The writeup says the poisoned upload landed at 10:52 UTC and public disclosure followed at 12:04 UTC, a 72-minute window that included investigating a fork bomb with 11k processes, analyzing the malicious .pth hook, and notifying both PyPI and LiteLLM support response transcript.
Fresh discussion on My minute-by-minute response to the LiteLLM malware attack
Today’s comments mostly add discussion around the security/process implications rather than new facts about the malware itself. People asked whether PyPI’s digital attestation/trusted publishing would have prevented this, debated the limitations of AI in operator roles, and argued that the real defense is deterministic approval gates and least-privilege controls around anything the model can execute. There was also skepticism about LLM reliability in the transcript (especially a repeated false claim that base64-encoded `exec` is normal), plus a side thread on how AI can both speed detection and flood security channels with low-quality reports. A few commenters also reacted to the speed of the response and disclosure, including one person noting they synced dependencies shortly after the bad release was removed, and another remarking on the author getting a blog post merged in under three minutes. One commenter joked about LiteLLM’s advertised security certifications, which underscored the thread’s broader irony about supply-chain trust.
The follow-on discussion is useful because it is less about the malware payload than about operational trust. Commenters asked whether PyPI "digital attestation" or trusted publishing would have changed the outcome, and one argued that once an LLM is in the loop it is "effectively acting as an operator" influencing what gets run and trusted HN reactions. Another commenter said Claude Code "repeatedly made the incorrect assertion" that base64 armoring was normal, a reminder that AI can speed triage while still being unreliable on low-level mechanics HN reactions.
The most concrete mitigation suggestion in the package thread was to slow down adoption of brand-new releases. A commenter noted that "npm/bun/pnpm/uv now all support" minimum package release ages, including a exclude-newer = "7 days" style control in uv fresh mitigations. In this incident, that kind of gate maps directly to the failure mode: a freshly published poisoned wheel in a widely used AI dependency.