Update September 1, 2026: Three research disclosures in August put names and numbers to the credential archive described below. One of them corrects part of this post.
CloudSEK published a reconstructed victim dataset on August 11, 2026: 2,500+ organizations and roughly 434,000 potentially exposed CI/CD pipelines, with organization-level matches named in the report. 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. Hudson Rock disclosed on August 12 that it had obtained and analyzed a 153 GB archive of 433,909 files, attributing 118,829 CI runner dumps to 2,488 corporate domains.
CloudSEK is explicit that its figures describe reconstructed exposure and are not proof of compromise. Hudson Rock's post carries no equivalent caveat. Both firms run a domain lookup, CloudSEK's here, and neither published the archive itself. Note also that CloudSEK's 434,000 pipelines and the FBI FLASH figures cited below, 500,000+ credentials from 10,000+ pipelines, count different things. Neither supersedes the other.
Correction on scope: This post framed the campaign around LiteLLM. SOCRadar analysed the timestamps on the 2,188 organization records on August 13, finding the earliest at March 19, 18:05 UTC and the latest at March 24, 20:09 UTC. For 2,085 of those records, 95 percent, collection activity appears before the malicious LiteLLM packages reached PyPI on March 24. 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. If you are searching logs, search February 27 through late March, not only the 40 minutes on March 24. That window still matters if you installed the poisoned LiteLLM releases, but on SOCRadar's reading it accounts for a small share of the exposure.
Correction on versions: Two malicious LiteLLM releases were published, 1.82.7 and 1.82.8, not one. In 1.82.7 the payload sat in litellm/proxy/proxy_server.py and required the module to be imported. 1.82.8 kept that payload and added litellm_init.pth, which executes at Python interpreter startup with no import required. The "What to check now" section below has been updated to cover both.
Correction on the CVE: This post says TeamPCP exploited CVE-2026-33634 to overwrite Trivy's workflow versions. Trivy traced the initial credential theft to a vulnerable pull_request_target workflow abused on February 27, and the NVD record for CVE-2026-33634 explains why the March 1 rotation did not terminate the intrusion rather than how the intrusion began.
On enforcement: The Australian Federal Police charged two Western Australian men on August 27, 2026, following a joint AFP, FBI and WA Police operation. The charges are allegations and have not been tested in court. The credentials in the archive are unaffected either way.
A new post covers what the August data says about credential rotation: The Credentials Were Rotated. They Still Worked.
--
On April 28, 2026, Check Point Research published a technical analysis of VECT 2.0's encryption (CPR-2026-0428). The finding is straightforward: VECT's encryption is broken in a specific way. For any file larger than 128 KB, the process that should generate a unique encryption key for each file chunk reuses a single value instead, and only that final value is saved. The first three-quarters of every large file become permanently scrambled. Not recoverable by the victim. Not recoverable by VECT either.
Paying the ransom does not restore large files. The decryption key is real. The data loss happens before the key is even relevant.
That finding matters on its own. It is also downstream of a more structural problem that has received considerably less attention.
How targets get selected
Most ransomware operations follow the same targeting sequence. A group identifies an organization, builds or buys access, then deploys. Target selection happens before access exists. Your exposure to a given ransomware group is a function of whether that group has decided to pursue organizations like yours.
VECT doesn't work this way. Neither does its supply chain partner, TeamPCP.
The FBI IC3 FLASH-20260702-01, published July 2, 2026, documents a campaign built on scale rather than targeting. Between February and March 2026, TeamPCP tampered with four widely used open source software packages that organizations rely on for development and security scanning:
- Trivy, a tool used to scan containers for security vulnerabilities: TeamPCP exploited a vulnerability (CVE-2026-33634) to overwrite 76 of 77 versions of Trivy's automated workflow with a malicious copy, using a stolen developer credential that had write access to the code repository.
- Checkmarx KICS, a tool that scans infrastructure code for misconfigurations: TeamPCP similarly overwrote 35 versions. They also used each victim organization's own automation credentials to create a hidden repository called
docs-tpcpinside the victim's GitHub account. - LiteLLM v1.82.8, a software library with approximately 95 million monthly downloads: TeamPCP added a file called
litellm_init.pthto the installation. Files with the.pthextension are automatically read and executed by Python every time it starts, regardless of what software you're actually running. This gave TeamPCP persistent code execution on any machine that had installed the package. - Telnyx Python SDK versions 4.87.1 and 4.87.2: a three-stage remote access trojan, meaning software that quietly gives attackers control of the infected machine.
TeamPCP is the same group behind the Shai-Hulud supply-chain worm, which uses compromised packages to spread automatically through developer environments and CI/CD pipelines. The February-March 2026 campaign against Trivy and LiteLLM used the same underlying mechanism: trusted package, automatic execution, credential harvest. Shai-Hulud Part 2 covers the May 2026 TanStack campaign, where the worm went further and generated valid cryptographic signing certificates to pass package verification checks.
The result: 500,000+ stolen credentials from 10,000+ CI/CD (continuous integration and deployment) pipelines, the automated systems that build, test, and deploy software. AWS, Azure, and GCP tokens. Kubernetes secrets. Container registry credentials. GitHub and GitLab access tokens.
TeamPCP didn't select targets. It selected packages. By March 2026, the credential archive existed. VECT went through it and selected ransomware victims from the inventory.
Target selection happened after access, not before.
"Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won't stop there."
"We will chain these compromises into devastating follow-on ransomware campaigns."
What this changes about ransomware exposure
The conventional ransomware planning exercise asks: "What would an attacker need to do to get into our environment?" That question assumes the attacker hasn't already decided. The TeamPCP model means that question may already have been answered, months ago, by a routine package install in a development pipeline your team has since forgotten about.
Sophos Counter Threat Unit confirmed at least one VECT deployment using TeamPCP-sourced credentials. The FBI warns that the stolen credentials "will be weaponized long after the initial compromise." Your VECT exposure isn't determined by whether the group is targeting your sector. It's determined by whether your cloud tokens are in that archive.
Why it doesn't appear in your logs
This is Gap 3: Movement isn't visible.
The litellm_init.pth persistence file runs automatically on every Python startup in the affected environment. The software package manager records an install. The CI/CD pipeline records a workflow execution attributed to a known service account. The cloud provider records an authenticated API call from a recognized identity. Three audit logs, three Security Operations Center (SOC) tickets, one breach.
No single log shows the path from compromised package to production cloud environment. Piecing it together requires correlating the install timestamp, the workflow run, and the outbound API call against a list of affected package versions that most organizations don't maintain and most security monitoring systems don't automatically check against. The same fragmented-log problem appeared in the Anodot/Snowflake supply chain incident in April 2026, where tokens stolen from a SaaS integration provider were reused across multiple customer environments, with each system validating its own piece of the activity and none connecting them. The VECT/TeamPCP case runs the same pattern through the CI/CD layer rather than the SaaS integration layer.
The Checkmarx KICS vector adds another layer. TeamPCP used the victim's own automation credentials to create docs-tpcp inside the victim's GitHub organization. The repository creation event appears in GitHub's audit log attributed to the victim's service account. Nothing looked wrong. That's Gap 1.
The competence gap inside the operation
Check Point's analysis of VECT 2.0's code found clear signs of amateur development: security-evasion code that is written but never actually runs, an obfuscation layer that undoes itself, configuration flags that appear to be flexible but are actually hardcoded, and broken decorative text in the program. The encryption flaw that makes VECT permanently destroy its victims' files fits the same pattern. The malware is amateur work.
The infrastructure surrounding it is not. VECT's affiliate program includes Monero (a privacy-focused cryptocurrency) escrow accounts, integration with BreachForums, tiered commissions, and dedicated negotiators who handle ransom discussions. The BreachForums mass-affiliate model, formalized April 16, 2026, gives operators access to this infrastructure without building their own. TeamPCP's credential archive substitutes for technical exploitation skill: you don't need a vulnerability in the target's defenses if you already have their cloud tokens.
This matters for defense planning. Endpoint security software running correctly will identify the malware. The delivery path through software supply chains and automated pipelines will not trigger it. Detection isn't broken. It's incomplete.
What to check now
If your environment ran any of these packages before April 2026, treat your pipeline cloud credentials as compromised until you can confirm otherwise:
- LiteLLM, specifically v1.82.8. Also search for
litellm_init.pthin Python installation directories on any machine that ran LiteLLM during February and March 2026. - Trivy GitHub Action, any version pinned to 0.76.x or 0.77.x tags during that window.
- Checkmarx KICS GitHub Action, any of the 35 affected tags.
- Telnyx Python SDK 4.87.1 or 4.87.2.
Search your GitHub organization's repository list for docs-tpcp. Its presence means TeamPCP used your own automation credentials to create it. Rotate cloud credentials (AWS, Azure, GCP service accounts, container registry tokens, GitHub and GitLab access tokens) issued before April 2026 in affected environments. Review AWS CloudTrail, Azure Monitor, and GCP Cloud Audit Logs for API calls from pipeline service accounts to production environments during February through April 2026, particularly any calls that predate known deployments.
The Gap 3 chapter in Mind Your Attack Gaps covers the hybrid-cloud breach case study, where the same fragmented-log problem runs across a different attack chain. At Vectra AI, we model cross-environment movement across identity, cloud, and SaaS without depending on correlation across three separate audit systems. The TeamPCP/VECT campaign is a clear example of why single-environment visibility doesn't cover this class of attack.
The credential archive exists. If your pipeline ran the affected packages before April 2026, the right question now is not whether you could be targeted but whether your tokens are already there.