Attackers turned two open-source security scanners into supply chains

What happened

Beginning 19 March 2026, an actor identified as TeamPCP compromised the release pipeline of Trivy, Aqua Security's widely used open-source vulnerability scanner. According to the project's own GitHub security advisory, the actor used compromised credentials to publish a malicious Trivy release and to force-push the vast majority of version tags on the companion trivy-action and setup-trivy GitHub Actions to commits carrying credential-harvesting code, before publishing further malicious container images on Docker Hub on 22 March. The advisory states the root cause was an earlier, incompletely remediated compromise: credentials rotated after an initial disclosure on 1 March were not all revoked at once, leaving a window the actor used to regain access.

A related but separate compromise struck Checkmarx's KICS infrastructure-as-code scanner days later. A security advisory posted to the kics-github-action repository on 23 March 2026 reported that every release tag on that GitHub Action had been repointed to a malicious commit carrying similar credential-theft code, while the project's main branch remained clean. Independent analysis published by the security vendor Wiz, in a post attributing the campaign to TeamPCP, described the two incidents as part of a broader pattern in which the same actor reached several open-source projects used inside software build pipelines within roughly a week.

Confidence and limits

Both compromises are confirmed directly by the affected projects' own security advisories, which is the standard this entry requires before treating a supply-chain claim as established. The attribution to TeamPCP comes from Wiz's independent analysis rather than from either project's advisory, and should be read as a vendor's assessment rather than an official attribution. This entry does not attempt to describe the credential-theft mechanism in operational detail.

Why it mattered

Trivy and KICS are not incidental developer tools; teams add them to continuous integration pipelines specifically to catch security problems before code ships, which means both projects run with meaningful access to the build environment and the secrets inside it. When the scanner itself is compromised, the very control meant to catch a supply-chain risk becomes the delivery mechanism for one, and any pipeline that pulled the affected release or Action tags during the exposure window inherited the compromise automatically, without any action beyond a routine, automated update.

Defensive takeaway

Audit your build pipelines now for any use of the affected Trivy or KICS releases and Action tags during the disclosed windows, rotate any credentials those pipelines could have exposed, and move toward pinning third-party Actions and scanner versions to specific commit hashes rather than tags that a compromised maintainer account can redirect.

• Do any of your CI/CD pipelines reference Trivy, trivy-action, setup-trivy, or the KICS GitHub Action by a mutable version tag rather than a fixed commit?
• Would your organisation detect a credential-rotation window left open after a prior, partially remediated compromise?
• Do your security scanning tools run with more CI/CD secret access than the tasks they perform actually require?

Both advisories describe an ecosystem-level lesson rather than a flaw unique to either project: any tool trusted enough to run inside a build pipeline is, by that same trust, a target worth compromising.