A supply-chain compromise that reached more than a thousand organisations came in through software nobody bought and nobody chose. A questionnaire was never going to find it. Here is what did.
TL;DR
- Two Western Australian men have been charged over a global software supply-chain attack that hid malicious code inside open-source software, spread on its own, and reached more than 1,000 organisations, harvesting over 500,000 credentials.
- The compromised software was not a vendor anyone contracted with. It was open-source code pulled in through the dependency chain, sitting beneath countless suppliers at once, with no one to send a due-diligence request to.
- There is a second sting: many Australian cyber policies do not clearly cover losses from a third-party software compromise, so the exposure you cannot see may also be the one you are not insured for.
On 26 August 2026, the Australian Federal Police, the FBI and the Western Australia Police Force executed search warrants in Perth and arrested two men over their alleged role in a cybercrime group known as TeamPCP. The next day they appeared in the Perth Magistrates Court. The investigations had been running in parallel since April, after the AFP and FBI received threat assessment reports. The charges include multiple computer offences and money laundering.
The headline is the arrests. The lesson is how the attack worked, and why nothing in a conventional third-party risk programme would have caught it.
What actually happened
TeamPCP did not break into a thousand organisations one at a time. They poisoned the well. The group is alleged to have inserted malicious code into open-source software, the free, shared building blocks that sit inside almost every modern application. Developers around the world then pulled that software into their own projects, as developers do every day, not knowing it now carried a payload. Reporting describes a self-propagating worm that spread from project to project on its own, and thousands of code repositories affected.
From there it did what it was built to do. It infiltrated the organisations that had unknowingly taken the software in, and it harvested sensitive data, including user credentials and authentication material. The published figures are large: more than 1,000 organisations across government, academia and the private sector, over 500,000 credentials stolen, at least 300 gigabytes of data exfiltrated, and hundreds of millions of dollars in global remediation costs.
Read that mechanism again, because it is the whole point. The victims did not choose a risky vendor. They used ordinary, trusted, open-source software, and the risk rode in with it.
This is the nightmare version of supply-chain risk
We have written before about what actually sits beneath a material supplier, and how the software estate of a modern organisation runs down through layer after layer of shared components until, at the bottom, you reach things maintained by a foundation, or one unpaid person, or no one at all. The uncomfortable finding was that the most critical shared components often have no counterparty. There is no company to contract with, no one to send a questionnaire to, no one to hold to a remediation commitment.
TeamPCP is that finding turned from theory into an arrest. The compromised code was not a supplier on anyone’s register. It was a dependency, and a dependency of a dependency, inherited silently through the build. You cannot have done due diligence on it, because you did not know you had it, and there was no one to do the due diligence on.
You did not buy it. You did not choose it. You inherited it, three tiers down, and it was already carrying the payload.
This is why supply-chain risk has quietly become the hardest problem in cyber. The register names the suppliers you know. The real exposure lives underneath them, in code that moves between projects faster than any contract or questionnaire cycle can follow.
The blind spot in your cover
There is a second problem sitting on top of the first, and it is the one that should worry a board. When a compromise arrives through third-party software, it is not always clear that your cyber insurance covers this risk.
Australian cyber policies do not treat this uniformly. Definitions of what counts as your computer system vary from policy to policy. Some exclude outsourced or cloud-based infrastructure. Some carry systemic-risk clauses that limit cover when a single event hits many policyholders at once, which is exactly the shape of a shared open-source compromise. So an organisation can do everything asked of it, be hit through software it did not write and could not see, and then find the claim is contested.
The exposure you cannot see, in other words, may also be the exposure you are not covered for. That is a question worth putting to your broker before an incident, not after.
Why a questionnaire was never going to catch this
Here is the part that matters most for how you run third-party risk. Sit the standard tool next to this attack and watch it fail.
A supplier security questionnaire asks a vendor to describe their own controls. Do you have multi-factor authentication, do you patch, do you run background checks. Even answered perfectly and honestly, it could not have surfaced TeamPCP. The malicious code was not in your supplier’s controls. It was in a component buried in the software your supplier had themselves inherited from somewhere upstream. Your supplier did not know it was there either. So the questionnaire was addressed to a party who could not see the problem, about controls that were not where the problem lived, at a single point in time, while the worm kept spreading.
Every structural weakness of the questionnaire is on display at once. It is self-reported, so it captures what the vendor believes, not what is true. It is point-in-time, so it says nothing about a package that was clean last quarter and poisoned this week. And it stops at the party you can reach, when the danger sat well below them, in code with no owner to question. You cannot questionnaire your way to a poisoned dependency. The instrument is not weak here, it is blind.
What actually found it
Now look at what did surface it, because the contrast is the lesson.
The malicious code was not revealed by anyone filling in a form. It was found by examining the software itself, from the outside, on evidence. Cyber threat assessment work identified the malicious code sitting in the open-source repositories and traced how it behaved, and that analysis is what gave investigators something to pull on. The attribution that followed, linking the code back to two people in Western Australia, was classic investigative tradecraft: digital forensics across accounts and infrastructure, open-source intelligence cross-referencing usernames, payments and online profiles, and the patient work of following domains and connections back to a place and a person.
Both halves of this story, finding the poison and finding the people, were investigation. Neither was attestation. Nobody asked a supplier a question and believed the answer. Someone looked at the evidence, from the outside, and reasoned about what it showed.
The point
This is the through-line, and it is worth saying plainly. Only an investigative process, grounded in intelligence tradecraft and built on evidence rather than self-report, could ever have discovered this. A questionnaire never could have. Not because the people writing questionnaires are careless, but because the method itself cannot see below the party it is sent to, cannot see a package that changed after it was assessed, and cannot see a threat the supplier does not know they are carrying.
The uncomfortable implication for most third-party risk programmes is that the tool at their centre is structurally unable to detect the attack that just put two people in a Perth courtroom. Doing more of it, faster, does not help. What helps is the opposite discipline: understanding what actually sits beneath your suppliers, from outside-in evidence rather than a form, and keeping that picture current as the code underneath you changes.
That is the work BayRisk does. We assess and prove where your supply-chain exposure really sits, on evidence, and keep it current, so a shift three tiers down is something you can see and put in front of a board, not something you read about after the arrests. We do not touch your code and we do not run your defence. We make the risk one you can see and prove. The engineering stays with your teams. The risk stays yours. Keeping it visible and provable becomes ours.
The weakest link, this time, was open source. It usually is. The question is not whether you have asked your suppliers the right questions. It is whether anyone has actually looked.
References
- Australian Federal Police, Two WA men charged following AFP-FBI-WAPF disruption of alleged global cybercrime syndicate, 27 August 2026.
- KrebsOnSecurity, Two Alleged ‘TeamPCP’ Hackers Arrested in Australia, August 2026.
- CyberScoop, Two alleged TeamPCP members arrested and charged after months of software supply-chain chaos, August 2026.
- Help Net Security, Two alleged TeamPCP hackers arrested over global supply chain attacks, 27 August 2026.
- Insurance Business Australia, Perth arrests reveal the supply chain blind spot in Australian cyber cover, August 2026.
Figures are as reported at the time of writing and remain the subject of legal proceedings. No victim organisation is named here by design.