LiteLLM Supply Chain Attack: 434,000 Pipelines, 2,500 Organisations

Fibre optic patch cables plugged into the front panels of rack-mounted servers, photographed close up Photo by Brett Sayles on Pexels

CYBERSECURITY · 13 Aug 2026 —

BENGALURU, 13 AUG 2026 — Two poisoned releases of LiteLLM sat on PyPI for about forty minutes in March. CloudSEK has now published what came out of that window: a dataset built from roughly 434,000 captured files, mapping potential exposure to more than 2,500 organisations.

Forty minutes is the number to hold on to. It is far too short to catch a human developer, and more than long enough to catch a fleet of build servers that pull fresh dependencies on every run.

The chain

Nobody attacked LiteLLM. The project was collateral.

On 19 March the group CloudSEK calls TeamPCP — tracked by Google as UNC6780 — compromised Aqua Security's Trivy, a vulnerability scanner that a very large number of CI pipelines install automatically. LiteLLM's own pipeline was one of them. Installing the poisoned scanner handed over the credentials that pipeline held, including the token that publishes LiteLLM to PyPI.

On 24 March, from 10:39 UTC, versions 1.82.7 and 1.82.8 appeared on PyPI carrying credential-stealing code. They were pulled after about forty minutes; CloudSEK treats installations up to 16:00 UTC that day as suspect. The incident carries CVE-2026-33634.

CloudSEK's own summary puts it best: "Trivy, then the build system, then the LiteLLM release: one unrevoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure."

Why forty minutes was enough

The payload did not wait to be imported. It executed on every Python invocation on any system where the package was installed.

That distinction explains the large number. A developer who installed during those forty minutes might run the payload once. A continuous integration runner installs it from a requirements file and executes it on every job, and a busy pipeline runs jobs continuously.

The 434,000 figure is a count of exfiltration events from automated pipelines, not of companies or of people. It is large because pipelines are repetitive, which is also why what they hold is worth taking.

19 MarchTrivy compromised by TeamPCP, Google's UNC6780. The upstream event.

24 March, 10:39 UTCLiteLLM 1.82.7 and 1.82.8 pushed to PyPI. Live for about 40 minutes.

434,000 filesExfiltration events captured from CI/CD pipelines, per CloudSEK's dataset.

2,500+ organisationsReconstructed exposure — explicitly not a victim count. See below.

What was taken

The haul was predictable, and it is what any build runner keeps in its environment: cloud keys, SSH keys, Kubernetes tokens, database passwords, environment variables, runtime data, and the package-publishing credentials that make the next hop possible.

One category is specific to what LiteLLM is. It is a proxy that puts one interface in front of many model providers, so the machines running it hold model credentials by design — OPENAI_API_KEY and ANTHROPIC_API_KEY among them, as CloudSEK records.

That is a category of secret that barely existed three years ago and now sits in a great many environments, frequently with generous quotas attached and no spending ceiling. A stolen cloud key gets noticed by a billing alarm eventually. A stolen model key funds somebody else's inference, and the first signal is an invoice.

The 2,500, handled honestly

CloudSEK is careful about this and the careful part is easy to lose in a headline.

The figure represents reconstructed exposure, based on information in the attackers' captured files that could be tied to an organisation. Matches are graded high confidence for identifiable corporate domains, repositories, credentials or infrastructure, and medium confidence for weaker indicators. CloudSEK is direct that these labels measure "the strength of evidence linking exposed information to an organization, not proof that the organization was breached or that an attacker used what was taken".

The named list includes NVIDIA, AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, Accenture Federal Services, Regeneron, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX and Zscaler. Appearing on it means something of theirs was in the captured data. It does not mean any of them was compromised.

Full disclosure: CloudSEK sells AIVigil, an exposure-monitoring product that this report points squarely towards. That does not make the dataset wrong — the firm's methodology notes are more restrained than most vendor research — but a reader should know which company benefits from the number being large.

If you followed our guide, you were not in this

We publish a guide to self-hosting LiteLLM, so the question is fair.

That guide installs from a published container image rather than from PyPI, pinned at litellm:v1.93.0 — eleven minor versions ahead of the poisoned releases, which were PyPI packages. Both facts put its readers outside the incident. Readers following it were never in the blast radius.

We are stating that because we told people to run this software, and the honest version of that obligation is to check rather than to stay quiet.

The argument this settles

Five days ago we wrote about registry time-locks — the cooldown mechanisms that make a package wait some number of days before automation is allowed to adopt it.

This incident makes the strongest case yet for time-locks, precisely because the window was so short. A cooldown of even a single day would have made 1.82.7 and 1.82.8 unreachable by every pipeline that had one enabled. Forty minutes cannot be beaten by human vigilance, by review, or by faster monitoring. It can only be beaten by not being first.

The cost is equally clear: a cooldown delays legitimate security patches by the same interval. The trade-off is clear. A security fix applied a day late is a manageable risk. A credential harvester applied within the hour is not.

