How TeamPCP Got Into Cisco: Following the Trivy Supply Chain Trail
Let's trace the chain.
On March 19, 2026, someone force-pushed malicious code to 75 of 76 version tags in aquasecurity/trivy-action, the official GitHub Action for Trivy, one of the most widely used container vulnerability scanners in the industry. Aqua Security's own tooling, compromised at the source.
The malicious payload was elegant in its simplicity: it harvested CI/CD secrets from whatever pipeline was running it, and then ran the legitimate Trivy scan. Pipeline output looked normal. The only way to know you'd been hit was to audit your secret environment variables and trace where they went.
What got harvested
Anything in the environment of any CI/CD job that ran aquasecurity/trivy-action between March 19 and remediation. That means:
- GitHub tokens
- AWS access keys and secrets
- Container registry credentials
- Any other secrets passed as environment variables to the pipeline
If you're thinking "we use Trivy for container scanning in every pipeline, so that's every secret in the org": you might be right. That's the attack surface.
How Cisco got hit
BleepingComputer confirmed that TeamPCP used credentials harvested from this Trivy compromise to breach Cisco's internal development environment. Specifically: a malicious GitHub Action plugin from the Trivy compromise was used to steal credentials and data from Cisco's build and dev environment, impacting dozens of devices including developer workstations and lab machines.
From there, attackers accessed source code belonging to Cisco and its customers, and stole multiple AWS keys. Those keys were used to perform unauthorized activity across a small number of Cisco AWS accounts. Cisco's CSIRT contained the breach, but the initial exfil had already happened.
The European Commission separately confirmed a breach linked to the same Trivy supply chain attack.
Why this fits the TeamPCP pattern
We've been tracking TeamPCP since at least March 2026. Their playbook has a consistent signature:
- Target security tooling or developer tooling (Bitwarden CLI, Checkmarx KICS, Trivy, xinference)
- Compromise the distribution channel (npm package, Docker tag, GitHub Action tag)
- Silently harvest credentials while the tool does its legitimate job
- Use harvested credentials to pivot into high-value targets
What makes this interesting is the choice of targets. Trivy is a container security scanner. The people running it are security engineers and DevOps teams. They have high access, broad environment variable scope in their pipelines, and relatively high implicit trust in the output of security tools. It's a precision targeting decision, not a spray-and-pray campaign.
What to do right now
If you ran `aquasecurity/trivy-action` before remediation:
- Treat the pipeline environment as compromised
- Rotate every secret that was present as an environment variable in any job that used trivy-action
- Audit downstream usage of those secrets: AWS CloudTrail, GitHub audit log, container registry access logs
- Look for unauthorized access, unusual API calls, unexpected resource creation
Going forward, regardless of whether you were affected:
- Pin GitHub Actions to commit SHA instead of version tags. A version tag like
@v2is mutable: the tag can be force-pushed to point to different code. A commit SHA is immutable.uses: aquasecurity/trivy-action@a1234567...can't be force-pushed to point to malicious code. - Audit which GitHub Actions your pipelines consume. For each one, understand who controls the repository and what access the action has to your environment variables.
- Scope environment variables tightly in CI/CD jobs. Don't pass secrets to jobs that don't need them.
This isn't theoretical. TeamPCP has demonstrated they can turn a widely trusted security tool into a credential harvester at scale. The Bitwarden CLI hit 334 downloads before detection. trivy-action runs in thousands of pipelines. The scale here is larger.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge, cybersecurity intelligence from Georgia.