Executive summary
From late 2025, a threat actor group calling itself TeamPCP has turned the tools and practices built for high-velocity software deployment into delivery mechanisms for malware.
While the group has used a variety of methods to target organizations, the most impactful methods target organizations use GitHub features as part of their Continuous Integration/Continuous Delivery (CI/CD) pipeline.
TeamPCP has leveraged access to tools used in these pipelines to distribute credential-stealing malware - hoovering up package registry tokens, cloud credentials, SSH keys, Git credentials, personal access tokens and any secret available in a CI/CD environment.
In this post, we’ll look at:
The mechanism of these attacks, including the exploitation of the pull_request_target trigger in GitHub Actions.
How to apply identity and access management controls to protect developer and maintainer accounts,
Ways to minimize exposure to supply-chain risk
Background
Modern software development
Modern software is most often built on top of a vast ecosystem of established free and open-source software. The contributions of cryptographic libraries like OpenSSL, programming languages like Python and package ecosystems such as npm underpin today’s critical infrastructure and our daily experience of the internet. Open-source projects are often run by volunteers who contribute features and maintain code. While for-profit software companies that use open-source software may choose to contribute financial or development, for the most part, open source projects are labors of love.
Software supply-chain attacks are a pervasive risk. Open-source software can be exposed to every kind of attack - from email takeovers due to expired domains, binary takeovers due to deleted S3 buckets, bad actors infiltrating the community, changes in repository ownership, or malware hidden in poisoned package updates.
Open source software is published in public code repositories like GitHub and in package registries such as npm and the Python Package Index (PyPi). A fully fledged software program may contain dozens or hundreds of open-source software packages, libraries and frameworks. Each of these components, known as dependencies, is periodically updated with new features, security patches or stability fixes, all of which need to be updated in the downstream products that use them.
The key to dealing with this complexity is automation. If a maintainer patches a vulnerability in a library, the update can be distributed and applied automatically. This allows developers to close the window of opportunity from when a vulnerability is disclosed to when it is patched. In some configurations, software packages are updated without human intervention.
But there’s a tradeoff. These same automations can conversely be abused as malware delivery systems. Attackers can sneak backdoors or credential-stealing malware into a legitimate product or masquerade as a benign dependency. These attacks are particularly dangerous because they leverage the key strength of the modern software development lifecycle: scale and automation.
Don’t pull the pull_request_target trigger
In the last few months, attackers have recycled a years-old attack technique.
GitHub’s free Dependabot tool scans dependencies and automatically opens a pull request (a proposed code change) informing maintainers when a component needs to be updated. To move even faster, a pull request can be configured to trigger a workflow, which are automations executed by GitHub’s built-in CI/CD platform, GitHub Actions.
GitHub developed the pull_request_target trigger to allow maintainers more flexibility when dealing with a pull request that came from a fork (an independent copy of a repository). Compared to the already existing pull_request trigger where actions are run against the fork, pull_request_target runs the actions at the original repository. This functionality allowed maintainers of the repository to set up tasks like maintenance automations, test integrations or other CI workflows for pull requests.
In many cases these set ups require access tokens that live within the Github Actions workflows. Workflows are .yaml files that describe an automation job and what tools to use. This is a prime target for opportunistic malicious actors, particularly if those access tokens are long lived and broadly scoped. The hacking community coined their own term for abuse of the pull_request_target feature for malicious purposes: a “Pwn Request.”
GiHub warned of misuse in 2021 and again in 2025. The warning last year was explicit:
A malicious actor can submit a seemingly innocuous pull request that, when triggered by pull_request_target, unleashes havoc. This malicious code, running in the context of the target repository’s environment, could exfiltrate secrets or even tamper with repository contents and releases.
TeamPCP
TeamPCP is a financially-motivated cybercrime actor that first surfaced in late 2025. The group, also tracked as DeadCatx3, PCPcat, ShellForce, and CipherForce, created the Telegram group ID “Team_PCP,” which was initially named “Black Witch / PCP.”
This threat group focuses on gaining initial access to their target’s GitHub repositories by exploiting known weaknesses in GitHub configurations. The group seeks to abuse these weaknesses to create and distribute malicious updates to widely-used software. Updates are modified to steal secrets, credentials, personal access tokens, API keys and any other secret on a compromised device. This credential theft enables follow-on attacks against entities that have not revoked or rotated credentials.
Constant target
While hunting for repos that use GitHub Actions workflows with pull_request_target was the attack du jour for 2026, it’s far from the only threat targeting open source maintainers. Several software supply chain attacks have also started after attackers targeted the online accounts of maintainers.
In September 2025, threat actors compromised the account of a prolific open-source npm maintainer via a targeted email phishing attack, under the pretext that the maintainer needed to reset their two-factor authentication (2FA). The email warned that accounts with “outdated” 2FA credentials would be locked two days later. The maintainer's credentials were abused to update at least 18 packages with code that monitored for cryptocurrency transactions and replaced destination wallets with those controlled by attackers.
In July 2025, the Python Package Index Blog disclosed ongoing phishing attacks targeting its users via email. The attackers used email addresses that were included as part of package metadata. PyPi disclosed that four user accounts were compromised in an Adversary-in-the-Middle (AitM) style phishing attack during these campaigns. The attackers abused this access to create two API tokens and released malicious versions of the num2words package. PyPi noted that the attacks would not have succeeded if strong, phishing-resistant authentication had been required.
Recommendations
Unless an organization has the resources and means to inspect every single open-source dependency before it is merged, there will always be some degree of exposure to supply-chain risk. These risks can be minimized. Supply-chain security is a large, complex subject, and this post will not attempt to cover it all. Below are some of the more broadly applicable practices based on our own experience, plus specific configuration advice for GitHub Actions and a reading list for further resources.
Cooldown period: Fortunately, malicious updates to popular open-source packages with hundreds of thousands of installs per week tend to be discovered quickly. Many organizations hold off on installing the latest version, known as an n-1 patching strategy, or staying one or two versions behind unless there is an urgent need to update.
Even a short delay may be of benefit. The pnpm project, a high-performance alternative to npm, recently introduced a minimum release age of 24 hours as a default in its pnpm 11.0 release to provide time for differential analysis. Developers can, however, override the setting. With that setting, pnpm will not install dependencies or transitive dependencies until a specific window of time has passed, allowing for detection and removal of malicious versions in the registry.
Software bill of materials (SBOMs): SBOMs are machine-readable descriptions of the libraries, dependencies and other components of a software product. SBOMs are intended to allow for the quick identification of possible vulnerable or tampered software in order to mitigate supply-chain risks.
SBOMs can answer the critical questions after a new supply-chain incident, such as whether the vulnerable component has been downloaded during the exposure period and if the component has been deployed to production. This knowledge can be useful for remediation, particularly when a large number of credentials need to be revoked and rotated.
Audit dependencies: A Software Composition Analysis (SCA) tools analyze open-source dependencies to surface vulnerabilities and associated risks such as reputational ones, licenses, number of downloads, install scripts, and maintenance status.
Npm’s command-line interface has the npm audit command, which generates a report on vulnerabilities based on GitHub Advisories in a software project based on the registry used. More comprehensive tools, such as Snyk and Socket.dev, integrate with GitHub and are free for open-source and individual developers.
GitHub Actions: The quickest fix for the pull_request_target attack vector is to avoid it where possible. Security teams can scan all GitHub Actions workflows and remove pull_request_targets trigger for a workflow if that functionality is not required.
Workflows in GitHub Actions point to dependencies using tags. These are mutable. If a maintainer account is compromised, a GitHub Action workflow could also be modified to a tag for a specific commit that has been compromised.
To guard against this, GitHub introduced SHA pinning for Actions. Rather than pointing at a version tag for a dependency, maintainers can specify a hash for the dependency when the workflow runs.
Protect developer and maintainer accounts: Open-source project maintainers play a critical role in the software supply chain and are targeted routinely. GitHub has supported passkey-based authentication since 2023. Based on the FIDO2/WebAuthn standards, passkeys are cryptographically tied to a domain at enrolment making them impossible to use on a lookalike phishing site. Passkeys can be implemented in both hardware and software to cater for different use cases.
The credential-stealing malware used in the attack described earlier in this post targeted nearly every kind of developer credential. Developer workstations often access production environments and tore the sort of secrets attackers lust for. Again, implementing phishing-resistant authentication using passkeys or security keys that is enforced in policy is recommended. Additionally, requiring more than one approval before a pull request is merged can increase the chance of detecting suspicious behavior. Also, all pull requests and commits should be digitally signed to ensure only an authorized user is contributing.
Further reading
Okta Threat Intelligence has prepared an interactive table of TTPs used in TeamPCP attacks, which is available to the security contacts of Okta customers at our Security Trust Center:
https://security.okta.com/product/oktathreatintelligence/defending-against-teampcp-software-supply-chain-attacks
Defending Against Software Supply Chain Attacks - Cybersecurity Infrastructure and Security Agency (CISA):
https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf
Software Security in Supply Chains - National Institute of Standards and Technology (NIST)
https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains
Supply Chain Security Guidance - UK National Cyber Security Centre (NCSC):
https://www.ncsc.gov.uk/collection/supply-chain-security
Software Supply Chain Security Cheat Sheet - Open Worldwide Application Security Project (OWASP):
https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html
