TeamPCP: How a Supply Chain Attack Hit Build Systems and CI/CD Pipelines

Date Observed: March 2026

Ecosystem: GitHub Actions, npm, PyPI

Targets: Aqua Security Trivy, Checkmarx KICS, BerriAI LiteLLM

Attack Type: Supply chain compromise, mutable tag hijacking, CI/CD credential theft, self-propagating worm, PyPI wheel backdoor

Key Takeaways:

• TeamPCP targeted CI/CD pipelines, not just source code.

• The campaign abused trusted paths like GitHub Actions, npm, and PyPI.

• Once inside the pipeline, attackers could access secrets and credentials.

• Downstream teams could be exposed just by using affected actions or packages.

• The takeaway: code scanning alone is not enough; build systems need runtime protections too.

TeamPCP is a threat actor behind a coordinated 2026 supply chain campaign targeting open-source tools embedded in build systems and CI/CD pipelines. Public reporting linked the activity to compromises involving Aqua Security's Trivy, Checkmarx's KICS, and BerriAI's LiteLLM, with attackers abusing trusted automation, release workflows, and package distribution channels to steal credentials and push malicious code downstream.

One of the most important early pivot points was a Pwn Request against Trivy's CI workflow, which exposed the aqua-bot automation credentials. From there, the campaign expanded across GitHub Actions, npm, and PyPI, using different techniques depending on the target, but with the same practical outcome: compromise the pipeline, steal credentials, and turn trusted software delivery paths into distribution channels for attacker-controlled code.

Scope and Impact of the Attack

Scope

• Multi-ecosystem activity spanning GitHub Actions, npm, PyPI, Docker Hub, and OpenVSX-linked distribution paths

• Confirmed tag hijacking in Trivy and KICS, alongside malicious package distribution through npm and PyPI

• Confirmed compromise of major CI/CD-adjacent tools including Trivy, KICS, and LiteLLM

• Mutable Git tag hijacking used to weaponize trusted GitHub Action references without changing workflow YAML

• Credential pivoting across stages, enabling continued expansion of access

• Self-propagating worm spreading infection to downstream consumers

Impact

The full impact of TeamPCP’s campaign is still being evaluated, but early confirmed effects include:

• compromise of Trivy’s release process, including malicious action-tag retargeting and publication of attacker-controlled artifacts

• distribution of malicious packages or release artifacts through trusted developer channels including npm, PyPI, and container-related workflows

• exposure of CI/CD secrets and automation credentials from runners that executed compromised actions or consumed affected packages

• downstream risk to organizations that ran affected workflows or installed compromised artifacts during the campaign window

How the Attack Works

Stage 0: Pwn Request Against Trivy's CI

TeamPCP exploited Trivy's pull_request_target workflow, a GitHub Actions trigger that runs with base-repository secret access even when initiated from an external fork. A crafted pull request caused the workflow to execute attacker-controlled code, exfiltrating the aqua-bot automation account credentials. This compromise became a major launch point for the Trivy branch of the broader TeamPCP campaign.

Stage 1: Mutable Git Tag Hijacking

Using aqua-bot access, TeamPCP re-pointed existing version tags on the Trivy and KICS GitHub Actions to commits containing malicious shell payloads. No workflow YAML changed; only the commit behind the tag. Any pipeline referencing those tags silently executed attacker code. For KICS, reporting indicates the scope was broader, with malicious code injected across all Git tags, invalidating every pinned historical version simultaneously.

Stage 2: CI/CD Secret Exfiltration

The injected payload harvested GITHUB_TOKEN, repository secrets, environment variables, and, in some cases (AWS, GCP, Azure), cloud provider credentials from the runner. These were exfiltrated through outbound HTTPS requests that could easily blend in with normal pipeline traffic. Public reporting also indicates Trivy was re-compromised again after initial remediation, suggesting the attackers retained or re-established access through stolen credentials or adjacent control paths.

Stage 3: CanisterWorm

TeamPCP deployed CanisterWorm, a self-propagating npm backdoor. It executed during npm publish from a compromised runner, injecting a malicious preinstall script into the package tarball before it reached the registry. That meant downstream projects could become infected simply by installing a poisoned package, even without direct compromise of their source repository.

