Tech and AI
A forty minute window in one AI package exposed credentials from 434,000 build pipelines
By Staff Writer | 13 August 2026
Two security firms published research this week showing that compromised versions of LiteLLM, downloaded from the official Python package repository in March, scraped access secrets from more than 2,500 organisations.
LiteLLM is an open source tool that sits between applications and the various artificial intelligence models they call, and it is widely embedded in software delivery pipelines. For a window of about forty minutes in March, two versions of it published at the package's official location in the Python Package Index carried code that read the memory of the machines it ran on, scraped the contents and sent them to a channel the attackers controlled.
Research posted this week by CloudSEK and by Hudson Rock sets out what came out. CloudSEK describes cloud keys, source code repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables and model provider keys, taken from more than 2,500 organisations and from 434,000 continuous integration and delivery pipelines. Organisations the researchers place in their high confidence list include Nvidia, Amazon Web Services, Cisco, Samsung, Siemens, Volkswagen, the London Stock Exchange Group, BT Group and Vodafone.
The two affected releases are versions 1.82.7 and 1.82.8. Any organisation that ran either is being told to treat every secret reachable from that environment as compromised.
How one package reached thousands of firms
The compromise did not begin with LiteLLM. It followed an earlier supply chain attack on Trivy, a vulnerability scanner in common use, which the LiteLLM build process installed automatically. Other software infected in the same campaign includes KICS and the Telnyx Python software development kit. A group calling itself TeamPCP claimed the attack, and researchers have largely corroborated the claim.
The detail worth dwelling on is what allowed the first breach to keep working. According to CloudSEK, the Trivy developers rotated an automation token but did not fully revoke it, and the gap lasted twenty days. That left the attackers close to three weeks in which they could force malicious code into third party builds that relied on the scanner.
The key takeaway is how supply chains have evolved to make a single upstream breach affect thousands of companies simultaneously.
Alon Gal, co-founder and chief technology officer, Hudson Rock
Why rotation notices are being ignored
Kevin Beaumont, an independent security researcher who examined the data, said he had confirmed it against multiple affected organisations. "I've confirmed the data is legit by the way, multiple victim orgs," he wrote, adding that the data held a large volume of sensitive material from those organisations.
He also described testing credentials at one large organisation which had told him it had rotated everything and that the disclosure amounted to nothing. Its own disclosure policy permitted the test. Almost every credential still worked.
Hudson Rock has warned that a further problem sits underneath the named list. Many pipelines are configured generically, so the captured variables contain live database passwords, third party interface keys and cloud credentials with no company email address, no custom domain and no internal server name attached. Organisations in that position have active secrets in the data and no way of recognising them as theirs.
What the firms are telling organisations to do
Both firms are urging anyone who ran the affected versions to rotate credentials across their pipelines rather than selectively, on the assumption that any secret the LiteLLM environment could reach has gone. That means invalidating and reissuing cloud keys, Kubernetes service account tokens and repository access tokens, and reviewing logging and outbound traffic controls. Hudson Rock has extended the advice to any organisation running model proxy infrastructure or third party pipeline scanners, whether or not it believes it used the package directly.
The uncomfortable part for anyone running a delivery pipeline is that none of the victims made a decision to trust the attackers. They trusted a scanner, which trusted a build, which trusted a package, and forty minutes was enough.