TeamPCP and Vect: when your security tooling becomes the ransomware entry point

Over five days in March 2026, a criminal group tracked as TeamPCP compromised three tools that organisations deploy specifically to protect themselves: the vulnerability scanners Trivy and KICS, and the language model gateway LiteLLM. The starting point was mundane — a single GitHub personal access token that had been rotated incompletely. Unit 42 puts the blast radius at more than a thousand affected enterprise SaaS environments.

What makes this a July story rather than a March one is what happened next. Sophos has documented that the credentials harvested back then — more than 500,000 sets, pulled from continuous integration environments — are now feeding ransomware deployments by the Vect group. And one detail reshapes the entire calculation for any crisis committee: the Vect 2.0 locker irreversibly destroys every file larger than 128 KB. Paying the ransom returns nothing, because the attacker no longer holds what would be needed to decrypt it either.

Five days in March that are still producing victims

The chain begins somewhere unglamorous: a maintainer credential that survived an incomplete rotation. With it, the attackers reached Trivy's build automation and moved outwards from there. The underlying weakness was catalogued as CVE-2026-33634, carrying a CVSS score of 9.4.

From that foothold the compromise spread in layers. Published version tags on Trivy's GitHub Actions were rewritten, all 35 tags of Checkmarx's KICS action repository were force-pushed, and version 2.3.28 of a second Checkmarx action was poisoned. In LiteLLM, a persistent loader was injected into version 1.82.8. The npm publishing tokens collected along the way then fed a self-propagating worm that Sophos places across more than 48 packages, with later counts running above 60.

The underlying pattern is what deserves attention, because it transfers to any package ecosystem: steal a publishing token, enumerate the packages that token can sign, push a patch version carrying the payload, republish. None of this requires a vulnerability in the customer's own code. It is the same mechanic we saw in the compromise of the Mastra npm packages — except that here the entry point was the security tooling itself.

Why the attackers went after the scanner

Targeting a security tool is not a taunt. It is an efficiency decision. A vulnerability scanner sits in a privileged position inside build automation: it runs often, it runs across nearly every repository, and — decisively — it runs with broad permissions, because it needs to read source, container images and deployment manifests. Compromising it means standing at the point where everything passes through.

The condition that made this work in Trivy is well documented in the continuous integration security literature. An automated workflow configured to react to externally submitted change proposals can end up executing with repository secrets while processing code contributed by a stranger. Once those two properties coincide, the boundary between trusted code and untrusted code dissolves, and repository secrets fall within reach of the running process. Nothing more exotic is required.

The trace this class of compromise leaves behind is characteristic. The observed payload dumped the memory of the automation runner process to recover secrets that are never written to disk, and harvested SSH keys, cloud credentials, Kubernetes tokens and npm tokens. For exfiltration, Unit 42 documents the use of vendor-lookalike domains and, as a fallback, the creation of a hidden repository inside the victim's own organisation using the token the workflow already had to hand. That last detail is what makes the exfiltration blend in: the traffic goes to GitHub, and GitHub was allowed.

A credential archive reverses the order of attack

Here is the development that belongs on the board agenda rather than only in the security team's inbox. In the classic model, a ransomware operator compromises an organisation and then works out what they are looking at. This arrangement inverts that sequence: TeamPCP first assembled an archive of more than 500,000 credentials drawn from continuous integration environments, and Vect then selects its victims from that archive — deliberately, knowing in advance what it is walking into.

The operational consequence is uncomfortable. The interval between compromise and impact stops being measured in days and starts being measured in months. A credential captured in March can be the initial access for a July incident, by which point build system logs have very likely aged out. Any retrospective analysis that only looks back thirty or ninety days will find nothing at all.

Scale compounds the asymmetry. Infosecurity Magazine reports the warnings about the industrialisation of this model: alongside the TeamPCP arrangement came another with the BreachForums forum, which shifts from being a distribution channel to functioning as operational infrastructure, with escrow, affiliate support and key distribution built into the forum itself. In July, the FBI issued a joint advisory specifically covering TeamPCP activity.

Vect 2.0: the flaw that breaks the payment calculation

Analysis by Check Point Research of the Vect 2.0 locker — present in the Windows, Linux and ESXi variants — uncovered an implementation error with permanent consequences. Every file above 131,072 bytes, or 128 KB, is destroyed outright rather than encrypted in a reversible way.

The reason is straightforward to explain without becoming a recipe. The locker splits large files into four chunks and generates a distinct single-use value for each. Only the last one is retained alongside the file; the first three are generated, used and discarded, appearing neither on disk nor in the registry, and never transmitted to the operator. Because the algorithm requires both the key and the exact single-use value for each chunk to reverse the operation, three quarters of every large file are unrecoverable. Including by whoever launched the attack.

The practical reading is summed up well by Help Net Security: in functional terms Vect is not ransomware, it is a data wiper with a ransom note attached. The Hacker News confirms the behaviour reproduces across all three platforms. For a crisis committee this removes one branch of the decision tree entirely: recovery depends wholly on backups, and negotiation offers no genuine technical option.

Why the usual controls did not catch it

It is worth pausing on how an organisation with sound controls could pass through this without noticing.

