TeamPCP’s Checkmarx GitHub Actions Attack: What You Need to Know

A supply chain incident becomes far more dangerous when it stops looking like a single breach and starts behaving like a multiplier.

That is what made the TeamPCP campaign stand out in March 2026. The compromise of Checkmarx GitHub Actions and developer tooling became one of the clearest signs that the campaign was no longer contained to Trivy. By the time Checkmarx was affected, the operation had already shown how stolen CI/CD credentials could be reused to poison trusted workflows across vendors.

What began inside Aqua Security’s Trivy ecosystem quickly expanded into poisoned GitHub Actions, malicious Docker images, compromised packages, a self-propagating worm, destructive Kubernetes activity, and a pivot into Checkmarx tooling.

What Happened in the Checkmarx Supply Chain Attack?

The Checkmarx phase showed how quickly a supply chain compromise can jump from one trusted ecosystem into another. TeamPCP reused access and tradecraft already proven in the earlier Trivy compromise to target two Checkmarx GitHub Actions, checkmarx/ast-github-action and checkmarx/kics-github-action, with an almost identical credential stealer.

The malware harvested secrets from CI runner memory and the filesystem, packaged them into tpcp.tar.gz, and exfiltrated them to checkmarx[.]zone. It also included a fallback mechanism that created a docs-tpcp repository with the victim’s GITHUB_TOKEN if direct exfiltration failed. That design mattered because it showed the attackers were planning for resilience, not just opportunistic data theft.

The same phase also reached developer tooling. Malicious OpenVSX versions of ast-results v2.53.0 and cx-dev-assist v1.7.0 were published through a account. Once activated, the extensions checked whether the host had credentials for GitHub, AWS, Google Cloud, or Azure, and if so, fetched a second-stage payload from the same checkmarx[.]zone infrastructure. The official VS Code Marketplace was not affected, but OpenVSX users were exposed.

What Do You Need to Know First?

The most important point is that this was a cascading trust attack. The initial compromise mattered, but the larger risk came from what happened next.

TeamPCP harvested secrets from the environments that executed compromised actions and artifacts. Those secrets included GitHub tokens, SSH keys, cloud credentials, Kubernetes tokens, CI/CD configuration material, and other valuable access paths. Once those were in hand, the attackers could move into adjacent repositories, registries, and developer tooling without needing a fresh exploit each time.

That is why the incident should not be viewed as a Trivy-only problem or a Checkmarx-only problem. The real issue was the exposure of transitive trust. One poisoned action could collect credentials that opened the door to other workflows, other vendors, and other environments.

That pattern also aligns with a broader trend highlighted by Alon Gal in a LinkedIn post about the incident. are no longer just about corrupting software delivery. They are becoming a way to accumulate large stores of valid, high-privilege access that can be reused quietly over time.

For a fuller breakdown of TeamPCP’s broader activity across CI/CD, registries, and cloud-native environments, see this TeamPCP campaign analysis.

How Did the TeamPCP Campaign Begin Before Reaching Checkmarx?

TeamPCP has been tied to cloud-focused operations centered on credential theft, -linked activity, cryptomining, and post-compromise exploitation. In this campaign, the group moved with unusual speed and flexibility. It did not just compromise one distribution path. It chained access across repositories, build systems, registries, packages, and extensions.

The campaign took shape after a remediation gap left credentials exposed following a February 27, 2026 “Pwn Request” attack against Trivy’s CI/CD infrastructure. That earlier event exposed a service account token with write access to multiple repositories. The follow-on exploitation on March 19, 2026 turned that weakness into a full supply chain event.

Timeline of TeamPCP Attacks in the Supply Chain Campaign

Date	Incident	Why It Matters
February 27, 2026	A prior “Pwn Request” attack exposes a Trivy CI/CD service account token.	This earlier exposure creates the conditions for later follow-on compromise if remediation is incomplete.
March 19, 2026	TeamPCP abuses that access to push a malicious v0.69.4 tag to Trivy.	The campaign begins at the source, turning a trusted release path into a malware distribution channel.
March 19, 2026	Malicious Trivy-related GitHub Actions, including trivy-action and setup-trivy, begin harvesting runner secrets.	The attack shifts from artifact poisoning to CI/CD credential theft, enabling wider downstream compromise.
March 20–21, 2026	Stolen secrets are reused across connected environments and trust paths.	This is where the incident becomes a cascading supply chain event rather than a single-vendor breach.
March 22, 2026	Malicious Trivy Docker Hub images 0.69.5 and 0.69.6 appear without corresponding GitHub releases or tags.	The actor shows it can bypass GitHub-based release controls and use registry access directly.
March 22, 2026	Aqua’s internal aquasec-com GitHub organization is defaced through a compromised service account.	The blast radius extends into internal repositories, highlighting the danger of bridged bot accounts and broad token scope.
March 22, 2026	Malicious litellm releases appear on PyPI as the campaign expands into package ecosystems.	This shows the operation is no longer limited to GitHub Actions and container images, and is now using stolen publish access to reach developers through package managers.
March 22, 2026	The broader campaign escalates with CanisterWorm propagation and destructive activity targeting Iranian environments.	The operation evolves beyond theft into worm-like spread and selective destructive behavior.
March 23, 2026	Malicious OpenVSX versions of ast-results v2.53.0 and cx-dev-assist v1.7.0 are published through a compromised Checkmarx account.	The campaign expands into developer tooling and tests for cloud and GitHub credentials on victim systems.
March 23, 2026	Checkmarx says only OpenVSX downloads during the affected UTC window are potentially impacted, and releases clean versions.	This narrows the directly affected population but confirms the incident has reached the Checkmarx ecosystem.
March 23–24, 2026	checkmarx/ast-github-action and checkmarx/kics-github-action are found compromised with TeamPCP-linked credential stealer logic.	Checkmarx becomes a central phase of the campaign, showing how earlier stolen CI secrets can be reused across vendors.
March 24, 2026	Security guidance focuses on rotating secrets, auditing logs for tpcp.tar.gz, hunting for docs-tpcp and tpcp-docs, and pinning actions to SHAs.	The response shifts from isolated remediation to ecosystem-wide incident response and trust reduction.

How Did TeamPCP Use Earlier Access to Reach Checkmarx?

The campaign unfolded in several connected phases, with each stage building on access gained in the previous one.

How Was Trivy Poisoned at the Source?

The initial Trivy compromise, tracked as , began with a malicious v0.69.4 tag pushed to the repository. The attacker used imposter commits with spoofed contributor identities and backdated timestamps to make the changes appear legitimate on casual inspection. Those commits pulled malicious Go source files from a typosquatted command-and-control domain and fed them into the build process. The poisoned release then flowed through trusted channels, including GitHub Releases, Docker Hub, AWS ECR, and GitHub Container Registry.

That distribution model was central to the campaign’s success. Rather than forcing victims to download an obviously malicious binary, the attacker abused the normal release path of a tool many organizations already trusted.

How Did Service Account Access Enable Lateral Movement?

Once inside the Aqua ecosystem, the attacker used compromised service account credentials to inject malicious workflows into additional repositories. Malicious tags were published for both trivy-action and setup-trivy, two GitHub Actions used in many downstream pipelines.

This shifted the incident from a repository compromise into a broader supply chain event. At that point, any workflow that trusted those actions by tag rather than by full commit SHA became a potential collection point for secrets.

The Payload Focused on Large-Scale Credential Theft

The malicious GitHub Action payload used a three-stage design: collect, encrypt, and exfiltrate.

The collection logic scraped process memory from GitHub Actions runner processes and searched the filesystem across dozens of likely credential locations. It looked for SSH keys, AWS, Google Cloud, and Azure credentials, Kubernetes material, Docker configuration, .env files, database connection details, and even cryptocurrency wallet data. The attacker then bundled stolen information into an encrypted archive named tpcp.tar.gz.

That approach made the runner itself the harvesting mechanism. The attacker did not need to break into every target directly. The target’s own automation environment gathered the data for them.

Exfiltration Was Built to Survive Partial Disruption

TeamPCP did not rely on a single outbound channel. The campaign used typosquatted domains, Cloudflare Tunnel infrastructure, and fallback mechanisms designed to keep data flowing even if one path failed.

One of the most notable fallback methods created repositories such as tpcp-docs inside a victim’s GitHub organization and uploaded stolen data there as release assets. In the Checkmarx phase, a similar pattern appeared again with the docs-tpcp naming variant. This was a clever move for two reasons. First, it improved resilience. Second, it made the exfiltration look less suspicious because it used the victim’s own infrastructure.

Why This Was Bigger Than a GitHub Actions Compromise

GitHub Actions drew much of the early attention, but the broader TeamPCP campaign extended well beyond CI workflows.

