Your Vulnerability Scanner Just Became the Vulnerability
Trivy is a popular open-source vulnerability scanner. Last week, it was compromised and used to steal credentials from over 1,000 organizations that trusted it.
What Happened
On March 19, 2026, a threat actor called TeamPCP compromised Trivy, one of the most widely used open-source vulnerability scanners in the world. The tool that thousands of organizations run inside their CI/CD pipelines to find security flaws was itself weaponized to steal credentials, backdoor developer machines, and spread laterally through cloud infrastructure.
Over 1,000 cloud environments have been confirmed infected. Aqua Security, Trivy’s maintainer, is still investigating the full scope. Microsoft, Palo Alto Unit 42, Wiz, Sysdig, GitGuardian, and Arctic Wolf have all published independent analyses. CVE-2026-33634 has been assigned with a CVSS score of 9.4.
If your organization uses Trivy, GitHub Actions, or any npm packages updated in the last week, keep reading.
How the Attack Unfolded
The compromise happened in five phases, each building on the last. Understanding this chain matters because the same pattern can be replicated against any open-source project with CI/CD automation.
Phase 1: A Misconfigured Workflow and an Incomplete Fix
Sometime in late February 2026, an automated bot called “hackerbot-claw” found a misconfigured `pull_request_target` workflow in Trivy’s GitHub repository. This is a well-documented vulnerability in GitHub Actions: the `pull_request_target` event runs workflows with write access to the repository and makes secrets available to the workflow, even when triggered by a pull request from a fork.
The bot exploited this to steal a Personal Access Token (PAT) from Trivy’s CI environment. Aqua Security discovered the theft and rotated credentials, but the rotation was incomplete. According to GitGuardian’s analysis, residual access paths remained open. TeamPCP retained access to surviving tokens, including credentials for the `aqua-bot` service account, and waited.
Phase 2: Binary Poisoning Through Official Channels
On March 19 at 17:43 UTC, TeamPCP used the compromised service account to push a malicious Trivy release: version 0.69.4. The commits were crafted to spoof legitimate maintainer identities, reusing original author metadata and timestamps to create a deceptive Git history. The release triggered Aqua’s automated build pipelines, which published the infected binary to GitHub Releases, Docker Hub, GitHub Container Registry (GHCR), and Amazon ECR.
Two days later, on March 22, TeamPCP pushed additional malicious Docker images tagged 0.69.5 and 0.69.6 directly to Docker Hub, without corresponding GitHub releases. The last clean version is 0.69.3.
Phase 3: Tag Poisoning Turns Every Pipeline into a Weapon
This is where the attack scaled. TeamPCP force-pushed malicious commits to 75 of 76 version tags in the `trivy-action` GitHub Action and all 7 tags in `setup-trivy`. Because most GitHub Actions workflows reference actions by version tag (e.g., `@v0.28.0`) rather than by commit SHA, every CI/CD pipeline that referenced these actions began running TeamPCP’s code on its next execution. No workflow file changed. No pull request was created. The tag simply pointed somewhere new.
The poisoned actions executed a three-step credential theft operation:
Collection. The malware read directly from GitHub Actions Runner memory (`/proc/<pid>/mem`), bypassing GitHub’s log-masking to harvest credentials. Targeted secrets included SSH keys, AWS/GCP/Azure cloud credentials, Kubernetes tokens, Docker registry credentials, database passwords, TLS private keys, and cryptocurrency wallet files. It also scraped credentials from over 50 filesystem paths.
Encryption. Stolen data was encrypted with AES-256-CBC wrapped in RSA-4096, making network-layer inspection ineffective.
Exfiltration. Primary exfiltration went to a typosquatted domain: `scan.aquasecurtiy[.]org` (note the misspelling of “security”), resolving to 45.148.10.212 (TECHOFF SRV LIMITED, Amsterdam). As a fallback, the malware used the victim’s own stolen GitHub PAT to create a public repository named `tpcp-docs` and uploaded the encrypted credential dump there, using trusted infrastructure as a dead drop.
Phase 4: Persistent Backdoor via Blockchain C2
When the malicious Trivy binary ran on developer workstations (not just in CI/CD), it installed a systemd service (`sysmon.py`) that polled an Internet Computer Protocol (ICP) blockchain canister every 50 minutes for command-and-control instructions. Because the C2 infrastructure lives on a decentralized blockchain, it resists DNS sinkholes, domain takedowns, and traditional network-based blocking. The low beacon frequency (every 50 minutes) was designed to evade statistical anomaly detection.
Phase 5: CanisterWorm Spreads Through npm
Using credentials stolen in Phase 3, TeamPCP launched CanisterWorm, a self-propagating worm that compromised 47+ npm packages across multiple scopes (including @emilgroup, @opengov, and @teale.io namespaces). Twenty-eight packages were compromised within 60 seconds. Later variants added token theft and malicious publishing in postinstall hooks, turning every developer or CI pipeline that installed an affected package into an unwitting propagation vector.
On March 22, TeamPCP also used a compromised long-lived PAT from the `Argon-DevOps-Mgt` bot account (created July 2023) to breach Aqua Security’s internal GitHub organization. Within a two-minute window (20:31-20:32 UTC), 44 internal repositories were renamed with a `tpcp-docs-` prefix, exposing Tracee source code, internal forks, CI/CD pipelines, and Kubernetes operators.
The Kubernetes Wiper: “Kamikaze”
One payload deserves special attention. TeamPCP deployed a Kubernetes wiper that deploys privileged DaemonSets across cluster nodes. The behavior is geographically targeted:
On systems geolocated to Iran: executes `rm -rf / --no-preserve-root` and forces a system reboot via a container named “kamikaze”
On all other systems: installs CanisterWorm as a systemd service for persistent backdoor access
The Iranian targeting is notable given the current geopolitical context, but attribution to any state actor has not been established. TeamPCP’s motivations appear primarily criminal (credential theft, infrastructure compromise) with the Iranian wiper component potentially representing hacktivism, a false flag, or an unrelated vendetta. No vendor has attributed TeamPCP to a nation-state.
Why This Matters
This attack exploits a fundamental trust assumption: that security tools are trustworthy. Organizations run Trivy inside their most privileged environments (CI/CD pipelines with access to production credentials, cloud infrastructure tokens, and signing keys) precisely because it is a security tool. That trust relationship made the compromise devastatingly effective.
Three structural problems made this possible:
1. Tag-based GitHub Action references are inherently fragile. If you reference `uses: aquasecurity/trivy-action@v0.28.0`, you are trusting that the tag will always point to the same commit. Tags can be force-pushed. There is no integrity guarantee. This is a known risk that the GitHub Actions ecosystem has not adequately addressed. The fix is to pin actions by full commit SHA, which is immutable.
2. Incomplete credential rotation created the window. Aqua Security detected the initial PAT theft in late February and rotated credentials, but missed residual access paths. TeamPCP waited and re-entered through a surviving token. As GitGuardian’s analysis puts it: the core lesson extends beyond detection. Organizations must “trace blast radius, prioritize rotation, verify remediation, and prove that the same credential cannot be reused tomorrow.”
3. Official distribution channels became the delivery mechanism. The malicious binary was published through GitHub Releases, Docker Hub, GHCR, and ECR. These are the channels organizations trust. There was no phishing email, no drive-by download, no exploitation of a vulnerability in the traditional sense. The attacker simply published a new version through legitimate automation.
What You Should Do
Immediate (today)
Check for affected Trivy versions. Search your environments for Trivy 0.69.4, 0.69.5, or 0.69.6. The last clean version is 0.69.3. Check GitHub Actions logs, Docker image registries, and developer workstations.
Audit GitHub Actions workflow runs from March 19 onward. Review execution logs for `trivy-action` and `setup-trivy`. Look for unexpected network connections, repository creation (especially repositories prefixed with `tpcp-docs`), or credential access patterns.
Rotate all secrets that were accessible to affected pipelines. If any pipeline ran a compromised action or binary after March 19, treat every secret accessible to that pipeline as compromised. This includes cloud provider credentials, Docker registry tokens, npm publish tokens, SSH keys, database credentials, and Kubernetes service account tokens.
Search for persistence mechanisms. On Linux systems, look for suspicious systemd services: `sysmon.py`, `pgmon.py`, `pgmonitor.service`, `internal-monitor.service`. Check for outbound connections to the ICP canister endpoint (`tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io`) or the typosquatted domain (`scan.aquasecurtiy[.]org`).
This week
Pin all GitHub Actions by full commit SHA. Replace every tag-based action reference in your workflows with the full 40-character commit hash. This is the single most effective mitigation against tag poisoning attacks. Yes, it makes updates harder. That friction is the point.
Audit npm dependencies installed since March 19. Check for packages in the @emilgroup, @opengov, and @teale.io scopes. Review postinstall hooks in all recently updated packages.
Review CI/CD pipeline permissions. Apply least privilege to workflow tokens. Restrict `GITHUB_TOKEN` permissions to the minimum required for each workflow. Eliminate long-lived PATs wherever possible and replace with short-lived, scoped tokens.
Going forward
Treat CI/CD runners as production infrastructure. Monitor them with the same rigor you apply to production servers. Credential theft from a CI/CD runner can be more damaging than a production server compromise because runners have access to deployment credentials, signing keys, and cross-environment tokens.
Implement secret scanning and rotation verification. When you rotate credentials after an incident, verify the rotation was complete. Test that the old credential no longer works. GitGuardian, GitHub Advanced Security, and similar tools can help detect lingering exposure.
Indicators of Compromise
Network:
- `scan.aquasecurtiy[.]org` (typosquatted exfiltration domain)
- `45.148.10.212` (TECHOFF SRV LIMITED, Amsterdam)
- `tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0[.]io` (ICP blockchain C2)
- `plug-tab-protective-relay.trycloudflare.com` (Cloudflare tunnel exfil)
- `souls-entire-defined-routes.trycloudflare.com`
- `checkmarx[.]zone`
- `63.251.162.11`
- `23.142.184.129` (ICP blockchain infrastructure; monitor only, do not block as this serves legitimate traffic.)
Note on Cloudflare tunnel domains: The `trycloudflare[.]com` subdomains above are ephemeral Cloudflare quick tunnels that may already be rotated or expired. Monitor for the pattern but do not rely on these as durable indicators.
Note on checkmarx[.]zone: This is a typosquatted domain impersonating Checkmarx (legitimate domain: checkmarx.com). Confirmed as attacker infrastructure by Palo Alto Unit 42.
Affected versions:
- Trivy 0.69.4, 0.69.5, 0.69.6 (last clean: 0.69.3)
- trivy-action: 75 of 76 tags compromised
- setup-trivy: all 7 tags compromised
- 47+ npm packages across @emilgroup, @opengov, @teale.io scopes
Persistence indicators:
- systemd services: `sysmon.py`, `pgmon.py`, `pgmonitor.service`, `internal-monitor.service`
- Repositories prefixed with `tpcp-docs` in your GitHub organization
File hashes (select):
- `e9b1e069efc778c1e77fb3f5fcc3bd3580bbc810604cbf4347897ddb4b8c163b`
- `61ff00a81b19624adaad425b9129ba2f312f4ab76fb5ddc2c628a5037d31a4ba`
The Bottom Line
The Trivy compromise demonstrates that software supply chain attacks are no longer limited to obscure packages or niche tools. A security scanner used by thousands of organizations to protect their infrastructure was turned into a credential harvesting platform, a persistent backdoor, and a worm propagation vector, all distributed through official channels that defenders are conditioned to trust.
The fix is not complicated, but it requires discipline. Pin your actions by SHA. Rotate credentials completely. Monitor your CI/CD runners. And stop assuming that because a tool is designed to improve your security, it cannot be used to destroy it.
*Research sources: Intruvent CTI Cloud, Microsoft Defender Security Research (March 24, 2026), Palo Alto Unit 42 Cloud Security (March 25, 2026), Wiz Research (March 20-23, 2026), GitGuardian (March 24, 2026), The Hacker News (March 25, 2026), Sysdig Threat Research (March 23, 2026), Arctic Wolf (March 24, 2026), Aqua Security formal advisory (March 23, 2026)*
For threat hunting queries and detection rules for your SIEM, visit the Intruvent Threat Intelligence Hub or for CTU related to the Iran conflict visit the Intruvent Iran Cyber Threat Intelligence Center or contact us at contact@intruvent.com.
Want sector-specific threat intelligence for your organization? Check out our BRACE CTI platform