Australian Federal Police (AFP) have charged two men from Western Australia over their alleged role in TeamPCP supply chain hacks. Authorities link the alleged activity to compromises of widely used security and AI-related software components, including the open-source scanners Trivy and Checkmarx KICS, as well as the AI gateway LiteLLM.
The case centers on a pattern investigators say relied on trusted publishing workflows: attackers allegedly stole credentials from legitimate open-source projects and then distributed manipulated releases through the projects’ own channels.
Who is accused, and what charges are filed
According to AFP reporting, Louis Michael Gaebler (23) and Ruben Ian Thomson (21) appeared in Perth Magistrates Court on August 27, 2026, one day after search warrants were executed.
Police carried out searches at properties in Cottesloe, Hamilton Hill, and Mandurah, seizing electronic devices for forensic analysis. Investigators allege that both men were principal participants in the syndicate and that they received payments in cryptocurrency, with the value still being investigated.
Gaebler is charged with a total of 14 offences combined across multiple counts, including offences related to possessing data with intent to commit computer offences, unauthorized modification of data with intent to commit serious offences, supplying data with intent, failing to comply with a court order, and dealing with proceeds of crime above a specified threshold.
Thomson faces fewer counts but still includes charges tied to possessing and supplying data with intent, along with unauthorized modification of data with intent to commit serious offences.
How the alleged TeamPCP supply chain attacks worked
The core allegation is that the campaign moved through legitimate software distribution ecosystems rather than relying on a single directly hacked site. Prosecutors describe a process where stolen publishing access allowed malicious code to be pushed into official release flows.
Investigators say the operation spanned five distribution ecosystems: GitHub Actions, Docker Hub, npm, PyPI, and OpenVSX. Importantly, they allege the compromises were chained so that credentials taken from one target enabled the next stage.
From Trivy to Checkmarx KICS
One portion of the alleged attack path began with the Trivy scanner compromise. The stolen credentials were then reportedly used against Checkmarx KICS days later, resulting in poisoned activity distributed via KICS-related release and automation channels.
The supply chain angle here is that trust in normal publishing and build steps becomes the delivery mechanism. If an attacker can alter what a trusted pipeline installs or publishes, it can turn normal updates into an infection vector.
LiteLLM release pipeline manipulation
The allegations also focus on LiteLLM, an AI gateway that routes requests across multiple large language model (LLM) providers. Investigators allege that LiteLLM’s own build pipeline installed Trivy without pinning it to a verified version.
In the scenario described by authorities, the poisoned scanner then obtained a publishing token associated with the project. That token was allegedly used to push backdoored LiteLLM releases in late March.
Because LiteLLM sits where an organization’s provider keys are consolidated, investigators warn that the impact could extend beyond the initial compromise of any single package or build script.
Scope of impact: credentials, data, and CI/CD pipelines
FBI messaging linked to the campaign emphasizes that exposed assets may remain valuable long after the first intrusion. The FBI advisory stated impacted organizations should treat exfiltrated data and credentials as a persistent risk, noting that affiliated actors are likely to weaponize stolen materials “long after the initial compromise.”
Authorities and third parties reported large-scale exposure figures, though some counts were framed as potential or reconstructed. The AFP said malicious code potentially compromised more than 1,000 organizations globally, enabled theft of more than 500,000 credentials, and led to exfiltration of at least 300 gigabytes of data.
Other researchers published figures associated with the same campaign. For example, CloudSEK reported reconstructed exposure of more than 2,500 organizations and roughly 434,000 CI/CD pipelines. Hudson Rock attributed 118,829 CI runner dumps to 2,488 corporate domains from a 153GB archive of attackers’ exfiltrated data.
These numbers are significant because CI/CD systems and build pipelines often have broad access to secrets. If those secrets are stolen, attackers can potentially move laterally, modify future builds, or sign off malicious changes.
Why defenders should assume “persistent” risk
Beyond the question of whether a single build step was altered, the FBI advisory specifically advises organizations to treat stolen CI/CD and cloud credentials as ongoing threats. The guidance includes rotating secrets and tokens used in continuous integration and continuous delivery systems.
The advisory also calls for publishing tokens and cloud credentials accessible during the relevant exposure windows to be rotated, since an attacker might reuse them long after the compromised package was removed.
It also recommended searching for evidence based on filenames and repository patterns related to the worm framework created by the malware. The FBI advisory mentions repository names such as tpcp-docs and docs-tpcp.
Observed platform patterns and released package disappearance
Multiple reports suggested that exposure was not evenly distributed across developer platforms. StepSecurity said its analysis of a dataset from CloudSEK found GitLab leading among affected platforms, with 1,064 organizations. It was followed by GitHub Actions (618), Azure DevOps (233), Jenkins (105), Bitbucket Pipelines (94), and CircleCI (15).
Authorities also focused on how long malicious releases could remain accessible after removal. The reporting states that two malicious LiteLLM builds no longer appear in PyPI’s release history as of August 27, 2026. However, those packages reportedly still returned HTTP 200 when accessed via direct CDN-linked URLs even five months after removal from the index.
This distinction matters for incident response: removal from a listing does not always mean every cached or direct artifact location disappears simultaneously.
What the case highlights about open-source security
A striking element of the allegations is that the affected software components were open-source and depended on established trust relationships—publishing credentials, automated build steps, and routine package delivery mechanisms.
The AFP stated that none of the filed charges names a specific compromised project. Still, the operational description connects the alleged group to a chain of poisoned releases across common ecosystems.
Investigators also noted that linked infrastructure could be traced back several years by other researchers, and that continuity might reflect rebranding, shared operator behavior, or close collaboration—though certainty about the relationship was not asserted as absolute.
In addition, reporting indicates that the group open-sourced a worm framework used in an earlier campaign and later produced new waves of poisoned packages with similar tooling.
Recommended defensive actions for organizations
While this court case focuses on alleged responsibility, the associated advisories and reporting translate into practical steps for defense teams:
- Rotate secrets used in CI/CD and publishing workflows, including tokens and cloud credentials that were accessible during exposure windows.
- Review for repository and artifact indicators mentioned in advisories, such as repository names associated with the worm’s activity.
- Pin automation to verified versions: for GitHub Actions workflows, prefer pinned commit SHA hashes over floating tags.
- Assume credentials and exfiltrated data may be reused, even if specific releases are later removed.
Taken together, these actions aim to reduce the blast radius of supply chain compromise and to prevent attackers from reactivating access using stolen keys.
Conclusion
The charges filed in Australia add a legal dimension to a broader security lesson: TeamPCP supply chain hacks—as alleged by investigators—show how attackers can leverage trusted build and release pathways to distribute malicious software and harvest secrets at scale.
For organizations relying on open-source tooling and automated pipelines, the key takeaway is clear: treat stolen credentials as a long-term threat, strengthen dependency verification, and harden release workflows so that a compromised credential can’t silently turn into widespread, persistent access.
Source: https://thehackernews.com/2026/08/alleged-teampcp-hackers-charged-in.html
