A threat actor tracked as TeamPCP has compromised two GitHub Actions workflows maintained by Checkmarx, a major application security vendor, in a confirmed supply chain attack detected around March 19, 2026. The attack used credentials stolen from a prior compromise of Aqua Security's Trivy vulnerability scanner to poison Checkmarx's CI/CD pipelines, injecting a credential-harvesting payload capable of exfiltrating secrets from any organization running the affected actions. This is the second confirmed supply chain hit by TeamPCP in the same campaign, and evidence suggests the attack is designed to cascade; each compromise fueling the next.
What Happened
TeamPCP first compromised GitHub Actions associated with Aqua Security's Trivy open-source vulnerability scanner (tracked as CVE-2026-33634, CVSS 9.4). Approximately four days after that initial breach, on or around March 19, Sysdig observed the identical credential-stealing payload deployed against two Checkmarx GitHub Actions:
checkmarx/ast-github-action; Checkmarx's AST (application security testing) actioncheckmarx/kics-github-action; Checkmarx's KICS infrastructure-as-code scanning action
The attack vector: credentials stolen from the Trivy compromise included GitHub personal access tokens (PATs) with write access to repositories also using Checkmarx actions. TeamPCP used those tokens to force-push tags pointing to malicious commits containing the stealer payload (setup.sh). The poisoned actions appear legitimate to any developer pulling them; they come from the official Checkmarx repository.
Wiz identified the initial foothold as a compromise of the cx-plugins-releases service account. Attackers additionally published trojanized versions of the ast-results VS Code extension to the Open VSX marketplace, extending the blast radius beyond CI pipelines into developer workstation environments.
What Was Taken
The "TeamPCP Cloud Stealer" payload is designed to harvest a comprehensive set of credentials and secrets from CI runner memory and environment, including:
- GitHub personal access tokens (PATs) and repository secrets
- SSH keys and Git credentials
- Cloud provider credentials: AWS, Google Cloud, Microsoft Azure
- Container and orchestration secrets: Kubernetes configs, Docker credentials
- CI/CD configuration files and environment variables (
.env) - Database credentials
- VPN credentials
- Cryptocurrency wallet data
- Slack and Discord webhook URLs
Stolen data is exfiltrated as an encrypted archive (tpcp.tar.gz) to the attacker-controlled domain checkmarx[.]zone (IP: 83.142.209[.]11:443); a deliberate typosquat of the legitimate Checkmarx domain designed to blend into CI/CD logs. As a fallback, the stealer creates a docs-tpcp repository using the victim's own GITHUB_TOKEN to stage stolen data if the primary exfiltration channel fails.
Any organization that ran the compromised Checkmarx actions during the exposure window should assume all secrets accessible in that CI environment are compromised.
Why It Matters
This attack demonstrates a cascading supply chain compromise model that fundamentally undermines the trust assumptions of the CI/CD ecosystem. The kill chain here is self-reinforcing: compromise one trusted action, harvest tokens, use those tokens to compromise the next trusted action, harvest more tokens, repeat.
The victim selection is not incidental. Checkmarx is an AppSec vendor; organizations running its GitHub Actions are disproportionately security-mature enterprises and development teams that have specifically invested in securing their pipelines. Compromising Checkmarx's actions means the attacker's payload executes in the most security-conscious CI environments, with access to the most sensitive internal credentials.
The typosquat domain technique is particularly insidious. An analyst reviewing CI logs would see outbound traffic to checkmarx.zone and reasonably assume it is legitimate vendor telemetry. Manual detection is unlikely; automated detection requires explicit IoC matching or anomaly detection on CI egress.
This campaign also highlights the fragility of the "trusted source" model for GitHub Actions. Force-pushing tags to malicious commits does not require publishing a new action version; it hijacks the existing tag reference. Organizations pinning actions to tags rather than commit SHAs are fully exposed.
The Attack Technique
Stage 1, Initial Compromise (Trivy): TeamPCP compromised Aqua Security's Trivy GitHub Actions (CVE-2026-33634). Method of initial credential acquisition not fully disclosed, likely via phishing, infostealer malware on a maintainer workstation, or exploitation of a CI secret exposure.
Stage 2; Credential Harvesting at Scale: The Trivy stealer payload executes in CI runners of every organization using the action, harvesting GitHub PATs and cloud credentials from runner memory at execution time.
Stage 3; Lateral Pivot to Checkmarx: Harvested PATs with write access to Checkmarx repositories used to force-push malicious tags to ast-github-action and kics-github-action. The cx-plugins-releases service account was the confirmed foothold.
Stage 4 (Cascading Exfiltration: Any organization running the compromised Checkmarx actions now executes the stealer, yielding a new wave of credentials) which can be used to poison additional actions in a further expansion.
Evasion: Typosquat exfiltration domain (checkmarx[.]zone), encrypted archive format, and fallback staging via victim's own GitHub token.
What Organizations Should Do
-
Pin all GitHub Actions to full commit SHAs, not tags. Tags are mutable; a force-pushed tag silently redirects to a malicious commit. Pinning to a commit SHA (
uses: checkmarx/ast-github-action@<full-sha>) ensures you run exactly what you audited. This is the single most effective mitigation against tag-hijacking attacks. -
Rotate all secrets immediately if you ran affected actions. Any CI environment that executed
checkmarx/ast-github-actionorcheckmarx/kics-github-actionduring the exposure window should treat all in-scope secrets as compromised: GitHub PATs, AWS/GCP/Azure credentials, SSH keys, database passwords, and any.envvalues accessible to the runner. -
Block outbound CI traffic to non-approved destinations. CI runners should only be permitted to communicate with known-good endpoints. Egress filtering or network policies that block unexpected outbound connections, including to typosquat domains, would have stopped the exfiltration regardless of whether the payload executed.
-
Audit GitHub Actions permissions and GITHUB_TOKEN scopes. The
GITHUB_TOKENgranted to Actions should follow least privilege. If a workflow does not need write access to create repositories or push commits, that permission should be explicitly denied in the workflowpermissionsblock. The fallback exfiltration method (creating adocs-tpcprepo) requirescontents: write; revoking that where unnecessary eliminates one exfiltration channel. -
Implement CI secret scanning and runtime monitoring. Tools like Sysdig, Wiz, or open-source alternatives can monitor CI runner behavior at runtime; flagging unexpected network connections, new repository creation, or credential access patterns that deviate from baseline.
-
Add affected IoCs to your threat intelligence feeds immediately. Block at DNS/firewall:
checkmarx[.]zone/83.142.209[.]11. Search CI logs fortpcp.tar.gz,docs-tpcp,tpcp-docs, andsetup.shexecution. Correlate any access to these indicators with repository write events and secret access logs.