Three tools deep on one credential
The attack chain behind this compromise runs through three separate open-source tools connected by a single point of failure. TeamPCP, a threat actor group with a track record of high-profile open-source compromises, first breached Aqua Security's Trivy vulnerability scanner using an automation token that had been rotated at some point but never fully revoked. That gap left roughly a 20-day window in which attackers could force-push malicious code over trusted, already-published version tags, meaning organizations pulling a specific Trivy version they had used safely before could suddenly receive a tampered build. Rotation without revocation is a common half-measure in credential hygiene, one that looks complete on a checklist while leaving the old credential fully functional for anyone who already holds it.
LiteLLM, the open-source Python library and proxy server that sits in front of large language model APIs for a huge number of AI engineering teams, installed Trivy inside its own CI pipeline without pinning it to a vetted release from the system package manager. That single configuration choice meant the compromised scanner flowed automatically into LiteLLM's build process, with no human reviewing the incoming version before it executed. As CloudSEK researchers put it, describing the chain: Trivy, then the LiteLLM build system, then the LiteLLM release, one unrevoked token, three tools deep. Each hop in that chain looked like normal automation doing exactly what it was configured to do.
Forty minutes, then months of exposure
The poisoned build produced two malicious LiteLLM versions, 1.82.7 and 1.82.8, published to PyPI. The packages contained a malicious Python .pth file, a mechanism that executes automatically at Python interpreter startup and, critically, bypasses the --ignore-scripts protection many security-conscious teams rely on to block arbitrary code execution during package installation. The packages were live on PyPI for approximately 40 minutes before removal, a window short enough that most manual monitoring processes would never have caught it in time.
That window sounds survivable until you account for how modern build infrastructure actually works. CloudSEK's assessment was direct: a 40-minute package window can create a months-long incident, because automated build systems execute at machine speed, rapidly copying malicious artifacts across scheduled jobs, dependency resolvers, ephemeral CI runners, and developer environments that pull dependencies without human review at each step. A vulnerability window measured in minutes translated into a compromise footprint measured in hundreds of thousands of pipelines.
What actually got exfiltrated
The malicious code harvested a broad set of credentials from every environment it touched: SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, .env files and CI/CD secrets, and, notably, LLM API keys and AI gateway credentials. That last category is a direct consequence of what LiteLLM is used for. Organizations running it as an AI gateway had their model provider credentials sitting exactly where this compromise reached, which means the blast radius extended into whatever downstream systems those API keys were scoped to access.
Exfiltration used encrypted delivery, AES-256 and RSA-4096, to typosquatted domains, or in some cases uploaded stolen data as release assets to the victim organization's own GitHub account, a technique that hides exfiltration inside infrastructure the victim already trusts and monitors less closely than external traffic. CloudSEK's reconstructed dataset put the affected population above 2,500 organizations and more than 434,000 CI/CD pipelines, with named enterprises including Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, FedEx, and Volkswagen.
AI infrastructure inherited open-source's oldest problem
The organizations exposed here were not using some exotic or unvetted tool. LiteLLM is widely adopted specifically because it lets engineering teams route requests across multiple LLM providers through one consistent interface, and Trivy is one of the most trusted open-source vulnerability scanners in the industry, embedded in countless CI pipelines precisely because teams believed it made their builds safer. The compromise exploited that trust directly: the scanner meant to catch vulnerabilities became the vulnerability, and the tool most likely to be waved through code review without a second look was exactly the one that carried the payload.
This is the same unpinned-dependency, transitive-trust problem that has plagued traditional software supply chains for years, now running through the AI tooling stack that most engineering organizations adopted in the past 18 months with far less mature governance than their core application dependencies received. Teams that would never let an unpinned base image into a production Dockerfile routinely let AI framework dependencies update automatically, because the tooling is new enough that supply chain discipline has not caught up to adoption speed.
The audit this forces on every AI gateway deployment
Any organization running LiteLLM should treat versions 1.82.7 and 1.82.8 as confirmed-malicious and rotate every credential the proxy had access to, not just check whether the specific version is still installed. That includes LLM provider API keys, cloud credentials in the same environment, and any CI/CD secrets the build pipeline could reach, because the FBI's July advisory specifically warned that harvested credentials from this campaign would likely see delayed, affiliate-driven exploitation well after the original news cycle closed. Treating the exposure window as closed simply because the malicious packages were pulled is the mistake this advisory was written to prevent.
The broader lesson is a governance gap most CTOs have not closed yet: AI infrastructure components, gateways, orchestration frameworks, and observability tools adopted during the recent build-out deserve the same dependency pinning, credential scoping, and supply chain review that core application infrastructure gets. A one-token failure three tools removed from the actual target compromised 2,500 companies specifically because that governance layer had not been built out yet for the AI stack.
