Two Alleged TeamPCP Hackers Charged in Australia After Massive Software Supply Chain Attacks

Australian authorities have charged two Western Australian men over their alleged roles in TeamPCP, a cybercrime operation accused of compromising trusted open-source software and using stolen developer credentials to launch a cascading series of supply chain attacks. The campaign targeted security tooling and AI infrastructure, potentially exposing more than 1,000 organizations and hundreds of thousands of CI/CD environments.

The Australian Federal Police (AFP) has charged two Western Australian men over their alleged involvement in TeamPCP, a cybercrime syndicate accused of weaponizing trusted open-source software to compromise organizations around the world.

Ruben Ian Thomson, 21, and Louis Michael Gaebler, 23, were charged with a combined 14 offences following coordinated searches in Western Australia. The arrests followed an investigation involving the AFP, Western Australia Police Force (WAPF) and the U.S. Federal Bureau of Investigation (FBI). Police allege the pair were principal participants in a sophisticated cybercrime operation involved in data intrusion, identity crime and cryptocurrency-related activity.

The case represents a significant development in the investigation of TeamPCP, a threat actor associated with a series of software supply chain compromises that affected security tools, developer infrastructure, package registries and AI software.

The group did not need to compromise every victim individually. Instead, the attackers targeted the software and development infrastructure that thousands of organizations already trusted.

A compromised application can affect one organization. A compromised developer tool can potentially reach every organization that installs it, runs it in a build pipeline or trusts credentials available to that pipeline.

In the TeamPCP campaign, compromised software became a mechanism for harvesting the credentials needed to compromise additional software. The result was a self-reinforcing attack chain that moved through GitHub Actions, Docker Hub, npm, PyPI and OpenVSX, turning the software development ecosystem itself into the propagation mechanism.

According to the AFP, malicious code associated with the campaign potentially compromised more than 1,000 organizations globally, stole more than 500,000 credentials and resulted in the exfiltration of at least 300 GB of data. Those figures describe potential exposure rather than a confirmed compromise of every organization counted in the broader datasets.

Two Australians Face 14 Cybercrime Charges

The AFP and WAPF executed search warrants at properties in Cottesloe, Hamilton Hill and Mandurah on August 26, seizing electronic devices and other material for forensic examination. The two men subsequently appeared before the Perth Magistrates Court on August 27.

Thomson, from Cottesloe, faces eight charges, including:

• One count of possessing data with intent to commit a computer offence
• Four counts of unauthorized modification of data with intent to commit a serious offence
• One count of supplying data with intent to commit a computer offence
• One count of failing to comply with a Section 3LA order
• One count of dealing with proceeds of crime worth $100,000 or more

Gaebler, from Mandurah, faces six charges:

• One count of possessing data with intent to commit a computer offence
• Four counts of unauthorized modification of data with intent to commit a serious offence
• One count of supplying data with intent to commit a computer offence

The Section 3LA charge carries a maximum penalty of 10 years’ imprisonment, while the proceeds-of-crime charge carries a maximum penalty of 20 years. None of the charges publicly identifies a specific compromised software project.

The charges are allegations, not convictions. The defendants are entitled to the presumption of innocence unless and until proven guilty in court.

The AFP and FBI said their investigation began after receiving information from cyber threat intelligence organizations about a syndicate allegedly inserting malicious code into software distributed through open-source repositories. The investigation expanded into a parallel international effort in April 2026.

Why the TeamPCP Campaign Is Different

Traditional cyberattacks often follow a relatively direct path:

Attacker → vulnerability → victim

TeamPCP’s supply chain strategy introduced another layer:

Attacker → trusted developer/project → compromised build or release mechanism → downstream software → CI/CD pipeline → credentials → additional projects → more victims

That difference dramatically changes the economics and scale of an intrusion.

Instead of individually exploiting thousands of companies, an attacker can compromise one widely trusted component and allow normal software development processes to distribute the malicious code.

KrebsOnSecurity’s reporting describes TeamPCP’s approach as a cyclical exploitation model in which attackers compromised an open-source project, used the resulting access to steal credentials, and then used those credentials to compromise another developer tool. The newly compromised tool could then provide another set of credentials and another path into the software ecosystem.

The March 2026 attacks against Trivy, Checkmarx KICS and LiteLLM provide one of the clearest examples of this technique.

