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.