• Package signing does not help when the attacker holds the legitimate maintainer credential: the artefact is correctly signed, published by exactly the identity that ought to publish it.
• A software bill of materials records which version was installed, not whether that tag was rewritten afterwards. Several affected tags were overwritten while keeping the same version number.
• The build system usually sits outside endpoint telemetry coverage. Ephemeral runners are destroyed on completion, and the evidence goes with them.
• The fallback exfiltration travelled to legitimate vendor-lookalike domains and to the victim's own code platform — two destinations no reasonable egress rule blocks.
• Long-lived secrets held in environment variables are readable by any process on the runner. Being present at the right moment is sufficient.

The same reasoning applies to how organisations should be prioritising genuinely exploitable exposure: security tooling concentrates privilege and trust, and that concentration is precisely what makes it a target.

Detection: what to look for, and over what window

The first move, and it is not a minor one, is to widen the search window. If the organisation ran Trivy, KICS or LiteLLM in production or in build during spring 2026, retrospective analysis needs to reach back to March. Microsoft published specific detection and investigation guidance for the Trivy compromise, and it remains the most useful starting point.

On what to hunt for, these signals tend to yield the most in practice:

1. Use of cloud or service principal credentials from addresses or regions that do not match where build runners normally sit, particularly where the credential was issued before April 2026.
2. Repositories created in the code organisation that no developer recognises. This campaign has been documented using a hidden repository with a fixed name inside the victim's own organisation.
3. Presence of the persistent loader associated with the compromised LiteLLM version in container images built during the affected window.
4. DNS resolution towards domains impersonating known security vendors from build runners, a destination with no functional justification whatsoever.
5. Child processes reading the memory of the automation runner process, a behaviour that forms no part of any legitimate build.

In a Microsoft Defender estate, a starting query over device telemetry to scope the third point would look something like this, adapting the runner naming to your own environment:

DeviceFileEvents | where DeviceName has_any ("runner", "build", "ci-") | where FileName endswith ".pth" or FileName has "litellm_init" | where Timestamp between (datetime(2026-03-01) .. now()) | project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessAccountName | order by Timestamp asc

Treat the output as a hypothesis rather than a verdict: the aim is to narrow down which runners built images during the affected window so they can go to manual analysis. This kind of retrospective sweep against a specific hypothesis is the proper work of a threat hunting exercise, and it rarely goes well when improvised in the middle of an incident.

Defence: what to change in practice

The measures that genuinely reduce exposure to this pattern are specific rather than generic, and none of them is especially expensive:

• Pin external actions and dependencies to immutable commit identifiers rather than version tags. A tag can be rewritten; a commit identifier cannot. This single change would have neutralised most of the propagation.
• Replace long-lived secrets in automation with short-lived credentials issued through identity federation. A token that expires within the hour has marginal value in a stolen credential archive.
• Separate automated workflows that process external contributions from those holding access to secrets. These are distinct functions and should not share an execution context.
• Apply restricted egress on build runners with an allowlist of destinations. A runner that only needs to reach three registries should not be able to resolve an arbitrary domain.
• Verify that backups are immutable and that restoration has actually been tested against large volumes. Against a locker that destroys anything above 128 KB, backup is not a fallback plan — it is the only plan.
• Bring security tooling vendors into the critical third-party inventory. They are frequently left outside the formal third-party risk management process precisely because they are security vendors.

One governance point tends to get settled too late: rotating 500,000 credentials is not a realistic exercise for anyone, but identifying which of your own were exposed during the March window is entirely achievable — provided a decent secrets inventory exists. Organisations without one will find that containment work begins by building it.

What this means under NIS2 and DORA

For entities within scope of NIS2, this case falls squarely within the supply chain security obligations of Article 21, which requires organisations to consider the specific vulnerabilities of each direct supplier and the quality of their development practices. A security tooling vendor embedded in build automation is, for these purposes, a direct supplier holding privileged access.

In financial services, DORA raises the same question with sharper edges, because the register of information on ICT third-party arrangements requires documenting dependencies many organisations never treated as contractual. An open-source scanner embedded in build automation appears in no contract, yet it is a real functional dependency with access to production secrets.

On notification, the trigger to assess is not the supplier compromise in March but the moment at which you determine that your own credentials were exposed and may have been used. That determination is what starts the clock, which is why incident response and the compliance function need to work from the same timeline from day one.

What this case leaves behind

There is an understandable temptation to read this as an open-source problem, and it is not. The same pattern works against proprietary software the moment a publishing credential falls into the wrong hands. What has changed is something else: a market now exists that converts stolen supply chain access into ransomware deployments on an industrial basis, with a division of labour between those who steal and those who extort.

The second reading is less comfortable. For years, the argument for investing in security tooling inside build automation was that it reduced risk. That remains true, but it is no longer free: this tooling is now privileged attack surface and has to be treated accordingly, with the same demands around version pinning, ephemeral credentials and monitoring that we apply to any component with access to production.

The third point is the one to internalise fastest. With Vect on the table, the question "do we pay?" no longer has a useful technical answer. The only variable still under your control is whether the backups survive a full restoration. Better to find that out before you need to, not during. Organisations without clarity on their exposure across the March 2026 window will find a managed SOC with retrospective analysis capability the shortest route to an answer, and the accumulated lessons from the digital supply chain all point the same way.

This article includes detection queries and hardening measures for defensive purposes. Validate them in a test environment before applying them in production and adapt them to your own architecture: runner naming, paths and time windows vary by organisation.