TeamPCP Hackers Abuse CI/CD Pipelines to Steal Developer and Cloud Credentials

TeamPCP is using trusted CI/CD pipelines, developer tools, and open-source release workflows to steal credentials from cloud and software environments at scale.

Trend Micro’s latest research links the April 22 Checkmarx KICS incident and the April 24 elementary-data compromise to a broader TeamPCP supply chain campaign. The attacks show how a single poisoned build step or release workflow can expose GitHub tokens, cloud keys, SSH material, Kubernetes secrets, database credentials, and package publishing tokens.

The campaign is especially dangerous because it abuses trusted software delivery paths. Developers and CI runners execute the poisoned components as part of normal scanning, packaging, publishing, or deployment activity.

TeamPCP targets trusted development infrastructure

TeamPCP, also tracked by Trend Micro as SHADOW-WATER-058, is a financially motivated threat cluster tied to multiple supply chain incidents across developer and cloud-native ecosystems.

The group has targeted security tools, AI-related packages, Python packages, Docker images, GitHub Actions workflows, VS Code extensions, OpenVSX extensions, and package release pipelines.

These attacks do not depend on tricking one employee into opening a file. They exploit the trust that organizations already place in build systems, package registries, automation jobs, and signed releases.

Targeted area	Why attackers want it
GitHub Actions	CI workflows often have access to repository tokens and deployment secrets.
Docker images	Containers can run automatically in developer machines and build pipelines.
PyPI packages	Python packages can reach data, cloud, and automation environments quickly.
VS Code and OpenVSX extensions	Developer extensions can run inside trusted local workstations.
Release pipelines	Compromised workflows can publish malicious builds that look legitimate.

Checkmarx KICS was hit through multiple channels

In the Checkmarx KICS incident, attackers poisoned several distribution paths linked to the infrastructure-as-code scanner. The affected channels included Docker Hub, VS Code, OpenVSX, and GitHub Actions.

KICS is a security tool used to scan infrastructure-as-code files. That makes it a valuable target because it often runs near sensitive cloud templates, configuration files, tokens, and deployment data.

According to Trend Micro, the malicious KICS artifacts pulled a JavaScript credential stealer that ran during what appeared to be a normal KICS scan. BleepingComputer also reported that the compromise affected Docker images and code extensions used by developers.

• The KICS campaign abused trusted developer and security tooling.
• The poisoned artifacts targeted sensitive development and cloud credentials.
• The payload ran during normal scanning activity.
• The incident later connected to a downstream Bitwarden CLI compromise.
• Checkmarx said previously published known-safe versions were not overwritten.

The elementary-data compromise abused GitHub Actions

The elementary-data incident followed a different path but reached a similar result. Attackers exploited a GitHub Actions script injection issue in the project’s workflow and used the project’s own release automation to publish a malicious package.

StepSecurity reported that elementary-data version 0.23.3 was uploaded to PyPI on April 24, 2026. The same release run also pushed a container image to GitHub Container Registry tagged as 0.23.3 and latest.

Snyk said the package contained a malicious elementary.pth file. Python processes .pth files during interpreter startup, which means the payload could run when Python started, even if the user did not directly import the elementary-data package.

Incident	Attack path	Main risk
Checkmarx KICS	Poisoned Docker images, extensions, and GitHub Actions workflows	Credential theft from developer and CI/CD environments
elementary-data	GitHub Actions script injection and forged release automation	Malicious PyPI package and compromised container image
Bitwarden CLI follow-on	Use of stolen tokens after the KICS incident	Downstream compromise through trusted package publishing

What the stealers tried to collect

The TeamPCP payloads focused heavily on secrets that let attackers move from one environment to another. Trend Micro said the malware targeted GitHub personal access tokens, npm tokens, cloud credentials, SSH keys, Kubernetes secrets, database credentials, infrastructure-as-code files, and cryptocurrency wallet keystores.

The elementary-data stealer also made live AWS API calls to Secrets Manager and SSM Parameter Store. That matters because some secrets may never exist as local files but can still be pulled through cloud APIs if the infected runner has enough permissions.

Snyk also reported that the elementary-data malware targeted dbt profiles, Snowflake, BigQuery and Redshift credentials, AWS, GCP and Azure keys, API tokens, SSH keys, and .env files.

• GitHub tokens and repository credentials
• Cloud access keys and service account files
• AWS Secrets Manager and SSM Parameter Store data
• Kubernetes service account tokens and kubeconfig files
• SSH keys and Git credential stores
• Database and data warehouse credentials
• npm, PyPI, and other package publishing tokens
• Cryptocurrency wallet files and keystores

Why CI/CD runners are high-value targets

CI/CD runners often sit at the center of software delivery. They fetch code, run tests, build packages, push containers, sign releases, and deploy workloads to cloud environments.

That means a poisoned workflow may have access to secrets that a normal workstation does not. In many environments, build jobs can read deployment tokens, package registry credentials, signing keys, Kubernetes access files, and cloud IAM credentials.

This creates a dangerous chain reaction. A single compromised workflow can leak tokens, those tokens can publish more malicious artifacts, and those artifacts can reach other users or projects.

The broader TeamPCP campaign keeps expanding

Unit 42 previously said TeamPCP had moved through a sequence of supply chain attacks affecting tools such as Trivy, KICS, LiteLLM, and the Telnyx Python SDK. Arctic Wolf also warned that TeamPCP could continue pivoting to new projects as long as stolen credentials and trust relationships remain useful.

The campaign has also continued beyond the April incidents. StepSecurity reported in May that TeamPCP launched a new Mini Shai-Hulud wave affecting TanStack npm packages and other npm ecosystem projects through hijacked CI/CD release paths.

This pattern suggests the group is not focused on one package or one registry. It is looking for weak points in how open-source projects build, sign, and publish trusted software.

Defense priority	Why it matters
Pin dependencies and container digests	Mutable tags can pull malicious builds after compromise.
Limit CI/CD secret access	Compromised jobs should not expose every production credential.
Restrict runner egress	Outbound allowlists can block credential exfiltration.
Use short-lived tokens	OIDC-based publishing reduces damage from stolen long-lived secrets.
Audit workflow inputs	User-controlled comments and pull request data should not flow into shell commands.

What affected organizations should do

Organizations that used affected Checkmarx KICS artifacts, impacted extensions, compromised Docker images, or the malicious elementary-data 0.23.3 package should treat exposed environments as compromised.

Teams should rotate every secret available to affected runners, developer workstations, and containers. That includes GitHub tokens, cloud IAM keys, Kubernetes service account tokens, SSH keys, package registry tokens, database credentials, and secrets stored in environment variables.

They should also review CI logs, package installation logs, Docker image digests, release workflow activity, outbound network activity, and suspicious package publishing events.

1. Identify runners, workstations, and containers that used affected artifacts.
2. Remove malicious packages, images, and extensions.
3. Rebuild affected environments from clean sources.
4. Rotate GitHub, cloud, SSH, Kubernetes, database, npm, and PyPI credentials.
5. Review CI/CD workflow logs for suspicious commands and exfiltration attempts.
6. Check whether stolen tokens were used to publish or modify other packages.
7. Pin future image pulls to verified digests instead of mutable tags.

How maintainers can reduce the next supply chain breach

Package maintainers should audit workflows that process issue comments, pull request comments, pull_request_target events, and other user-controlled GitHub context values.

Untrusted input should not be inserted directly into shell commands. If workflows must process comments or PR data, they should pass the content through environment variables and apply validation before execution.

Release workflows also need stricter controls. Maintainers should avoid long-lived publishing tokens, use trusted publishing where possible, require human approval for sensitive release jobs, and separate build jobs from publishing jobs.

• Remove unnecessary write permissions from GitHub Actions tokens.
• Set least-privilege permissions at workflow and job level.
• Use protected environments for publishing jobs.
• Require manual approval for production releases.
• Prefer OIDC and trusted publishing over long-lived API tokens.
• Block outbound CI traffic except to approved services.
• Scan release artifacts before publishing them.

TeamPCP shows the new shape of supply chain attacks

The TeamPCP campaign shows that CI/CD security is now a direct part of cloud security. Attackers no longer need to break into production first if they can compromise the tools that build, scan, sign, or deploy production code.

Security tools and developer packages make attractive targets because organizations trust them by default. When attackers poison those channels, malicious code can run in high-value environments before defenders see anything unusual.

The safest response is to reduce implicit trust. Development teams should pin dependencies, limit runner permissions, restrict egress, remove long-lived secrets, and treat every workflow step as code that can become part of an attack chain.

FAQ