How Did the Attack Spread Into npm and PyPI?

Less than 24 hours after the initial Trivy compromise, TeamPCP launched CanisterWorm, a self-propagating worm that used stolen npm publish tokens to infect more than 28 packages in under a minute. The worm resolved token owner identities, enumerated packages those accounts could publish to, bumped package versions, and pushed malicious updates automatically.

The campaign also crossed into PyPI, where malicious versions of litellm were published before being quarantined.

The strategic lesson was clear. Once attackers harvest publish credentials from CI/CD systems, package ecosystems become a force multiplier. One compromised runner can produce many poisoned artifacts in very little time.

The Actor Also Bypassed GitHub Entirely

On March 22, TeamPCP pushed malicious aquasec/trivy:0.69.5 and 0.69.6 images directly to Docker Hub, without corresponding GitHub releases or tags. That indicated that Docker Hub credentials had also been compromised independently.

That detail is easy to miss, but it matters. It showed that the attackers were not dependent on one delivery path. Even if defenders locked down GitHub-based release workflows, a compromised registry account could still be used to distribute trojanized images.

How Did Internal Repositories Become Part of the Attack Surface?

Later the same day, the actor used a compromised service account to rename and expose dozens of repositories in Aqua’s internal aquasec-com GitHub organization. The repositories were renamed with a tpcp-docs- prefix and publicly defaced in a burst that lasted only a couple of minutes.

The visual defacement attracted attention, but the more important issue was what it revealed about service account scope. One bot account bridged multiple environments. Once its token was stolen, the attacker gained a pivot point into both public and internal ecosystems.

How Did the Checkmarx GitHub Actions Phase Widen the Campaign?

The pivot into the Checkmarx ecosystem confirmed that TeamPCP was not operating as a one-vendor opportunist. It was reusing stolen access and repeating proven tradecraft across different targets.

Two Checkmarx GitHub Actions workflows were compromised: checkmarx/ast-github-action and checkmarx/kics-github-action. The used there matched the same credential-stealing logic seen in the Trivy incident. The payload stole secrets from CI runner environments and exfiltrated them to checkmarx[.]zone, using the same encrypted archive naming convention, tpcp.tar.gz.

The new variant also created a docs-tpcp repository using the victim’s GITHUB_TOKEN if direct exfiltration failed. That mirrored the fallback strategy used earlier in the campaign and reinforced the point that TeamPCP was iterating, not improvising.

The same phase also included malicious OpenVSX extensions published through a compromised account: ast-results v2.53.0 and cx-dev-assist v1.7.0. Once activated, the malicious code checked whether cloud credentials were present and fetched a second-stage payload from checkmarx[.]zone. The official VS Code Marketplace was not affected, but OpenVSX users were exposed.

This multi-pronged pivot mattered because it showed the actor could compromise workflows, registries, and developer tooling at the same time.

Why Was the Shift to Destructive Activity So Alarming?

Credential theft alone would have made this campaign severe. What raised it further was the addition of destructive behavior.

The kamikaze.sh payload evolved through five versions in under three hours. Early versions focused on Kubernetes escape and persistence. Later versions added SSH propagation, Docker API exploitation on port 2375, and more modular delivery. Version 3.3 introduced a notable evasion trick: Python payloads embedded inside valid WAV audio files, using steganography to disguise them as normal media.

The most serious branch of the malware targeted specifically. It checked for Asia/Tehran time zone settings and fa_IR locale indicators before deciding whether to deploy a destructive path. On Kubernetes clusters, the malware could launch privileged DaemonSets such as host-provisioner-iran, mount the host filesystem, and execute rm -rf / –no-preserve-root followed by a forced reboot. On non-Kubernetes Iranian hosts, it could also trigger wiping behavior.

That combination changed the character of the campaign. This was no longer just a credential theft and monetization operation. It was an operation that mixed opportunistic access theft with geographically targeted destructive impact.

What TeamPCP Telegram Activity Suggests About Its Broader Intent?

Telegram messages attributed to TeamPCP suggest the group sees this campaign as part of a broader and continuing operation, not a one-off supply chain compromise.

In other Telegram posts, members discuss leadership transition, working through large stores of stolen credential sets, and continuing to target security tools and open-source projects in the months ahead.

 

TeamPCP & CipherForce

Shared screenshots from the CipherForce leak site also suggest that TeamPCP operates as a CipherForce affiliate, reinforcing that the group’s activity extends beyond CI/CD credential theft into broader extortion-linked operations.

Why Does This Incident Matter to Every Security Team?

The TeamPCP campaign exposed several structural weaknesses that extend far beyond the vendors directly involved.

• Long-Lived Credentials Remain a Major Risk: Service account PATs, package publish tokens, registry credentials, and broad automation secrets still provide durable access that attackers can reuse well after the first incident is detected.
• CI/CD Environments Are Still Under-Monitored: Many organizations apply strong controls to production but far less scrutiny to build runners, release pipelines, and automation hosts. That gap is dangerous because CI/CD infrastructure often has access to source code, signing paths, package publishing rights, and cloud credentials.
• Trust Based on Tags Is Too Weak: The Trivy and GitHub Actions portions of this campaign were especially effective because many workflows referenced tags rather than full commit SHAs. If a tag can be force-pushed, trust can be redirected silently.
• Supply Chain Risk Is Now Identity Risk: The deeper problem in this incident was not only poisoned code. It was the theft and reuse of valid identities. In modern software delivery environments, tokens and service accounts are often the real high-value targets.

When supply chain attacks move across vendors, packages, and developer tooling, point-in-time assessments are not enough. gives organizations continuous visibility into third-party security posture, risk trends, and emerging threats, helping teams prioritize exposures and make better-informed decisions across the extended enterprise.

What Should Security Teams Do Now?

Organizations reviewing exposure to this campaign should focus on both immediate containment and structural hardening.

Immediate Priorities

1. Audit use of checkmarx/ast-github-action and checkmarx/kics-github-action first, especially in repositories that may have executed them during the affected window.
2. Search GitHub organizations for docs-tpcp, tpcp-docs, and similar naming patterns that could indicate fallback exfiltration.
3. Review CI logs and host telemetry for references to checkmarx[.]zone and tpcp.tar.gz, then broaden the hunt to scan.aquasecurtiy[.]org, *.trycloudflare.com, and *.icp0.io.
4. Investigate exposure to malicious OpenVSX extensions, especially ast-results v2.53.0 and cx-dev-assist v1.7.0, and verify whether any affected developer environments had cloud or GitHub credentials present.
5. Rotate all CI/CD-accessible secrets that may have been exposed during the relevant windows, including GitHub PATs, cloud credentials, Docker Hub credentials, npm tokens, and other service account secrets.
6. Inspect Kubernetes clusters for suspicious DaemonSets such as host-provisioner-std and host-provisioner-iran, along with privileged containers using hostPath: /.
7. Look for host-level persistence artifacts, including pgmon.service, pgmonitor.service, internal-monitor.service, /tmp/pglog, and /tmp/.pg_state.
8. Review installed developer extensions and package versions in environments using OpenVSX, npm, PyPI, and Trivy-related images.

Near-Term Hardening Steps

Teams should pin GitHub Actions to full commit SHAs, move CI/CD authentication toward short-lived OIDC-based access where possible, reduce service account scope, verify signature and provenance where available, and apply egress filtering to build runners and Kubernetes nodes. Runtime monitoring should also cover CI and K8s systems with the same seriousness typically reserved for production workloads.

The incident further underscored the necessity for provenance-aware controls such as Sigstore, Cosign, SLSA, and software bill of materials workflows. Those measures do not eliminate supply chain risk, but they make silent trust abuse much harder.

What Do You Need to Know Going Forward?

The TeamPCP incident was a sharp reminder that modern supply chain attacks do not end when the first artifact is identified. They expand through trust relationships, identities, and automation paths that many organizations still treat as background infrastructure.

Three lessons stand out:

1. Incomplete remediation can be as dangerous as the original breach. A token that is not rotated atomically, or a hidden trust path that remains open, can seed a much larger follow-on incident.
2. Software supply chain security has become inseparable from identity security. The key asset is often not the code itself, but the credentials wrapped around the code delivery process.
3. Attack surface matters more than novelty. TeamPCP did not need a single exotic exploit to produce an outsized impact. It chained together familiar weaknesses: long-lived credentials, high-privilege service accounts, trust in mutable tags, under-monitored runners, and connected vendor ecosystems.

Those are the central lessons for defenders. One popular tool can hand legitimate access to hundreds or thousands of organizations by default. One stolen token can bridge public and internal infrastructure. One poisoned action can quietly turn a build pipeline into a secret collection engine.

