A security scanner was the way in: the LiteLLM package hijack that put thousands of companies' secrets at risk

What many in the industry are calling one of the most alarming software supply-chain stories of the year has a cruel twist at its centre: the thing that let attackers in was a security scanner, the exact kind of tool meant to keep them out. The target was LiteLLM, an open-source gateway that thousands of companies use to route their applications to different AI models. The attack itself happened back in March. What changed this week is that the stolen data came to light, and researchers could begin to measure how far it spread.

What actually happened?

According to the security firms that reconstructed the incident, the chain worked like this:

• A threat group tracked as TeamPCP first compromised the build pipeline of Trivy, a hugely popular open-source vulnerability scanner. LiteLLM used Trivy inside its own CI/CD pipeline.
• That gave the attackers read access to LiteLLM's build environment, where they lifted LiteLLM's own PyPI publishing tokens, the keys that let you push new versions of the package.
• With those keys they published two malicious releases, versions 1.82.7 and 1.82.8, to PyPI. Endor Labs notes LiteLLM pulls around 95 million downloads a month, so the potential blast radius was large.
• The packages went live on 24 March 2026 at 10:39 UTC. That short window is the whole story of why "only 40 minutes" was still a disaster.

The key facts, from the researchers' write-ups:

• Who: threat actor TeamPCP, which researchers say had already compromised Trivy and a second scanner, KICS.
• How: a poisoned security scanner in LiteLLM's CI pipeline, used to steal LiteLLM's own package-publishing tokens.
• What shipped: LiteLLM 1.82.7 (a hidden payload in proxy_server.py) and 1.82.8, which kept that payload and added a global auto-run hook (see below).
• When: live on 24 March 2026; LiteLLM says PyPI quarantined the packages after about 40 minutes, though some analysts put the window at up to roughly three hours. The scale only became clear this week.
• Scale: Hudson Rock, which examined the stolen archive, describes 153GB of data and 118,829 CI/CD runner dumps tied to 2,488 corporate domains. CloudSEK, reconstructing the exposure, estimates more than 2,500 companies and around 434,000 CI/CD pipelines were potentially affected. Both stress these figures reflect exposure, not confirmed breaches.

How could 40 minutes expose so many companies?

Two design choices in the malware, and one in modern software, did the damage.

First, the escalation. Version 1.82.7 hid its payload inside proxy_server.py, so it ran when LiteLLM's proxy code was used. Version 1.82.8 went much further: on top of that payload, it dropped a .pth startup file into Python's site-packages, a hook that Python runs on every interpreter start, whether or not LiteLLM is imported. As researchers at Cycode and Snyk describe it, that means a Jupyter notebook, an Ansible run, a test suite, even pip itself, any Python process on the machine, would trigger the malware.

Second, where it landed. A huge share of installs happen not on laptops but inside automated CI/CD pipelines, the systems that build and deploy software. Those runners are stuffed with exactly what an attacker wants: cloud keys, Kubernetes tokens, GitHub and GitLab access tokens, SSH keys, package-publishing credentials and AI provider keys. The malware harvested them and sent them to an attacker-controlled server, and where that failed it fell back to a striking trick: creating a public GitHub repository inside the victim's own account and uploading the stolen data there as a release file.

So a short window on a hugely popular build dependency translated into secrets captured from tens of thousands of build runs, Hudson Rock counted nearly 119,000 CI/CD runner dumps in the archive. That is the difference between a poisoned app that harms one user and a poisoned build tool that harms everyone downstream of it.

Whose data is in there, and how bad is it?

Here caution matters. The reconstructed dataset lists credentials tied to a long roster of well-known organisations, with reporting naming AWS, Nvidia, Samsung, Cisco, Salesforce, ServiceNow, Siemens, Deloitte and others. But appearing in the dataset is not the same as being hacked. It means a CI pipeline associated with that organisation, or a contractor, employee or open-source project connected to it, leaked secrets during the window. As CloudSEK put it, the totals are "not a victim count", a high-confidence match reflects the strength of the exposure signal, not proof of a successful compromise. It is a reason to rotate credentials, not evidence that any named company's core systems were breached. The figures are security firms' estimates from the leaked data, not an official audit.

What is not in doubt is the class of data involved: live cloud and infrastructure credentials. Those are the keys to production systems, which is why the security industry is treating this as serious even months after the packages came down.

Why "your scanner became the weapon" is the real lesson

The detail that has the software world talking is the entry point. Teams add scanners like Trivy precisely to harden their pipelines, and here a scanner was the soft underbelly: compromise the tool everyone trusts to check their code, and you inherit the trust of everyone who runs it. It is a supply chain inside a supply chain, Trivy fed LiteLLM, and LiteLLM fed thousands of companies, so one upstream compromise cascaded two levels down. It is the same lesson our reporting on the npm ecosystem's supply-chain risk and on the security bill coming due for fast, AI-assisted development keeps circling: the danger is rarely the code you wrote, it is the code you trusted.

Is it over, and what should teams do?

Not entirely. The FBI issued a FLASH advisory (FLASH-20260702-01) in July warning that harvested credentials could still be weaponised for follow-on attacks, and CloudSEK says the wider threat "is still live". LiteLLM itself acted quickly once the March incident was found, publishing a security notice and working with PyPI to pull the packages, and the malicious versions are long gone. But because the real currency stolen was credentials, the exposure outlives the packages. The guidance applies with force: any organisation that installed LiteLLM around 24 March, especially in CI, should assume secrets on those runners were exposed and rotate them, cloud keys, tokens and API keys included.

Frequently asked questions

Was LiteLLM itself malicious?

No. LiteLLM is the victim. Attackers compromised a scanner in its build pipeline, stole its publishing keys and impersonated it on PyPI. LiteLLM published a security notice and helped get the malicious versions removed.

Which versions were affected?

LiteLLM 1.82.7 and 1.82.8 on PyPI, live from 24 March 2026 for a short window (about 40 minutes by LiteLLM's account, up to roughly three hours by some analyses). If you pinned or installed those specific versions, particularly in an automated pipeline, treat any secrets on that machine as exposed.

Does being named in the dataset mean my company was breached?

Not necessarily. It means credentials linked to your domain appeared in the leaked archive, a sign to rotate secrets, not proof that core systems were compromised. As CloudSEK stresses, the totals are "not a victim count", and the company figures are security firms' estimates, not an official audit.

Why is such a short window such a big deal?

Because the malware ran on almost any Python process (via a .pth startup hook) and because most installs happen inside CI/CD pipelines full of live credentials. A brief window on a widely used build dependency still touches a huge number of automated runs.