The Australian Federal Police arrested two men, aged 21 and 23, in the Western Australian cities of Cottesloe and Mandurah on August 26, 2026. Both are alleged members of TeamPCP, a group tied to a year of supply-chain attacks against open-source software and developer platforms. The investigation began in April 2026, after the AFP and FBI received information from cybersecurity firms, and Western Australia Police assisted in the arrests. This analysis draws on reporting from BleepingComputer.
The two face a combined 14 charges covering possessing and supplying data for computer offences and modifying data to facilitate serious crimes. The younger man is additionally charged with dealing in at least $100,000 in criminal proceeds and failing to comply with an order requiring access to electronic data. Maximum penalties run from 3 to 20 years per charge. These are allegations at this stage, and the AFP says further arrests or charges have not been ruled out while it examines the electronic devices seized during the operation.
A supply-chain attack works by compromising something you already trust rather than attacking you directly. TeamPCP allegedly injected malicious code into packages hosted on open-source repositories, which developers then pulled into their own applications and shipped onto systems used by government, academic, and private-sector organisations. Named victims include Trivy, LiteLLM, Telnyx, SAP, and TanStack packages, alongside breaches of the European Commission, Mistral AI, OpenAI, and GitHub. If your development teams consume any of those components, the compromise arrived through a normal build process.
Key Insight: According to the AFP, FBI, and Western Australia Police, the malicious code potentially compromised over a thousand organisations worldwide, enabling theft of half a million credentials and exfiltration of at least 300GB of data.
"The alleged compromise of a small number of trusted software components had a significant global impact. To date, the financial impact includes global remediation costs estimated to be hundreds of millions of dollars."
Australian Federal Police
How TeamPCP Reportedly Compromised Downstream Victims
The source material is specific about outcomes and thin on mechanics. Investigators describe malicious code injected into software hosted on open-source repositories, which developers then pulled into their own applications, but the public reporting does not name the malware families, staging infrastructure, or command-and-control domains involved. Rather than fill that gap with invented indicators, it is worth walking the compromise pattern the case illustrates and where it maps in MITRE ATT&CK.
The entry point is Supply Chain Compromise (T1195), specifically the software dependency and development tools sub-technique. The named affected packages span very different corners of the ecosystem: Trivy (a container and infrastructure scanner), LiteLLM (an LLM API proxy), TanStack (widely used JavaScript libraries), plus components tied to Telnyx and SAP. These are the kinds of packages that sit in build pipelines and CI runners rather than on user desktops, which is why a single tainted release propagates so widely before anyone notices.
That placement explains the credential theft. Build agents and CI/CD runners hold environment variables, registry tokens, cloud keys, and signing secrets in memory or on disk, so code executing during a build reaches Unsecured Credentials (T1552) and Credentials from Password Stores (T1555) without needing privilege escalation or lateral movement. If your build system pulls one of these packages, the malicious code runs with whatever access your pipeline already had.
Stolen authentication secrets then support Valid Accounts (T1078) and Trusted Relationship (T1199). Tokens harvested from one victim authenticate to that victim's own repositories and cloud tenants, and where those tokens belong to a package maintainer or a service provider, they open the door to publishing further poisoned releases downstream. That is the mechanism behind the reported breaches at GitHub, OpenAI, Mistral AI, and the European Commission: access earned in one place gets spent somewhere else, using credentials that look legitimate to every log that records them.
The scale that the AFP, FBI, and Western Australia Police attribute to the activity gives a sense of how much this pattern returns. Malicious code distributed by the group potentially compromised over a thousand organizations worldwide, enabling theft of half a million credentials and exfiltration of at least 300GB of data, with global remediation costs estimated in the hundreds of millions of dollars. Source code was among the stolen material, alongside credentials and authentication secrets.
Structurally, the group behaved less like a formal crew and more like a loose-knit collective of actors who frequent the same hacking forums, Discord servers, and Telegram channels. Police allege the two accused received cryptocurrency payments for their involvement, which points to a pay-for-participation arrangement rather than a single directed campaign. For defenders, that matters because attribution to a named group does not mean the tradecraft is centrally controlled or that the pattern stops with any one arrest.
The public identification work came from operational security failures rather than malware analysis. Separate investigations by Flare and Brian Krebs traced Telegram activity, reused aliases, and reused accounts to real-world identities. Reused handles across forums and messaging platforms are the closest thing to a durable indicator this case produced.
Two things are absent from the reporting and should not be assumed: there is no described defacement or extortion activity attributed to the group, and no ransomware component. The monetization described is credential and data theft plus payment for participation. The seized devices are still under forensic analysis, and further charges have not been ruled out, so the technical picture may expand.
What a Compromised Service Provider Costs the Organisations Downstream
The AFP put global remediation costs from this one set of intrusions in the hundreds of millions of dollars, spread across more than a thousand organisations that never had direct contact with the attackers. That is the defining feature of a supply chain compromise for a board: the spend lands on your side of the ledger even though the breach happened in someone else's build pipeline.
Start with the credentials. Investigators attribute roughly half a million stolen credentials and at least 300GB of exfiltrated data to the malicious code distributed through trusted packages. If any of those credentials belong to your developers, your CI runners, or your cloud tenancy, they work exactly as intended when reused. Nothing about them looks anomalous to a system that was built to accept them.
Your incident response bill in this scenario is not one line item. It typically covers forensic retainer hours, credential and secret rotation across every environment the affected component touched, rebuilding build agents, legal review, and the internal engineering time pulled off delivery work for weeks. Software delivery slows while your teams verify what shipped and when.
Then there is the scoping problem, which is the part executives usually underestimate. When the intrusion arrives inside a dependency you deliberately installed, your logs show authorised software behaving as authorised software. Proving the negative, that a given customer database was not touched, is far harder than confirming a single compromised laptop, and that uncertainty is what drives the cost and duration of the investigation.
Under the Notifiable Data Breaches scheme in the Privacy Act, that uncertainty does not pause your obligations. Once you have reasonable grounds to suspect an eligible data breach, you are required to assess it expeditiously, and if personal information has been accessed or disclosed in a way likely to cause serious harm, you notify affected individuals and the Office of the Australian Information Commissioner. A third party caused the exposure. The obligation still sits with the entity that holds the personal information.
Contractually, the fallout runs in both directions. Your enterprise customers will invoke audit and notification clauses in their agreements with you, often on short timelines, and some will request evidence you cannot produce quickly because the compromise predates your visibility. Meanwhile, your own recovery against the upstream vendor is usually limited by liability caps that bear no relation to the actual remediation spend. Cyber insurers will ask detailed questions about dependency management before renewal.
Reputational consequences tend to be quieter and slower. Prospects ask new questions during procurement. Existing customers add contractual conditions at renewal. Neither shows up as a discrete cost, but both affect the pipeline your revenue forecast depends on.
The most important point for planning purposes is that law enforcement action does not clean up an existing intrusion. Arrests remove operators. They do not revoke stolen API keys, close backdoored accounts, remove implanted code from a package version already pinned in your lockfile, or invalidate session tokens harvested months ago. Credentials taken during this campaign retain their value regardless of who is in custody, and access can be sold or shared with other actors who were never part of the original group.
Treat the arrests as a source of investigative detail about a period you may need to reconstruct, and assume any exposure you had is still live until your own evidence says otherwise.
Detecting and Containing Trusted-Access Abuse
The first action is a credential and token inventory: list every third-party account, CI/CD service principal, package registry token, and remote access path that reaches into your build systems, then rotate anything a dependency could have read from an environment variable. Malicious code inside a package runs with whatever your build agent holds, so the exposure is not limited to the package itself. Treat any secret that has ever been present in a build container as rotation-eligible, including cloud keys, signing keys, and personal access tokens.
While rotation is underway, pull the logs that would show a stolen secret being used somewhere else. The theft happens in your pipeline, but the abuse usually shows up on an authentication surface far away from it.
- Identity provider sign-in logs for service accounts and machine identities authenticating from new ASNs, new user agents, or outside their normal schedule.
- Source control audit logs: personal access token creation, new deploy keys, OAuth app grants, changes to branch protection, and workflow files edited outside a pull request.
- Package registry publish events for your own internal packages, plus token use you did not initiate.
- Cloud control-plane logs for role assumption and API calls made by build-time credentials from addresses that are not your runners.
- VPN, RDP and management-plane sessions attributed to vendor or contractor accounts across the window your dependencies were exposed.
In environments Capstone manages, Adlumin correlates those sign-in events across identity, VPN and cloud sources, so a build token suddenly authenticating from an unfamiliar network is flagged as an identity anomaly rather than sitting unnoticed in a log archive. That matters because stolen machine credentials produce authentications that look procedurally correct. Nothing fails, nothing locks out, and the only signal is context.
Once you have visibility, tighten how third-party access is granted. Require MFA on every vendor and contractor account that touches your systems, and disable accounts that have not authenticated in the last quarter instead of leaving them parked. Move provider access to just-in-time elevation so a standing account is not sitting at domain admin between engagements.
Your build environment deserves the same segmentation you apply to production. Give each pipeline scoped, short-lived credentials rather than a shared long-lived key, pin dependencies by hash in lockfiles, and run installs with lifecycle scripts disabled where your toolchain allows it, for example npm ci --ignore-scripts. Ship all build and registry logs to central storage that the build system itself cannot modify.
Longer term, put the obligations in writing. Contracts with software vendors and managed providers should specify breach notification timelines, log retention, and your right to receive indicators after an incident on their side. Without that clause, you learn about a compromise when a researcher publishes it.
Finally, run a tabletop where the breach starts at a provider. Work through who revokes the tokens, how fast you can rebuild artifacts from a known-good commit, which customers you owe notification, and who signs off on resuming deployments. Firms that have rehearsed that sequence rotate credentials in hours; firms that have not spend the first day deciding who owns the decision.
What the Arrests Change and What They Do Not
The activity attributed to TeamPCP was not run by a structured organisation. Investigators describe a loose-knit collective of people who met on the same hacking forums, Discord servers, and Telegram channels, which means removing two participants does not remove the network they operated in. The AFP has said further arrests and charges have not been ruled out as seized devices are examined, so the case is still open.
What changes for you is small. What does not change is the access model: injecting code into a trusted dependency remains one of the cheapest ways to reach a thousand organisations at once, and the separate investigations published by Flare and Brian Krebs, which tied real identities to reused aliases and accounts, demonstrate that the operators involved were not especially disciplined about tradecraft. Successors with the same approach and better opsec are a reasonable expectation.
The practical takeaway is about scope rather than attribution. Your exposure in an incident like this is defined by what a third party's code and credentials can actually reach once they are inside your perimeter, so it is worth confirming the real reach of every vendor account, integration, and dependency you trust, and confirming that no access remains active from a provider that has already been compromised. Arrests do not close accounts that were opened during someone else's breach.
