AI SecurityVulnerability ManagementIncident Response
The archive surfaced on Thursday: 153GB, 433,909 files, and 118,829 CI runner dumps traced to 2,488 corporate domains. Hudson Rock obtained and analysed it, and the list of organisations whose build secrets are sitting inside reads like a vendor directory — AWS, Nvidia, Samsung, Cisco, Salesforce, ServiceNow, Siemens, FedEx, Volkswagen, and hundreds more, per CloudSEK's reconstruction.
All of it came from a package that was live on PyPI for about 40 minutes, five months ago.
"A window of roughly 40 minutes in which the LiteLLM dependency was hacked led to over 430,000 instances in which millions of secrets were harvested," Hudson Rock's co-founder said of the haul. That sentence is worth sitting with, because it inverts how most teams still budget their response time.
LiteLLM was never the target. It was the delivery vehicle, and it was reached through two hops that nobody was watching.
It started at Trivy, the open-source vulnerability scanner. An automation token leaked, was rotated — but not fully revoked — and left roughly a 20-day window open. On 19 March 2026, TeamPCP, a crew that emerged in late 2025, used it to force-push a poisoned Trivy build that looked entirely legitimate downstream.
LiteLLM's own CI pipeline then installed Trivy unpinned, from the system package manager, on every run. It pulled the compromised scanner automatically, the scanner infected the build system, and the build system produced malicious LiteLLM 1.82.7 and 1.82.8, published to PyPI on 24 March. CloudSEK's summary of the chain is the cleanest description of the whole class of problem: Trivy, then the build system, then the LiteLLM release — one unrevoked token, three tools deep.
Note that a security scanner was the initial access vector. The tool inventorying everyone's dependencies had no one inventorying it.
The stealer — tracked as SANDCLOCK — did not rely on an install hook. It used a .pth file, which Python executes automatically at interpreter start, with no import required. That detail matters operationally: .pth execution sails straight past --ignore-scripts, the flag most hardened pipelines rely on to neuter malicious packages at install time.
Once running, it escalated to root and swept for exactly what a build agent holds:
.env files, database passwords, Slack signing secrets, Salesforce client secretsCollected data was encrypted with AES-256 under a hard-coded RSA-4096 key and exfiltrated — in some cases uploaded as release assets to public GitHub repositories. The concentration in individual victims is the part that should worry anyone running shared runners: CloudSEK counted 327 secrets across 1,900 runs at Cisco, and 3,459 secrets in the X Corp dataset.
One caveat deserves emphasis, and the researchers make it themselves: appearing in this dataset is evidence of exposure, not proof of compromise. Nobody has shown that every listed organisation was breached, or that every harvested credential was ever used.
The compromise happened in March. The credentials became public in August. That gap is the story's real lesson, and the FBI flagged it in advance — FLASH advisory FLASH-20260702-01, issued 2 July, warned that affiliated actors would likely weaponise harvested credentials long after the original intrusion window closed.
So the honest question for any security team this week is not "were we running LiteLLM 1.82.7 in March?" It is:
Most teams can answer (1) with effort. Very few can answer (4) at all.
Cloud credentials have a mature blast-radius story: IAM boundaries, short-lived workload identity, CloudTrail, anomaly detection. A leaked AWS key is a bad day with a well-rehearsed runbook.
An LLM provider key usually has none of that. It is typically a long-lived static string with no scope, no per-agent restriction, no egress control, and no usage record beyond a billing dashboard. Whoever holds it can call any model, at any volume, with any prompt, from anywhere — and the first signal is an invoice. That is why CloudSEK's framing of AI infrastructure as a high-value junction between data, identity, compute, and autonomous action lands: these systems now sit on the same tier as cloud IAM while being governed like a SaaS trial.
You cannot prevent an upstream maintainer's token from leaking. What you can decide, in advance, is how much a stolen key from your environment is actually worth to whoever ends up holding it.
That is the job Obiguard Governance AI does. Every model call routes through a governed path rather than straight from a runner to a provider endpoint, and allow-lists bind each credential to a specific envelope: exactly which model IDs an agent may call, which tools it may invoke, which external domains it may reach through retrieval or browser tools, and which users or service accounts may invoke it at all. A key lifted from a CI runner and replayed against an unapproved model, or used to push data to an unregistered endpoint, is blocked before the request leaves — not reconstructed from a bill next quarter.
The audit ledger closes the detection gap that made this leak a five-month problem. Every prompt, response, and tool call is recorded with the model, the agent ID, and the initiating user or service account, timestamped to the millisecond and cryptographically immutable — no edit, no delete. It streams to Splunk, Sumo Logic, Datadog, S3, or any SIEM by webhook, so "which of our AI keys was used, by whom, against what, in March" is a query rather than an archaeology project.
For the dependency half — did we ship 1.82.7, and what else depends on it — Obiguard SOC scans every connected repo on every push and once a day, and reports cross-repo blast radius before you upgrade, so the answer covers the whole estate rather than the one repo someone thought to check.
The next poisoned package will also be live for about 40 minutes, and you will also hear about it months later. Design for that. Talk to us about scoping your AI credentials before someone else does it for you.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →