CI/CD Credential Theft: TeamPCP Turns GitHub Actions Into the Release Channel

A software engineer works on a laptop at a tidy desk in a bright office, with a potted plant and a monitor.

A single unsanitized pull-request comment on the elementary-data repository was enough to turn the project’s own GitHub Actions release pipeline into the attacker’s delivery channel, according to research from Trend Micro’s TrendAI Research team on the TeamPCP campaign. The poisoned package was signed by the project’s legitimate CI and published to the Python Package Index (PyPI) and the GitHub Container Registry (GHCR), where it passed every standard verification check. The pattern reframes CI/CD credential theft: stealing maintainer credentials is no longer a prerequisite for releasing a malicious build under a project’s name.

  • TeamPCP, tracked by Trend Micro as SHADOW-WATER-058, has run at least seven supply chain waves from March 19 through April 24, 2026, hitting Trivy, Checkmarx KICS, Telnyx, LiteLLM, Xinference, elementary-data, and downstream Bitwarden CLI.
  • The April 22 Checkmarx KICS compromise simultaneously poisoned Docker Hub, VS Code/OpenVSX, and GitHub Actions for 83 minutes before Docker monitoring flagged the intrusion.
  • Stolen npm tokens from KICS were operationalized within 24 hours to hijack @bitwarden/cli v2026.4.0; Bitwarden confirmed roughly 334 downloads in a 93-minute exposure window.
  • The Vect ransomware group began publishing victims on April 15, 2026, using credentials attributed to TeamPCP exfiltration.

How TeamPCP turns the project’s CI into the release channel

The elementary-data incident is the version of the attack that should worry CISOs most. The actor posted one comment to a GitHub pull request on April 24, 2026, used the resulting runner token to forge a tagged release commit, and triggered the project’s own signing infrastructure. PyPI and GHCR accepted the package because the project built it. There was no maintainer compromise, no leaked secret, no phished password. The trust boundary failed at the comment-handling code path of the workflow itself.

The Checkmarx KICS wave from two days earlier ran a noisier version of the same idea. TeamPCP overwrote six checkmarx/kics Docker Hub tags including v2.1.20 and latest, pushed poisoned cx-dev-assist and ast-results extensions to VS Code and OpenVSX, and modified the checkmarx/ast-github-action workflow to inject a format-check.yml file that serialized every repository secret via the toJSON(secrets) expression. The payload ran for 83 minutes across three distribution channels before Docker’s monitoring caught it. Trend Micro’s analysis confirmed identical command-and-control infrastructure, encryption scheme, Bun runtime version, and Dune-themed staging repositories across the KICS and Bitwarden payloads.

Why CI/CD credential theft scales without maintainer takeovers

Most CI/CD cybersecurity strategy guidance still treats the maintainer credential as the keystone: rotate the personal access token, require hardware MFA, gate publishing to a small group. TeamPCP’s elementary-data wave proves the keystone has moved. When the pipeline trusts the comment-handling logic of its own pull-request workflow, the GITHUB_TOKEN issued to that workflow inherits the same release authority the maintainer would have used. The signing infrastructure cannot tell the difference, because there is no difference to tell.

The contrarian read is that signed artifact attestation, in its current shape, mostly answers the wrong question. Sigstore and similar mechanisms verify that the binary came from the project’s CI; they do not verify that the CI was triggered by a maintainer action rather than by an attacker action with maintainer-equivalent privilege. Trend Micro’s payload analysis confirms the operational consequence: the stealer targets GitHub PATs, npm tokens, AWS, Azure, and Google Cloud credentials, SSH material, Kubernetes secrets, and AI assistant configs including ~/.claude.json. In elementary-data, the stealer also made live AWS API calls to enumerate and pull secrets from AWS Secrets Manager and AWS Systems Manager Parameter Store, going past disk-resident files into the cloud control plane.

Restrict the workflow trigger, not just the maintainer

The defensive response runs in three steps, each cutting a different attack path the TeamPCP waves exercised.

Disable pull-request workflow triggers from forks and restrict comment-triggered workflows to maintainer accounts. The elementary-data wave used a comment on a pull request to obtain a runner token; switching the workflow trigger from pull_request_target to pull_request blocks the privileged variant, and gating any comment-triggered actions on a CODEOWNERS check blocks the rest. This is the cheapest control and the one that would have stopped the April 24 release outright.

Pin Docker image references and GitHub Actions to immutable digests, not tags. The KICS Docker Hub wave overwrote six tags including latest. A build pipeline that pulls checkmarx/kics:latest gets whatever the registry serves at pull time; one that pulls by sha256 digest gets the bytes it last verified. The same applies to uses: org/action@v1 references in GitHub Actions workflows; pin to a commit SHA, not to a moving tag.

Move CI runner secrets to OIDC short-lived tokens and audit the toJSON(secrets) expression. Most stolen credentials in this campaign were long-lived static secrets stored in repository or organization secret stores. OpenID Connect (OIDC) federation between GitHub Actions and AWS, Azure, or Google Cloud removes the long-lived key entirely; the runner exchanges its identity for a short-lived token at runtime. Pair that with a grep across every workflow for toJSON(secrets) or contains(secrets, the pattern KICS used to exfiltrate the full secret bundle in one expression. The next TeamPCP wave of CI/CD credential theft is already in scope: an attacker who controls a pull-request comment in your repository has the same release authority the April 24 elementary-data maintainers thought only they held.

Join our LinkedIn group Information Security Community!

Holger Schulze
Holger Schulze is the founder and publisher of Cybersecurity Insiders, an independent cybersecurity media and research company. The publication centers on the security domains under the most pressure from AI: identity and phishing resistance, incident response velocity, application security, and threat intelligence tradecraft. Coverage maps the readiness gap between where CISO teams sit today and where AI-era attack speed is pushing them, and which moves close it fastest. Writing here applies Cybersecurity Insiders' Capability and Coherence Maturity Model to primary-research data and named incident analysis, evaluating security programs across the reactive, managed, and adaptive maturity tiers. Holger moderates the Information Security Community on LinkedIn, one of the largest cybersecurity professional networks. Connect at linkedin.com/in/holger-schulze.

No posts to display