An organization named in the TeamPCP credential archive told Kevin Beaumont its exposure was handled and everything had been rotated. He checked their responsible disclosure policy, confirmed it permitted credential testing, and tried them.
That is one post, one organization, and Beaumont has not named it. Treat it as a single data point. But it is a data point about the distance between a closed remediation ticket and a revoked credential, and there is a second one, from the first victim in the chain.
What the August disclosures added
In July I wrote about the TeamPCP credential archive and argued that your exposure to the VECT ransomware partnership came down to whether your cloud tokens were in it. In August the archive acquired a size and a victim list.
- CloudSEK, August 11: more than 2,500 organizations and roughly 434,000 CI/CD pipelines.
- Hudson Rock, August 12: a 153 GB archive of 433,909 files, obtained and analyzed, with 118,829 CI runner dumps attributed to 2,488 corporate domains.
Read CloudSEK's caveat before the headline. Its figures "describe reconstructed exposure" and "should not be read as proof that every listed organization was successfully compromised or that every credential was stolen". Appearing in the dataset is a reason to investigate, not a confirmed breach. Hudson Rock's post carries no equivalent hedge, which is worth knowing when you compare the two lists.
Both firms name the organizations they matched. I am not repeating those names here. A reconstructed exposure match is not a confirmed compromise, and that distinction does not survive being turned into a list of company names.
Neither firm published the archive. Hudson Rock integrated it into its Cavalier platform and runs a per-victim disclosure process; CloudSEK runs a public domain lookup. Whether the corpus is circulating more widely is unclear, and the people closest to it disagree:
- Hudson Rock's Alon Gal told Help Net Security it "is not leaked anywhere at the moment and is not circulating widely".
- Beaumont, the same week, said "terabytes of creds are circulating online now".
- SOCRadar observed a broker on Telegram offering a bundle of LiteLLM, Trivy and CanisterWorm data at over 150 GB compressed, which it reads as one seller holding the collection rather than as wide circulation.
That distinction sets how fast you should expect the credentials to be used. It does not change whether they were copied in March.
The window is wider than the one everyone reported
This corrects my July post as much as anyone else's coverage.
The campaign was reported, as the LiteLLM breach, built around the roughly 40 minutes on March 24 when the poisoned packages sat on PyPI. SOCRadar analysed the timestamps on the 2,188 organization records and found the exposure sitting earlier:
- Earliest collection record: March 19, 18:05 UTC
- Latest: March 24, 20:09 UTC
- Records showing collection activity before March 24, which is before the LiteLLM packages went live: 2,085 of 2,188, or 95 percent
SOCRadar reads that timing as pointing to the upstream Trivy compromise rather than the LiteLLM install window, and SecurityWeek framed it the same way on August 14. SOCRadar's phrasing is the one to keep: the 40 minutes was the closing act, not the whole play.
So a log search scoped to March 24 was scoped too narrowly. That date still matters if you installed the poisoned releases, but most of the exposure predates it.
Trivy's own remediation is the case study
One reason rotation fails is documented in the first victim.
Aqua revoked credentials on March 1, covering the automation identities investigators knew were compromised. CloudSEK's timeline, read alongside Aqua's chronology and the NVD record for CVE-2026-33634, describes what followed. Activity continued through a different user and token. The token seen during the March 1 period reappeared in malicious activity on March 19. On March 22, a service account nobody had considered compromised touched 43 repositories in another organization. CloudSEK reconstructs roughly 20 days in which an automation token stayed usable after rotation, and flags that figure as its own reconstruction rather than a verified forensic interval.
Flare puts it more bluntly: "Aqua rotated credentials but missed some. The leftover access held."
Credentials were not invalidated simultaneously, which left at least one identity usable while replacement secrets were being issued. CloudSEK's inference from that, stated as an inference: if a surviving identity could reach the newly rotated secrets, rotating individual tokens would not necessarily remove the intruder. Run as a sequence of token replacements rather than as one containment event across every identity in the release path, rotation risks handing the attacker its own output.
"We rotated everything" and "the credentials no longer work" are different claims. Only the second is testable, and Beaumont's is the only public test of it I have seen.
The half nobody can reach
The second failure mode belongs to the disclosure model rather than to any victim.
Hudson Rock resolved 118,829 runner dumps to named domains, and is explicit about what it could not resolve: a large number of files "contain highly sensitive secrets but completely lack clear organizational attribution." Those organizations have live secrets in the corpus and no way to learn it. GitGuardian put the consequence plainly on August 14: neither firm can notify a company it cannot name, responsible disclosure needs an address, and a generically configured CI runner does not leave one.
So absence from a lookup tool is weak evidence. If you ran the affected Trivy actions or LiteLLM 1.82.7 or 1.82.8 in the window, your own pipeline records answer the exposure question, not whether a researcher could resolve your runner to a domain.
Why this is Gap 2
A stolen AWS key, repository token, Kubernetes service account or model provider key authenticates through the same interface the pipeline uses, from infrastructure that looks like automation, performing operations the identity is authorized to perform. The cloud provider records a successful API call from a recognized principal. Authentication succeeds. No exploit is involved anywhere in the follow-on activity.
Where the credential is still valid, the outcome of the authentication tells you nothing, because the outcome is success. Signals do remain at the sign-in, an unfamiliar network or an unusual client among them, and they are worth alerting on. The durable ones are behavioral: a service account reaching a resource it has never touched, or a retired token still being presented and accepted. Each is individually explainable, and in sequence they are not.
What to do this week
Verify the rotation rather than the ticket. For each credential class the affected process could reach, confirm the old value is now rejected:
- Cloud keys, and anything readable from the instance metadata service
- Repository, registry and package-publishing tokens
- SSH keys and Kubernetes service accounts
.envcontents, database URLs and AI provider keys
Flare's framing is the one to take into a remediation review: treat rotation as an inventory exercise, not an incident task. It only works if you know the full set, and as CloudSEK notes, quiet logs are not evidence that a credential was never copied.
Then widen the hunt to February 27 through late March:
- Pipeline service accounts authenticating to production
- Repositories named
docs-tpcportpcp-docsinside your own organization - Any token issued before April 2026 that is still in use
The Gap 2 chapter in Mind Your Attack Gaps covers the same failure mode through the Scattered Spider help desk chain, where the credential was legitimate and the sign-in was clean. At Vectra AI we model how an identity behaves after it authenticates, across cloud, identity and network, which is where a valid stolen token becomes visible.
The archive dates from March. Whether it still matters in September is a question your credential store can answer.
---
Disclosure: Vectra AI appears in CloudSEK's dataset. A compromised Trivy GitHub Action ran in a limited set of our CI/CD workflows on March 19 and 20, exposing build metadata and short-lived per-job credentials. We identified it internally, replaced the tooling and rotated the relevant credentials within hours, and re-checked our records against CloudSEK's findings in August. Our full statement is here.