Trivy / TeamPCP - How to check if you're exposed

Last week’s TeamPCP campaign was a reminder of how much trust modern software delivery depends on, and how damaging it can be when that trust is subverted.

What began with the compromise of Aqua Security’s Trivy ecosystem quickly expanded into a broader supply chain campaign touching GitHub Actions workflows, Trivy release artifacts, container images, npm packages, and malicious LiteLLM releases on PyPI. Across each stage, the objective was consistent: gain execution in trusted environments, harvest credentials, and use that access to extend the attack further.

For defenders, the immediate problem was simple. Working out whether you were exposed was not.

To help with that, we have released teampcp-scanner, a free, open-source tool designed to identify known indicators and affected components across the TeamPCP campaign.

TLDR: Check out https://github.com/whpoole/teampcp_scanner

What happened

On 19 March 2026, attackers compromised parts of Aqua Security’s Trivy ecosystem. Public reporting shows that malicious changes were introduced into trivy-action and setup-trivy, causing downstream GitHub Actions workflows pinned to affected tags to execute attacker-controlled code the next time those workflows ran. Aqua also disclosed malicious Trivy release artifacts and affected Docker Hub images during the incident window.

The operational significance was immediate. The code executed inside environments that often hold exactly the secrets attackers want most: CI/CD tokens, cloud credentials, deployment tokens, API keys, Kubernetes secrets, SSH material, and other high-value authentication data. In many organisations, those secrets provide access far beyond a single repository or build job.

Researchers then observed the campaign widen. Follow-on activity included the CanisterWorm npm operation and malicious LiteLLM releases on PyPI. The technical details varied between stages, but the strategic pattern held. Trusted developer tooling became an access path into the organisations that relied on it.

Who should care

This was not an issue confined to one package, one vendor, or one class of environment.

You should assess exposure if your organisation:

• used trivy-action or setup-trivy in GitHub Actions during the affected period

• ran affected Trivy binaries or container images

• has npm environments that may include compromised packages linked to the TeamPCP campaign

• installed LiteLLM 1.82.7 or 1.82.8

• relies on CI/CD systems, developer workstations, or build hosts where these components may have executed

Even where affected packages have already been removed, there is still value in checking for historic exposure. The initial execution path is only part of the problem. Residual indicators, host artefacts, compromised image digests, suspicious repository activity, and downstream credential abuse all matter.

The scanner

We built teampcp-scanner to answer the question every team asked as details emerged:

Were we exposed?

It is a single Python file with no external dependencies. It runs on macOS, Linux, and Windows. The goal is straightforward: give defenders a fast, evidence-based way to assess exposure across the currently known TeamPCP attack paths.

python3 teampcp_scanner.py --scan-path /your/repo --system

The scanner currently includes detection coverage for:

• GitHub Actions: identifies affected trivy-action and setup-trivy references in workflow files, including compromised versions and known malicious revisions

• Trivy binaries: hashes local Trivy binaries and compares them against known malicious values

• npm / CanisterWorm: checks for compromised packages and related behavioural indicators

• LiteLLM: detects affected versions and signs of the malicious Python startup backdoor

• Docker images: compares local image digests against known malicious image indicators

• Host persistence: checks known TeamPCP persistence paths and staging artefacts

• Network and C2 IOCs: searches for known domains, IPs, and related traces

• Kubernetes: looks for known TeamPCP wiper-related artefacts and suspicious manifests

• Git history and repository indicators: surfaces patterns associated with the campaign

• Credential exposure context: helps identify what classes of secrets may have been in scope if an affected component ran

Results are presented with severity, explanation, and remediation guidance, with output available in formats suitable for both direct review and integration into existing tooling.

Why we built it

At Strand, we spend our time helping organisations investigate and respond to real security incidents.

In the days following the TeamPCP disclosures, the same questions came up repeatedly.

Did this hit us?
What exactly do we need to check?
How do we check it quickly, and with confidence?

The public research on this campaign has been strong. The challenge for most teams was operational. The indicators were spread across GitHub Actions, host artefacts, container images, npm, PyPI, and broader infrastructure. Checking all of that manually takes time. It is easy to miss things. It is difficult to do consistently across multiple environments under pressure.

We built this scanner to make that first pass faster, clearer, and more accessible.

Get started

The scanner is available now on GitHub:

https://github.com/whpoole/teampcp_scanner

It requires Python 3.8 or later and no additional installation.

If the tool returns critical findings, treat that as a prompt for immediate action. Rotate any credentials that may have been exposed. Investigate affected runners or hosts. Remove or downgrade impacted components. Review for downstream signs of compromise.

If you need support with historic exposure assessment, host triage, or a fuller forensic investigation, get in touch:

[email protected]

A note on scope

This tool is based on publicly reported indicators and currently known attack paths. It is designed for rapid exposure assessment. It does not replace a forensic investigation.

A clean result reduces uncertainty. It does not prove that an environment was never exposed. It does not rule out additional developments as the public understanding of this campaign continues to evolve.

If you want, I can also give you a second version that is even more polished and publication-ready for a Strand blog specifically, with a stronger opening hook and a more elegant closing CTA.