Stage 4: PyPI Wheel Backdoor

The LiteLLM compromise used a tampered .whl distribution published to PyPI. Public reporting indicates the credential-stealing payload activated on import, putting API keys and service credentials at risk inside affected environments. To a downstream user, the release could appear legitimate unless the wheel contents were independently verified.

Stage 5: tpcp-docs Fallback Exfiltration

As a fallback exfiltration channel, TeamPCP used the stolen GITHUB_TOKEN to create a repository named tpcp-docs inside the victim's own GitHub organization, then pushed harvested credentials to it. This could bypass egress-based network controls focused on unfamiliar external domains as the operation used a legitimate token against GitHub's own API, generating no anomalous external traffic.

Key Capabilities

• Pwn Request: exploitation of pull_request_target to steal release credentials from a privileged CI workflow

• Mutable tag hijacking: silent payload substitution with no workflow file changes

• All-tag compromise: broad weaponization of historical versions, not just the latest release

• CanisterWorm: self-propagating npm backdoor spreading through the publish lifecycle

• PyPI wheel tampering: malicious binary distribution that appeared legitimate to downstream users

• Fallback repo exfiltration: secret staging inside the victim's own GitHub organization using stolen credentials

• Re-compromise after remediation: evidence that stolen credentials or adjacent access paths remained useful even after an initial response effort

Why This Matters to DevOps and DevSecOps Teams

TeamPCP matters because it targeted the build environment itself, not just the source code. The malicious logic arrived through trusted delivery paths such as GitHub Actions, package registries, and release workflows, then executed inside CI/CD systems that often had access to secrets, cloud credentials, and publish permissions.

For DevOps and DevSecOps teams, that changes the problem in three important ways:

• trusted automation can execute attacker-controlled logic without any visible workflow-file change

• secrets and tokens can be exposed during build execution, even when the codebase itself appears unchanged

• downstream consumers can inherit the compromise through routine package install or action usage

This is what makes TeamPCP a Build and CI/CD security problem, not just an open-source malware story.

How InvisiRisk Protects Against This Attack

Network Proxy: C2 Detection at the Build Layer

InvisiRisk BAF operates inside the CI/CD environment as a policy enforcement point for build-time traffic. When a compromised GitHub Action, package, or publish workflow attempts to beacon to attacker infrastructure, the connection can be intercepted and blocked before data leaves the runner.

Encrypted Secret Detection in Transit

Because build pipelines routinely handle tokens, API keys, and other sensitive credentials, outbound traffic from the runner is a critical control point. InvisiRisk can inspect build-time outbound requests for patterns associated with credential exfiltration, including encoded secrets and suspicious outbound payloads, before those requests are allowed to proceed. Even attempts to exfiltrate secrets over TLS can be detected and blocked when build traffic is routed through the InvisiRisk BAF.

Stability Buffer

A stability buffer helps reduce exposure to freshly published packages before the broader ecosystem has had time to identify and respond to malicious releases. In a campaign like TeamPCP, that kind of hold period can help prevent compromised packages from being pulled directly into sensitive build workflows during the highest-risk window.

Unauthorized GitHub API Enforcement

InvisiRisk can also enforce policy around outbound calls to GitHub APIs during the build, including blocking PUT and POST calls outside the expected build scope. If a compromised workflow attempts to create repositories, modify releases, or perform other write operations outside the expected scope of the job, those requests can be blocked or flagged for review. When TeamPCP's payload attempts to create the tpcp-docs repository using the stolen token, InvisiRisk's policy on unauthorized write operations would prevent the API call from completing, shutting down the fallback exfiltration channel entirely.

TeamPCP's campaign shows how quickly a single CI/CD credential theft event can expand into tag hijacking, malicious package distribution, secret exfiltration, and downstream propagation. For teams that rely on open-source tooling in automated pipelines, the build environment is now part of the software supply chain attack surface. Without stronger controls on what can execute, connect outbound, and access secrets during the build, defenders are likely to remain a step behind attacks like this.