Trivy Was the Initial High-Value Target

One of the most important elements of the campaign was the compromise of Aqua Security’s Trivy, an open-source vulnerability scanner widely used in modern software development and CI/CD pipelines.

According to Unit 42, the campaign’s latest phase began on March 19, 2026, after TeamPCP exploited an incomplete credential rotation following an earlier compromise involving the Trivy GitHub repository.

The attackers compromised the aqua-bot service account and used an imposter commit attack, force-pushing malicious code into 76 of 77 version tags in the aquasecurity/trivy-action repository and all tags in aquasecurity/setup-trivy.

This was an especially valuable position for an attacker.

A vulnerability scanner normally operates inside environments where security-sensitive information is readily available. CI runners may have access to cloud credentials, source repositories, package publishing tokens, Kubernetes credentials, SSH keys and environment variables.

The attacker therefore did not necessarily need to exploit the application being scanned.

They could compromise the scanner.

Unit 42 found that the TeamPCP payload was designed to fingerprint the environment and harvest credentials, including AWS, Google Cloud and Azure credentials. The malware also targeted .env files and cloud configuration directories.

This is an important security lesson: a security tool is not automatically a trusted security boundary.

If a scanner has access to secrets, a compromised scanner can become a credential theft platform.

Stolen Trivy Credentials Were Used Against Checkmarx KICS

Two days later, the attackers reportedly used stolen GitHub Personal Access Tokens to target Checkmarx KICS, an open-source Infrastructure-as-Code security scanner.

Unit 42 says TeamPCP force-pushed malicious commits into all 35 version tags of checkmarx/kics-github-action and compromised version 2.3.28 of checkmarx/ast-github-action. The attackers replaced or interfered with the legitimate container entrypoint and introduced another version of their cloud-stealing payload.

The attack also demonstrated an important fallback technique.

If the primary command-and-control channel was unavailable, the malware could use the victim’s own GITHUB_TOKEN to create a hidden repository named docs-tpcp inside the victim’s GitHub organization.

That approach illustrates why defenders should not focus exclusively on conventional network indicators.

An attacker can sometimes use the victim’s legitimate cloud or source-control infrastructure as part of the attack itself.

The traffic can therefore look much more like normal developer activity than a traditional malware connection.

LiteLLM Turned the Attack Into an AI Supply Chain Problem

The next stage was particularly consequential because it involved LiteLLM, an open-source AI gateway used to route requests between applications and multiple large language model providers.

Rather than directly attacking thousands of AI applications, TeamPCP allegedly used the compromised Trivy environment to obtain credentials associated with LiteLLM’s development pipeline.

Unit 42 says the attackers subsequently poisoned the LiteLLM CI/CD process and published malicious versions 1.82.7 and 1.82.8 to PyPI.

The technical details of version 1.82.8 were particularly significant.

The malicious package contained a Python .pth file named:

litellm_init.pth

Python processes .pth files during interpreter initialization. As a result, the malicious code could execute when Python started, rather than requiring an application to explicitly import LiteLLM.

That greatly expanded the potential execution surface.

In other words, an organization did not necessarily have to call a malicious LiteLLM function for the payload to become relevant. A Python environment processing the malicious package could trigger the code during interpreter startup.

Unit 42 found that the payload used multiple layers of Base64 encoding and harvested a broad range of secrets, including SSH keys, AWS, Google Cloud and Azure credentials, Kubernetes configuration and environment variables containing AI provider credentials such as OpenAI and Anthropic API keys.

The stolen data was encrypted before exfiltration using AES-256-CBC, with the session key protected by a hard-coded 4096-bit RSA public key. The researchers also identified attacker-controlled infrastructure designed to resemble legitimate vendor domains.

This is where the TeamPCP campaign moves beyond a conventional malicious-package incident.

The objective was not simply to infect developers. It was to reach the secrets surrounding the software development process.

The LiteLLM Attack Was Much Larger Than Two Malicious Packages

The two malicious LiteLLM releases were short-lived, but the downstream consequences were much larger.

CloudSEK’s reconstruction found potential exposure involving more than 2,500 organizations and approximately 434,000 CI/CD pipelines.

That number needs to be interpreted carefully.

A pipeline appearing in an exposure dataset does not necessarily mean the organization suffered a confirmed breach. Credential exposure, credential theft, successful authentication and subsequent abuse are different events.

CloudSEK itself distinguishes credential exposure from proof that an organization was successfully compromised. The confirmed victim set is therefore substantially narrower than the broadest reconstructed exposure figures.

The datasets nevertheless demonstrate the scale of the attack.

StepSecurity’s analysis of the CloudSEK data reportedly identified more than 1,000 organizations associated with GitLab, 618 involving GitHub Actions, 233 involving Azure DevOps, 105 involving Jenkins, 94 involving Bitbucket Pipelines and 15 involving CircleCI.

That makes the incident less about one package and more about the security architecture of modern software development.

Why CI/CD Pipelines Are Such Valuable Targets

CI/CD systems are designed to automate software delivery.

A typical pipeline can:

1. Download dependencies.
2. Compile source code.
3. Run security scanners.
4. Build containers.
5. Sign artifacts.
6. Publish packages.
7. Deploy applications.
8. Access cloud infrastructure.
9. Read secrets required for those operations.

The automation that makes CI/CD powerful also makes it attractive to attackers.

If a malicious dependency executes inside a privileged runner, the attacker may inherit the permissions assigned to that runner.

This creates a dangerous trust relationship:

Software does not have to be malicious when it enters the pipeline. It can become malicious because the pipeline itself has been compromised.

TeamPCP repeatedly exploited this principle.

The initial compromise produced credentials. Those credentials enabled another compromise. That compromise produced another set of credentials. The resulting access could then be used against another package ecosystem.

The software supply chain effectively became a ladder.

The Numbers Tell Different Parts of the Story

Several figures are now associated with the TeamPCP campaign, and they should not be treated as interchangeable.

The AFP says malicious code potentially compromised more than 1,000 organizations, stole more than 500,000 credentials and resulted in at least 300 GB of data exfiltration.

CloudSEK’s later reconstruction estimated exposure involving more than 2,500 organizations and approximately 434,000 CI/CD pipelines.

Hudson Rock’s analysis of attacker-related material identified 118,829 CI runner dumps associated with 2,488 corporate domains from a 153 GB archive.

These figures answer different questions.

The AFP numbers describe the authorities’ assessment of the criminal campaign and its potential global impact.

CloudSEK’s numbers describe reconstructed exposure across a much broader dataset.

Hudson Rock’s figures describe a dataset of captured CI runner material.

The safest interpretation is therefore not that “2,500 companies were hacked,” but that thousands of organizations may have had development infrastructure or credentials exposed through the campaign, while confirmed compromise represents a smaller subset.

TeamPCP Did Not Stop With GitHub and PyPI

The group’s activity extended across multiple software ecosystems.

The campaign involved GitHub Actions, Docker Hub, npm, PyPI and OpenVSX, according to the supplied investigation. The common denominator was not the specific programming language or registry.

It was trust.

The attackers repeatedly targeted credentials that could authorize software publication or modify trusted development workflows.

That strategy continued after the March campaign.

In August 2026, Socket researchers reported another active supply chain compromise involving the popular npm packages keyv and cacheable. At least ten packages were published with a malicious preinstall hook capable of downloading a standalone Bun runtime, executing an additional payload, harvesting cloud and CI credentials and republishing compromised packages using stolen npm credentials.

Socket did not recover definitive self-identifying markers tying that specific wave to a named campaign, so it should not automatically be attributed to TeamPCP.

The broader significance, however, is clear: the same supply chain weaknesses TeamPCP exploited remain active across package ecosystems.

TeamPCP’s History May Stretch Back to 2020

Attribution surrounding TeamPCP is also evolving.

Oligo Security reported in August that it had identified evidence connecting TeamPCP to activity previously attributed to TA-NATALSTATUS, with infrastructure and operational overlaps extending back to 2020. The researchers identified similarities in domains, malware deployment methods, staging techniques and backend infrastructure.

Oligo cautioned that the evidence does not establish with absolute certainty whether this represents a rebrand, overlapping operators or collaboration between historically related actors.

That caveat matters.

Threat actor attribution is rarely as simple as matching one malware sample to one criminal organization. Cybercrime groups frequently share infrastructure, exchange malware, sell access, recruit from overlapping communities and reuse aliases.

The result is often an ecosystem rather than a conventional organization.

Shai-Hulud Made the Supply Chain Problem Worse

TeamPCP is also closely associated with the Shai-Hulud supply chain attacks, including a worm framework that was later published openly.

The group’s model was particularly dangerous because stolen credentials could be used not just to steal information but to propagate the compromise.

The concept resembles a digital chain reaction:

Compromise developer → steal token → publish malicious package → compromise developer → steal token → publish another malicious package.

That makes package popularity itself a potential weapon.

The more widely used a package is, the greater the number of downstream systems that can potentially be reached.

The supplied reporting notes that TeamPCP later published the source code for a Shai-Hulud worm framework and even promoted a competition encouraging participants to conduct supply chain operations using the code.

That development is significant because it changes the threat from a single actor’s capability into a reusable attack methodology.

Once the tooling is available, other threat actors do not need to reproduce the entire research and development process.

Why AI Infrastructure Is Becoming an Especially Attractive Target

The LiteLLM compromise also highlights a new dimension of software supply chain security: AI infrastructure.

AI gateways increasingly sit between applications and multiple model providers. That means one service may legitimately hold credentials for several external AI platforms.

A compromised AI gateway can therefore become a concentrated credential target.

CloudSEK’s post-incident analysis specifically identified LLM API keys, cloud credentials, Kubernetes secrets, SSH keys and gateway configuration among the information potentially exposed by the campaign.

This creates a security problem that is easy to underestimate.

An organization might rotate an individual application password after an incident while overlooking the AI gateway that holds credentials for several providers.

The correct question after an AI supply chain compromise is therefore not simply:

“Was the vulnerable package installed?”

It is:

“What credentials, identities, workloads and downstream services could the compromised build environment access?”

What Organizations Should Do Now

Organizations that used affected TeamPCP-related software or believe their CI/CD environments may have been exposed should treat potentially stolen credentials as compromised until proven otherwise.

The FBI has advised affected organizations to treat exfiltrated data and credentials as a persistent risk because threat actors may weaponize stolen material long after the initial intrusion. The recommended response includes rotating CI/CD secrets, publishing tokens and cloud credentials that were accessible during the exposure windows.

1. Rotate CI/CD credentials

Immediately identify credentials available to affected runners, including:

• GitHub tokens
• GitLab tokens
• Azure DevOps credentials
• Jenkins credentials
• Bitbucket tokens
• CircleCI credentials
• npm publishing tokens
• PyPI publishing credentials
• Docker registry credentials
• Cloud access keys
• Kubernetes service-account tokens
• SSH keys
• AI provider API keys

Rotation should mean invalidation and replacement, not simply changing a password somewhere else.

2. Audit CI runners

Look for unexpected processes, files, outbound connections, modified workflow files and newly created repositories.

Pay particular attention to ephemeral runners that may have been considered disposable.

A compromised ephemeral runner can still leak credentials before it disappears.

3. Search for suspicious TeamPCP artifacts

The FBI advisory specifically recommends organizations search for repository names including:

docs-tpcp

and

tpcp-docs

These names are useful hunting indicators because attackers were observed creating repositories using stolen GitHub credentials.

4. Pin GitHub Actions to immutable commits

Do not rely solely on floating tags such as:

@main

or:

@v1

where security-sensitive workflows are concerned.

GitHub has separately recommended pinning GitHub Actions to verified commit SHA hashes as part of defending against supply chain attacks.

The principle is simple: a tag can move; a commit hash identifies a specific piece of code.

5. Pin dependencies and verify provenance

Security-critical build dependencies should be pinned to known-good versions and, where possible, verified through checksums, signatures or trusted provenance mechanisms.

A version number alone does not establish that the artifact currently associated with that version is trustworthy.

6. Reduce CI/CD privileges

A vulnerability scanner should not automatically have unrestricted access to every secret in the build environment.

Organizations should use:

• Short-lived credentials
• Workload identity
• Least-privilege tokens
• Environment-specific secrets
• Isolated runners
• Protected environments
• Separate publishing credentials
• Approval gates for production releases

The objective is to ensure that compromising one build component does not automatically compromise the entire software delivery system.

7. Monitor package publication events

Unexpected package releases, newly created repositories, changes to workflow files and modifications to release tags should generate alerts.

This is particularly important for organizations maintaining public packages.

An attacker who steals a publishing token may not need access to the underlying development workstation.

They only need the ability to publish.

GitHub and Package Ecosystems Are Already Responding

The TeamPCP campaign has also contributed to changes in software supply chain defenses.

GitHub introduced a default three-day cooldown for Dependabot version updates in July 2026. Dependabot now waits until a newly released version has been available on its registry for at least three days before opening a version-update pull request. Security updates remain unaffected by the cooldown.

The logic is straightforward.

Attackers benefit from speed.

If a malicious package is published and automated dependency tooling immediately proposes or consumes it, the attacker gets a window in which the poisoned release can propagate before researchers or maintainers detect it.

A delay creates an opportunity for the ecosystem to identify the malicious release.

GitHub has also introduced broader malware alerting through Dependabot by incorporating advisories from the OpenSSF malicious-packages project across ecosystems including npm and PyPI.

These changes demonstrate a larger shift in supply chain security: speed is no longer always an advantage.

For security-sensitive dependency updates, a controlled delay can reduce risk.

The Most Important Lesson From TeamPCP

The biggest lesson from TeamPCP is not that developers should stop using open-source software.

That would be neither realistic nor useful.

The lesson is that organizations need to understand the trust relationships surrounding their software.

An open-source package may have access to:

• Source code
• Build runners
• Cloud credentials
• Package registries
• Signing keys
• Kubernetes environments
• AI provider APIs
• Production deployment systems

Once those relationships are mapped, the security question changes.

Instead of asking:

“Is this package safe?”

security teams need to ask:

“What happens if this package becomes malicious inside our build environment?”

That is a much harder question, but it is the question that TeamPCP demonstrated organizations must answer.

A Supply Chain Attack Is Also an Identity Attack

The TeamPCP campaign shows that modern software supply chain attacks are increasingly attacks against identities and credentials, not just software.

The malware was valuable because it could obtain tokens.

Those tokens were valuable because they represented trusted identities.

And those identities were valuable because they could publish software, modify repositories, access cloud infrastructure or reach additional development environments.

In that sense, the ultimate target was not Trivy, KICS, LiteLLM or any individual package.

It was the trust attached to the software development process.

Once attackers obtain that trust, they can use legitimate mechanisms to perform malicious actions.

What Happens Next for the TeamPCP Investigation?

The arrests in Australia are unlikely to mark the end of the TeamPCP investigation.

Authorities have already indicated that the investigation remains active and that further arrests or charges have not been ruled out.

The forensic examination of devices seized in Western Australia could provide investigators with additional evidence about infrastructure, cryptocurrency transactions, stolen credentials, communications and other participants.

The international nature of the campaign also means evidence and victims are spread across multiple jurisdictions.

For defenders, however, the most important issue is not the criminal case.

It is the possibility that credentials stolen months ago remain useful.

A malicious package can disappear from a registry within minutes. The credentials it harvested can survive for months.

That is why removing a malicious package is only the beginning of remediation.

FAQ: TeamPCP Supply Chain Attack

Bottom Line

The TeamPCP arrests are important because they connect a highly consequential software supply chain campaign to an active criminal investigation in Australia. But the larger story is the attack model itself.

TeamPCP demonstrated how compromising one trusted developer tool can create a chain reaction across the software ecosystem.

Trivy provided access to credentials. Those credentials enabled another compromise. The next compromise produced additional publishing credentials. LiteLLM then became another distribution point for credential-stealing malware.

The attackers did not have to break into every organization.

They attacked the systems that organizations already trusted.

That is what makes software supply chain attacks so dangerous.

For security teams, the priority should be clear: treat CI/CD systems as production infrastructure, minimize the credentials available to build tools, pin security-sensitive dependencies, verify software provenance, monitor publishing activity and assume that any secret exposed inside a compromised build environment may remain dangerous long after the malicious package has been removed.

The TeamPCP investigation may eventually answer who was responsible for the campaign and how far the criminal network extended.

For defenders, the more immediate question is harder and more important:

If one trusted dependency inside your build pipeline turned malicious tomorrow, how much of your organization could it reach?

That is the question modern software supply chain security must be designed to answer.