The malicious LiteLLM packages were live on PyPI for about forty minutes in March. The credential archive that surfaced this week is 153GB. Most of what you need to understand about securing AI infrastructure right now sits between those two numbers.
The chain: scanner, CI, registry
On March 19, an actor tracked as TeamPCP shipped a poisoned build of Trivy, the open-source vulnerability scanner, using stolen release credentials. They never targeted LiteLLM directly. They did not have to. LiteLLM’s build pipeline installed the compromised scanner automatically, the way CI installs everything. Inside the GitHub Actions runner, the scanner did what scanners are trusted to do — read everything — and it left with LiteLLM’s PyPI publishing tokens and a maintainer’s GitHub personal access token. The PAT went to vandalism: a defaced maintainer profile and tampered personal repos. The publishing tokens went to work.
On March 24, TeamPCP used those tokens to publish LiteLLM 1.82.7 and 1.82.8 with a credential harvester inside. The payload was a Python .pth file, a hook the interpreter executes on startup with no import required. Every Python invocation on an affected machine ran it, and it took the entire environment.
The packages were pulled in roughly forty minutes. It did not matter. LiteLLM sits in requirements files and base images across the industry, and CI is very good at installing things quickly. CloudSEK’s mapping puts the blast radius at roughly 2,500 organizations and 434,000 CI/CD pipeline runs. Hudson Rock obtained the archive itself: 153GB, 433,909 files, 118,829 CI runner dumps across 2,488 corporate domains — AWS keys, Azure variables, Slack signing secrets, Salesforce credentials, and AI provider keys, with names like Nvidia, Microsoft, Samsung, FedEx, and Volkswagen on the victim list. Kevin Beaumont verified the archive independently — “the data is legit” — and found credentials that still worked months after they were taken.
The gateway concentrated exactly what the attacker wanted
An LLM gateway’s whole purpose is concentration. LiteLLM exists so that one process can talk to every model provider on your behalf, which means one process holds the provider API keys for OpenAI, Anthropic, Bedrock, and Azure; the cloud IAM roles behind them; the database credentials for logging, budgets, and rate limits — and it gets built and deployed by CI that holds still more. Concentration was the design goal. It is also the blast radius.
That same process installs from the same public registries as everything else in the build. Anyone running an LLM proxy has made this trade: a single choke point that is both the most convenient place to manage AI access and the most rewarding possible thing to compromise. Most teams made the trade without writing it down anywhere.
Five quiet months
The number worth arguing about is not 153GB. It is five months — publication on March 24, disclosure on August 12.
The archive tells you where the compromise lived that whole time. 118,829 of its files are CI runner dumps. This did not play out in production traffic, where inference is metered, logged, and increasingly watched. It played out in build pipelines, where AI dependencies actually get installed and where almost nobody has runtime instrumentation pointed. EDR watches laptops and servers. AppSec reads source. Production observability starts after deploy. A CI runner that spawns Python, reads its own environment, and phones home sits in the gap between all three.
If you ran 1.82.7 or 1.82.8
Rotating LLM provider keys is the smallest item on the list. The payload harvested the whole runner environment, so scope the response to the runner, not the package:
- Assume cloud IAM keys, SSH keys, Kubernetes secrets, and package publishing credentials are gone.
- Pull audit logs back to March 24 and hunt for use, not just presence. Beaumont found credentials from this archive still valid in August.
- Sweep hosts for leftover
.pthfiles and unexpected systemd services. The persistence footprint is small and easy to miss. - Treat your own publishing tokens as the top of the list, not the bottom. That is how this attack propagates — Trivy’s compromise was never about Trivy. If your tokens were on those runners, you are a candidate link in the next chain, not just a victim of this one.
An unrevoked token and a transitive dependency
The industry’s attention — ours included — goes to the AI-shaped threats: prompt injection, model red-teaming, agents attacking agents. The largest AI security failure disclosed this year required none of that. It was an unrevoked token, a transitive dependency, and five months where nobody was looking at the right layer.
Deterministic controls would have broken this chain at any of four links: short-lived, scoped publishing tokens; pinned and verified build dependencies; egress control on CI runners; and runtime eyes on what installed packages actually do. None of that requires a model to fight a model. It requires watching the infrastructure your AI runs on as closely as you have started watching the AI itself.
That is the layer we build for. If you want to see what the AI infrastructure in your environment is actually doing at runtime — gateways included — request a demo. If you would rather read first, start with the one-pager.
Reporting: Help Net Security (August 13, 2026) and SecurityWeek (August 12, 2026), based on research from CloudSEK and Hudson Rock, with independent verification by Kevin Beaumont and attack-chain reconstruction by Trend Micro. Malicious versions: LiteLLM 1.82.7 and 1.82.8, published March 24, 2026.