Two Perth Men Arrested: How a Supply Chain Attack Targets Australian Payments

A developer at an unnamed organisation downloaded a routine security scanning tool in early 2026. The library was hosted on a trusted open-source repository, reviewed internally, and deployed without a second thought. Weeks later, that organisation was one of more than 1,000 worldwide to discover that its authentication credentials - including, for some organisations, the stored passwords their finance teams used to access banking portals, ERP systems, and payment platforms - had been quietly exfiltrated.

On 26 August 2026, the Australian Federal Police (AFP), Western Australia Police Force, and the FBI charged two Perth men - Ruben Ian Thomson, 21, and Louis Michael Gaebler, 23 - over their alleged roles in the global cybercrime syndicate known as TeamPCP. The group embedded malicious code into at least seven widely-used open-source packages. More than 500,000 credentials were stolen. At least 300GB of data was exfiltrated. Remediation costs across affected organisations are estimated in the hundreds of millions of dollars.

For Australia’s technology press, this is a developer story. For Australia’s finance teams, it is a direct upstream threat to payments leaving your business right now.

What TeamPCP Did and How It Worked

Supply chain attacks exploit a straightforward trust problem: organisations scrutinise software vendors and contractors, but rarely scrutinise the open-source libraries those vendors and contractors depend on.

TeamPCP identified high-traffic packages in public repositories - libraries downloaded millions of times by developers building everything from security scanners to AI applications. The syndicate then embedded credential-harvesting code into specific versions of those packages. Developers who ran a routine update, or used an automated build pipeline that pulled the latest version, installed the malicious code without realising.

The affected packages confirmed in court filings and subsequent reporting include Trivy (a widely-used container vulnerability scanner), Checkmarx KICS (an infrastructure-as-code security tool), LiteLLM (an AI model routing library popular in enterprise AI builds), the Telnyx Python SDK (a communications platform used in financial messaging workflows), Bitwarden CLI (the command-line interface for the popular password manager), TanStack (a data management library used in web applications), and the Mistral AI SDK.

The scope matters. These are not niche packages. Trivy is deployed in cloud security pipelines across the ASX 200. Bitwarden CLI is used by IT and engineering teams to manage shared credentials - including, in many organisations, the passwords that provide access to payment platforms and banking portals. If your organisation’s engineering environment touched any of these packages between early 2025 and August 2026, credentials may have left the building without triggering a single alert.

Why Bitwarden CLI on the List Changes the Risk Calculus

Most commentary on the TeamPCP arrests has focused on scale: 1,000-plus organisations, 500,000-plus credentials, companies including Mercor and OpenAI among suspected victims, joint coordination across two hemispheres.

For finance teams, the specific inclusion of Bitwarden CLI is the detail worth sitting with.

Bitwarden is one of Australia’s most widely-adopted enterprise password managers. Finance teams use it - or ask their IT teams to use it on their behalf - to store credentials for ATO Business Portal access, banking platforms, accounts payable systems, ERP portals, and supplier payment gateways. When a developer’s build environment installs a compromised version of the Bitwarden CLI, those stored credentials become accessible to anyone running the harvesting code.

To be clear: Bitwarden the product was not breached. The vulnerability was in the CLI - a command-line tool developers use to interact with their Bitwarden vault programmatically in scripts and pipelines. If a developer in your organisation had the TeamPCP-compromised version installed and authenticated to a vault containing finance-team credentials, those credentials may have been exfiltrated.

This is not a theoretical scenario. It is a question of whether your organisation’s developer environment was exposed, and whether anyone has checked. Most finance teams will not know the answer without asking.

The Route from Stolen Credentials to a Diverted Payment

Once a criminal holds valid credentials for your banking platform or accounts payable system, the playbook is well-established.

The most common path runs through email. With access to an employee’s inbox - gained directly via stolen email credentials, or through a payment portal that sends notifications to a compromised email account - an attacker monitors incoming correspondence. They wait for a supplier invoice, a contract renewal, or a scheduled payment run to appear.

At that point they have two options. The first is to intercept the real invoice and replace the bank account details before the finance team sees it. The second is to send a spoofed instruction - from a lookalike domain, or directly from the compromised account - instructing the finance team to update payment details for a future payment.

Business Email Compromise (BEC) cost Australian organisations $152.6 million in 2024, a 66 per cent increase on the year before, according to the Australian Cyber Security Centre (ACSC). Supply chain attacks that steal credentials represent a scalable new way to give BEC operators the access they need to make those attacks land convincingly.