What to do

If LiteLLM ran anywhere in your build path in March, follow CloudSEK's advice, which is broader than it first sounds: rotate every credential the affected process could reach, not just the ones you believe it used. A harvester takes the environment, not a selection from it.

Then read access logs across cloud accounts, source control, registries and clusters for the period after 24 March, on the assumption that anything taken has had four and a half months to be used.

Then look at the shape of the problem rather than this instance of it. The lesson here is not about LiteLLM or Trivy. It is that an un-expiring token in a pipeline that always installs the latest dependencies converts any upstream compromise into your own — automatically, at machine speed, three tools away from anything you chose to trust.

What to watch

Whether the model keys get used. Inference is expensive and mostly untraceable to the thief, which makes a stolen provider key an unusually liquid asset.

Whether PyPI shortens the gap between a malicious upload and its removal. Forty minutes was fast by historical standards, and it was not fast enough.

And whether TeamPCP surfaces again upstream of something else. The group's demonstrated method is to compromise the tools that other build systems install without asking, which is a small and identifiable set.

Priya Nair’s Verdict Cybersecurity

Forty minutes is the whole argument. That window is too short for review, monitoring or human vigilance to matter, and long enough to catch every pipeline that installs the latest of everything on every run — which is why the count is 434,000 exfiltration events rather than 434,000 machines. The payload ran on every Python invocation, so a build fleet executed it continuously while a human developer might have run it once. Treat the 2,500 with the care CloudSEK itself asks for: it is reconstructed exposure, graded by confidence, and explicitly not a victim count — and CloudSEK sells the monitoring product this research points towards. What I would act on has nothing to do with LiteLLM. Rotate every credential the affected process could reach rather than the ones you think it used, because a harvester takes the environment wholesale. Then look at your model provider keys specifically. They are a new class of secret, they sit in a lot of environments with generous quotas and no ceiling, and unlike a cloud key their theft funds somebody else's inference quietly until an invoice arrives. And then enable a registry cooldown. Nothing else in your toolkit beats a forty-minute window; not being first is the only defence that works against it.

Sources & cross-checks

Primary: SecurityWeek, 12 August 2026 — for CloudSEK's dataset of roughly 434,000 files mapping potential exposure to more than 2,500 organisations; LiteLLM versions 1.82.7 and 1.82.8 being live on PyPI for about 40 minutes; the compromise chain running Trivy → LiteLLM's CI pipeline → the LiteLLM release; CloudSEK's line that “Trivy, then the build system, then the LiteLLM release: one unrevoked token, three tools deep”; the categories of secret taken (package publishing credentials, cloud keys, SSH keys, tokens, environment variables, runtime data and AI provider keys); the named organisations including Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX and Zscaler; and CloudSEK's own caveat that this is “reconstructed exposure” and not “proof that every listed organization was successfully compromised”.
Also primary: The Hacker News — for the precise timing (24 March 2026 from 10:39 UTC, with installations up to 16:00 UTC that day treated as suspect), the Trivy compromise dated 19 March, the actor TeamPCP tracked by Google as UNC6780, the incident's designation CVE-2026-33634, and the specific harvesting of OPENAI_API_KEY and ANTHROPIC_API_KEY alongside Kubernetes tokens and database passwords.
Methodology: Unite.AI — for CloudSEK's confidence grading (high confidence for identifiable corporate domains, repositories, credentials or infrastructure; medium for weaker indicators), its statement that the labels measure “the strength of evidence linking exposed information to an organization, not proof that the organization was breached or that an attacker used what was taken”, its recommendation to rotate broadly rather than selectively, and the disclosure that CloudSEK sells AIVigil, the exposure-monitoring platform this research points towards.
What could not be established: ⚠ No source gives download counts for 1.82.7 and 1.82.8, nor a split between CI/CD pipelines and developer machines. We could not establish how CloudSEK obtained the dataset beyond “its intelligence channels”, whether any of the named organisations has confirmed a compromise, whether the stolen model provider keys have been used, or whether LiteLLM's publishing token has been rotated and its CI hardened. Our own check of the pinned version in the RECATOOLS self-hosting guide was made against the published guide, not against any individual reader's deployment.
Method and limits: Compiled 13 August 2026. The argument that the shortness of the window is what makes the case for registry cooldowns, the reading of model provider keys as a newly liquid class of stolen secret, and the framing of never-expiring tokens plus latest-of-everything installs as the structural fault are RECATOOLS analysis rather than claims by CloudSEK. Organisations that ran LiteLLM in March should follow CloudSEK's own guidance rather than this summary of it.

Cyber Team

Cybersecurity Desk

Cyber Team is RECATOOLS’ cybersecurity desk, covering vulnerabilities, breaches, threat intelligence, and practical security guidance.

View author profile → · Editorial policy

About this byline Cyber Team is a specialist RECATOOLS editorial desk focused on cybersecurity coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy