On 22 March 2026, a threat actor known as TeamPCP used a single compromised service account token to execute one of the most visible open-source supply chain attacks of the year. The target was Trivy — a widely deployed open-source vulnerability scanner maintained by Aqua Security and used across CI/CD pipelines worldwide. The attack went well beyond the tool itself, cascading into Docker Hub images, GitHub Actions workflows, npm packages, and ultimately Kubernetes clusters — including a destructive wiper payload that force-deleted entire cluster environments.
If your organisation, your IT provider, or any software you depend on uses Trivy in an automated pipeline, you need to know exactly what happened.
What Is Trivy and Why Does It Matter Here?
Trivy is an open-source tool that scans container images, file systems, and code repositories for known security vulnerabilities. It is one of the most widely used tools in its category — embedded in CI/CD pipelines at organisations ranging from individual developers to large enterprises. Organisations use it to check that the software they are building and deploying does not contain known security flaws before it goes live.
The irony of this attack is not subtle: the tool used to check for security vulnerabilities became the vector for delivering them. A security scanner that hundreds of thousands of pipelines trust to run with elevated access to their environments was turned into an infostealer. The attackers understood this precisely, and that understanding is what made the target valuable.
How the Attack Unfolded
Stage 1: Compromise of the Trivy GitHub Actions
The initial intrusion point was the Trivy project's GitHub Actions workflows — specifically the aquasecurity/trivy-action and aquasecurity/setup-trivy Actions used by other repositories to automate security scanning. Attackers with a compromised credential pushed a credential stealer into trojanised versions of these Actions. Any repository that pulled and ran the compromised Actions exposed its CI/CD environment secrets — including tokens, API keys, and credentials stored as GitHub secrets — to the attackers.
This is the supply chain attack model in its purest form. The attacker does not need to compromise your organisation directly. They compromise a tool you trust, and they use that trust relationship to access your environment on your behalf.
Stage 2: Malicious Docker Hub Images
With credentials harvested from the initial compromise, the attackers pushed malicious versions of Trivy's Docker container image to Docker Hub. The last clean release was version 0.69.3. Versions 0.69.4, 0.69.5, and 0.69.6 — none of which had corresponding GitHub releases or tags — were pushed on 22 March 2026 and contained the TeamPCP infostealer. All three malicious versions have since been removed from Docker Hub.
The detail worth noting: 0.69.5 and 0.69.6 were pushed without any corresponding GitHub release. Any organisation with automated processes that pull the latest Docker image tag without verifying it against a known-good GitHub release would have pulled the malicious version without any warning. This is a fundamental risk in automated dependency management — and it applies far beyond Trivy.
Stage 3: npm Package Compromise and CanisterWorm
Using data stolen during the GitHub Actions compromise, the attackers moved into the npm package ecosystem, compromising dozens of packages to distribute a self-propagating worm called CanisterWorm. A self-propagating worm does not wait to be pulled by the next victim — once deployed in an environment, it actively seeks out new targets and spreads itself. CanisterWorm spreads via SSH using stolen keys and by exploiting exposed Docker APIs on port 2375 across the local network subnet.
Port 2375 is the Docker daemon's unencrypted API port. It should never be exposed on a production network — but in practice, misconfigured Docker environments with this port reachable on the local network are common. CanisterWorm scans for exactly this misconfiguration and uses it as a propagation vector.
Stage 4: The Kubernetes Wiper
The most destructive payload attributed to this campaign is a shell script that targets Kubernetes clusters. According to security researcher Charlie Eriksen at Aikido Security, the script deploys privileged DaemonSets across every node in any Kubernetes cluster it reaches — including control plane nodes. What happens next depends on the geography of the target:
- Kubernetes nodes identified as Iranian receive a container named
kamikazethat wipes the node and forces a reboot — the equivalent of a full system destruction. - Non-Iranian Kubernetes nodes receive the CanisterWorm backdoor, installed as a persistent systemd service.
- Non-Kubernetes Iranian hosts are targeted with
rm -rf / --no-preserve-root— a command that deletes every file on the system.
The geographic targeting of Iranian infrastructure adds a dimension to this campaign that goes beyond typical criminal motivation. The technical capability to deploy privileged DaemonSets across an entire Kubernetes estate, wipe nodes, and install persistent backdoors is not trivial. TeamPCP has been building toward this level of capability across a series of incidents targeting cloud infrastructure.
Stage 5: The Aqua Security GitHub Organisation Defacement
In parallel with the technical payload delivery, the attackers defaced all 44 internal repositories belonging to Aqua Security's aquasec-com GitHub organisation. Each repository was renamed with a tpcp-docs- prefix, its description changed to “TeamPCP Owns Aqua Security,” and its visibility set to public. All 44 changes were made in a scripted burst lasting just 79 seconds — between 20:31:07 and 20:32:26 UTC on 22 March 2026.
The vehicle for this was a single bot account — Argon-DevOps-Mgt — a service account created in July 2023 that had administrative access bridging two separate GitHub organisations. One compromised token for this account gave the attacker write and admin access to both organisations simultaneously. This is the weak link that security researcher Paul McCarty at OpenSourceMalware identified as central to the attack: a long-lived personal access token on a service account with cross-organisation privileges, almost certainly stolen during the earlier Trivy GitHub Actions compromise.
The Lessons That Apply Beyond DevOps
This incident involves container images, Kubernetes clusters, and CI/CD pipelines — the vocabulary of software development teams. But the underlying attack patterns are the same ones that threaten organisations of every size and type, and the lessons from this campaign apply well outside a DevOps context.
One Credential. Cascading Access.
The entire attack originated from a single compromised service account token. That token gave an attacker access to two GitHub organisations, the ability to push malicious code to a widely used open-source project, and ultimately the means to compromise every downstream environment that trusted that project. A single credential with excessive permissions and no MFA, used by an automated service account, was the master key.
This is not a DevOps-specific problem. It is the same vulnerability that enables business email compromise in law firms, HMRC agent credential theft in accountancy practices, and BSA portal fraud in NHS dental practices. The scale and the technical environment differ; the fundamental failure — a single privileged credential without adequate protection — is identical.
Supply Chain Trust Is Not Free
Organisations that use open-source software in their operations — and virtually every organisation does, either directly or through their IT provider's tooling — inherit the security posture of everything in that supply chain. When you run a security scanner, a monitoring agent, or a backup tool, you are trusting that tool's authors, their credential management, and their supply chain integrity.
The appropriate response is not to stop using open-source software. It is to understand that trust in a tool is not the same as verification that it has not been compromised, and to have monitoring in place that detects anomalous behaviour when — not if — something in the supply chain is compromised.
Long-Lived Tokens Are Silent Liabilities
The Argon-DevOps-Mgt service account was created in July 2023. The attack occurred in March 2026. If the personal access token used by that account was issued when the account was created and never rotated, it was a live credential for nearly three years. Service accounts and bot accounts accumulate credentials over time, often without the same lifecycle management applied to human accounts. They are rarely included in leavers processes, rarely subject to MFA enforcement, and rarely reviewed for scope creep.
Auditing service account access, rotating tokens on a defined schedule, and ensuring that no single service account bridges high-privilege access across multiple systems is not an enterprise-only security hygiene requirement. It applies to any organisation that uses connected services, automated tools, or third-party integrations.
Anomalous Behaviour Has a Signature
Forty-four repositories modified in 79 seconds. New Docker image tags pushed without corresponding GitHub releases. CanisterWorm scanning the local subnet for exposed port 2375. Each of these is a detectable anomaly — a pattern of behaviour that falls outside the baseline of normal operation. Effective security monitoring detects these deviations in real time and escalates them before the full payload is delivered.
The credential grinding campaigns documented in our March 2026 threat intelligence paper follow the same logic: the attack has a signature, that signature is observable in telemetry, and detection before exploitation is achievable. This Trivy campaign is no different. The 79-second burst of repository modifications is not subtlety — it is speed. The attacker moved fast because they knew that detection was possible and that the window for undetected operation was limited.
Immediate Actions if You Use Trivy
If your organisation, your IT provider, or any automated pipeline you depend on uses Trivy, the following actions are warranted now.
Confirm which version of Trivy is in use across all CI/CD pipelines and automated scanning processes. The last clean release on Docker Hub is version 0.69.3. Versions 0.69.4, 0.69.5, and 0.69.6 are malicious and have been removed from Docker Hub, but any environment that pulled them while they were available should be treated as potentially compromised.
Review your use of the aquasecurity/trivy-action and aquasecurity/setup-trivy GitHub Actions. Any pipeline that executed these Actions during the period of compromise should be treated as having had its secrets exposed. Rotate all credentials, tokens, and API keys that were present as environment variables or GitHub secrets in those workflows.
Check your Docker environments for exposed port 2375. The Docker daemon API should not be accessible on the local subnet without authentication. If it is, that is both an existing vulnerability and a CanisterWorm propagation vector.
Review your Kubernetes cluster security if applicable — specifically whether privileged DaemonSet creation can be restricted and whether any new DaemonSets appeared in your environment on or after 22 March 2026.
Ask your IT provider or MSP what scanning and monitoring tools they use in their delivery of services to you. Trivy is commonly used in managed service provider tooling. If your IT provider's own pipeline was compromised, any secrets they hold for your environment may have been exposed.
Supply Chain Attacks Have a Signature. SOC in a Box Detects It.
The Trivy campaign demonstrates what continuous monitoring exists to catch: anomalous credential use, unexpected outbound connections from security tooling, lateral movement across a subnet, and the rapid scripted modification of infrastructure that characterises an automated attack in progress. SOC in a Box deploys dark web monitoring for your credentials and infrastructure identifiers, behavioural detection that flags deviations from your network baseline, and a named analyst who investigates and escalates — not a dashboard you check yourself. If a compromised dependency creates anomalous behaviour in your environment, your analyst sees it.
Book a scoping call