The Australian Financial Crimes Exchange has noted that the gap between credential compromise and payment fraud is often measured in weeks or months. Attackers are patient. They wait for a payment large enough to be worth the risk of detection.

Why Standard Controls Did Not Catch This

The TeamPCP campaign is notable for how thoroughly it bypassed standard organisational defences.

Antivirus and endpoint detection tools are largely ineffective against supply chain attacks because the malicious code arrives as a legitimate package update, often signed by a recognised publisher, and behaves normally in most respects. The credential-harvesting function runs quietly alongside the expected functionality. Unless a security team is specifically scanning for outbound data exfiltration from build pipelines - a practice most are not set up to do - nothing flags.

Internal code review processes are also largely ineffective unless teams specifically audit third-party dependencies for malicious additions. Most organisations reserve that scrutiny for internal code, not the dozens or hundreds of open-source libraries their build tools pull automatically on every pipeline run.

Multi-factor authentication (MFA) reduces but does not eliminate the risk. If stolen credentials include session tokens, or if the attacker uses the credentials before MFA is enforced on a specific system, access remains possible. Banking portals with SMS-based MFA bypass flows are particularly exposed.

The ACSC’s Essential Eight framework requires organisations to control which applications and code can run in their environments. But most organisations have not extended that control into every library in their development pipeline, particularly in engineering teams where dependency updates happen daily and speed is a cultural priority.

The Control That Catches It Regardless of Credential Theft

Here is the structural problem with credential-focused security controls: they attempt to prevent the attacker from getting in. But in a supply chain attack, the attacker may already be inside - and your organisation does not yet know.

The control that holds even after credentials have been compromised is verification at the point of payment.

If your accounts payable process requires that every new or changed bank account is independently verified - against ASIC business registry data, against the account’s true owner, and against the BSB and account number in real time - then a fraudulent payment instruction cannot complete regardless of how convincing the email looks or how legitimate the apparent access appears.

This is what Confirmation of Payee (CoP) is designed to address at the consumer level. The National Payments Platform now checks that the account name matches the account number before a payment processes. But CoP operates at the transaction layer, and it does not verify the business identity or the relationship between the supplier and the payment being made.

For B2B payments - where invoice values can reach hundreds of thousands of dollars and payment instructions arrive by email rather than through a banking app - that gap is the fraud risk. A finance team that receives an instruction to update a supplier’s bank account, sent from what appears to be the supplier’s real email address (because it is - the account is compromised), will not be caught by CoP unless they verify the account independently before processing the change.

This is not a gap in the regulation. It is a gap in the process. And it is the gap that TeamPCP’s downstream buyers - whoever purchased those 500,000 credentials - will look to exploit.

What Australian Finance Teams Should Do This Week

The TeamPCP arrests are a prompt, not a panic. The AFP and FBI have charged two alleged operators. The campaign appears disrupted. But credentials stolen across the past 18 months remain in circulation, and supply chain attacks are not going away - they are becoming the preferred approach for criminal groups that want scale without the effort of targeted phishing.

Three practical steps:

Audit your developer environment exposure. Ask your IT or engineering team whether any of the affected packages - Trivy, Checkmarx KICS, LiteLLM, Telnyx Python SDK, Bitwarden CLI, TanStack, or the Mistral AI SDK - were installed in developer environments that had access to finance credentials or shared password vaults. The AFP has published indicators of compromise through the Australian Cyber Security Centre at http://cyber.gov.au

Rotate credentials for any system with financial access. If there is any possibility that a developer environment had access to credentials for banking portals, accounts payable systems, or ERP platforms, rotate those credentials now. Do not wait for confirmation of a breach - the absence of a breach notification is not the same as the absence of a breach.

Verify bank accounts before payment, every time. This is the control that holds even if everything else has been compromised. A payment instruction that arrives by email - including from a supplier’s real address, if that address is under an attacker’s control - should not trigger a payment until the receiving bank account is independently verified against the entity it is supposed to belong to.

The TeamPCP case is a reminder that the most dangerous payment fraud attacks do not start with a poorly worded phishing email. They start with a trusted library, a routine dependency update, and an organisation that had no reason to suspect anything was wrong. The credential is the entry point. The payment is the exit.

---

ezyshield is on a mission to eliminate payment fraud in Australia. We verify the person, the business, and the bank account before money moves - so payments only ever land with who they’re meant to. Learn more