The industry has already spent years talking about software supply chain risk in abstract terms. TeamPCP showed what that risk looks like when it unfolds at operational speed. The answer is not just faster patching. It is narrower trust, shorter credential lifetime, stronger provenance verification, and better visibility into the places where software is built and released.

MITRE ATT&CK TTPs

Tactic	Technique ID	Technique	Detail
Initial Access	T1195.001	Supply Chain Compromise: Software Dependencies	Poisoned Trivy GitHub Actions, npm packages, PyPI (litellm), and OpenVSX extensions.
Execution	T1059.004	Command and Scripting: Bash/Python	kamikaze.sh acts as the bash loader, while kube.py and prop.py serve as Python controllers.
Persistence	T1543.002	Create/Modify System Process: systemd	pgmon.service and pgmonitor.service are used with Restart=always on compromised hosts.
	T1610	Deploy Container	Privileged Kubernetes DaemonSets are deployed in kube-system, including host-provisioner-std and host-provisioner-iran.
Defense Evasion	T1027	Obfuscated Files / Steganography	Version 3.3 embeds Python payloads inside WAV audio files using base64 encoding.
	T1036	Masquerading	Imposter commits spoof GPG-associated identities, while PostgreSQL-themed service names help blend in.
Credential Access	T1552	Unsecured Credentials in Process Memory	/proc/[pid]/mem scraping targets Runner.Worker, alongside a sweep of 50+ filesystem paths.
Collection	T1560	Archive Collected Data	AES-256-CBC and RSA-4096 hybrid encryption is used to package stolen data into tpcp.tar.gz.
Exfiltration	T1567.001	Exfiltration to Code Repository	A fallback mechanism creates a tpcp-docs repository in the victim GitHub org and uploads stolen data as a release asset.
Lateral Movement	T1021.004	Remote Services: SSH	prop.py harvests ~/.ssh/id_* keys and auth.log entries to support SSH-based spread.
Impact	T1485	Data Destruction	An Iran-targeted wiper executes rm -rf / on Kubernetes nodes and non-Kubernetes Iranian hosts.

Indicators of Compromise (IoCs)

Type	Indicator / Value	Context
Domain	scan.aquasecurtiy[.]org	Primary C2 typosquat; resolves to 45.148.10.212.
IP	45.148.10.212	Command-and-control server.
ICP Canister	tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io	Fallback C2 via Internet Computer Protocol.
CF Tunnel	create-sensitivity-grad-sequence[.]trycloudflare[.]com	Current C2 for versions 3.2 and 3.3; serves kamikaze.sh, bg_kube.wav, and bg_prop.wav.
	championships-peoples-point-cassette[.]trycloudflare[.]com	C2 for versions 3.0 and 3.1; now inactive.
	plug-tab-protective-relay[.]trycloudflare[.]com	Phase 02 exfiltration endpoint tied to tfsec and traceeshark workflow injection.
Domain	checkmarx[.]zone	Phase 08 C2 and second-stage delivery infrastructure for the Checkmarx campaign.
GitHub Commit	70379aad1a8b40919ce8b382d3cd7d0315cde1d0	Imposter commit in actions/checkout, spoofing the rauchg identity.
	1885610c6a34811c8296416ae69f568002ef11ec	Imposter commit in aquasecurity/trivy, spoofing the DmitriyLewen identity.
File	/tmp/pglog; /tmp/.pg_state	Runtime artifacts seen across multiple kamikaze.sh versions as part of PostgreSQL-themed masquerading.
	/var/lib/pgmon/pgmon.py; /var/lib/svc_internal/runner.py	Persistent Python stager paths.
Systemd	pgmon.service; pgmonitor.service; internal-monitor.service	Persistence service names observed across payload versions.
Kubernetes	host-provisioner-std; host-provisioner-iran	Privileged DaemonSet names in kube-system using hostPath:/.
GitHub Repo	tpcp-docs (any org); repos prefixed tpcp-docs-*	Fallback exfiltration repos and internal organization defacement markers.
npm	@EmilGroup (28 packages); @opengov (16 packages); @teale.io; @airtm; @pypestream	npm scopes tied to CanisterWorm-infected packages.
PyPI	litellm==1.82.7; litellm==1.82.8	Compromised PyPI releases later quarantined after a short exposure window.
VSIX	ast-results v2.53.0; cx-dev-assist v1.7.0	Malicious OpenVSX extensions published through the compromised ast-phoenix account.