Global Cybercrime Infiltrates via Open Source: Two Charged After Malicious Code Spreads Worldwide

Trust in open-source software is under attack.

The Australian Federal Police, the U.S. Federal Bureau of Investigation and the Western Australia Police Force have charged two Western Australian men following an investigation into a cybercrime syndicate accused of creating malicious open-source software and using it to compromise companies and institutions around the world.

This is not simply another hacking case.

The attackers are suspected not of breaking directly through the firewall of a particular company, but of planting malicious code in open-source repositories that developers trusted and reused. That code was then unknowingly used by other developers and spread into systems used by government, academia and private companies.

Investigators estimate that the malicious code potentially compromised more than 1,000 organizations worldwide, enabled the theft of more than 500,000 credentials and led to the exfiltration of at least 300GB of data. The global remediation cost is estimated to reach hundreds of millions of dollars.

The central issue is not only the scale of damage.

The case shows how quickly the impact can spread worldwide when a small number of trusted software components are contaminated. The front line of cybersecurity is no longer limited to servers and network perimeters. The libraries developers download, dependency packages, build pipelines, authentication tokens, API keys and open-source repositories themselves have all become part of the attack surface.

Open source is the foundation of the modern digital economy.

But that same openness and reusability have become one of the most attractive entry points for cybercriminal organizations.

The investigation began in April 2026. The AFP and FBI received information from several cyber threat assessment companies that a criminal syndicate had inserted malicious code into open-source repositories. The AFP and Western Australia Police conducted the investigation in parallel with the FBI, and on August 26, 2026, search warrants were executed at residences in Cottesloe, Hamilton Hill and Mandurah in the Perth area.

Two Western Australian men were arrested: a 21-year-old man from Cottesloe and a 23-year-old man from Mandurah. The AFP charged them with a combined total of 14 offences. The allegations include possessing data with intent to commit a computer offence, unauthorized modification of data with intent to commit a serious offence, and supplying data with intent to commit a computer offence. The 21-year-old was also charged with dealing in proceeds of crime worth more than A$100,000 and failing to comply with a law enforcement order.

Investigators believe the two men were key participants in a cybercriminal organization and received cryptocurrency in exchange for illegal activity. The exact amount remains under investigation.

FBI Cyber Division Assistant Director Brett Leatherman said the men were suspected members of a cybercriminal group known as TeamPCP. The FBI described the arrests as the result of international cooperation against the growing threat of software supply-chain attacks.

The significance of the case lies in the attack method.

Traditional cyberattacks are often understood as direct intrusions into a company or institution by exploiting its vulnerabilities. Supply-chain attacks are different. Attackers do not necessarily attack the final target directly. Instead, they contaminate the software, tools, updates, development packages or partners that the target already trusts.

This method is efficient.

One open-source package can be reused in countless projects. A library installed by one developer can become part of an internal corporate service, and that service can later be included in customer systems or government projects. The attacker plants code in one place, but the damage can spread to hundreds or thousands of organizations.

The AFP-FBI case follows that structure. Police said the infected software was unknowingly used by other developers and then distributed into computer systems across government, academia and the private sector. The malicious software is suspected of infiltrating those organizations and stealing or harvesting sensitive data, including user credentials and authentication materials.

The attacker did not target the weakest point in the system.

It targeted one of the most widely trusted points.

That is what makes software supply-chain attacks so dangerous. Victim organizations do not think they are downloading a malicious file. They are using familiar development tools, installing trusted packages and following existing build procedures. If malicious code is hidden inside that process, security tools may mistake it for normal development activity.

Credential theft is especially damaging in supply-chain attacks.

If cloud access keys, API tokens, certificates, developer accounts or CI/CD secrets are stolen, attackers can gain deeper system access beyond simple data theft. When a development environment is compromised, the organization’s customers, partners and distributed software may also become exposed.

The estimate that more than 500,000 credentials were stolen in this case is serious in itself. Credentials are cash-like assets in the cybercrime economy. They can be sold on dark web markets, used as initial access for ransomware attacks, or become a foothold for further account takeover and lateral movement.

The estimated exfiltration of at least 300GB of data should not be seen merely as a number.

The value of data depends less on volume than on content. If authentication materials, source code, internal documents, customer information, system configuration details or vulnerability data were included, the damage could last for a long time. Companies would need not only to restore servers, but also revoke and reissue stolen credentials, inspect code repositories and deployment pipelines, and check customer systems.

That is why remediation costs can reach hundreds of millions of dollars.

The more organizations affected by a software supply-chain attack, the more recovery costs grow. Each organization must determine which packages it used, which versions were affected, where they were deployed, and which credentials may have been exposed. This process requires not only security teams, but also developers, legal teams, customer support, executives and regulatory response teams.

The problem is that many organizations do not fully understand their own software components.

Modern software often contains more external dependencies than code written directly by internal teams. A single application may depend on dozens or hundreds of open-source packages, and those packages may depend on other packages. Code adopted to accelerate development becomes part of a chain of security risk.

This case again highlights the importance of SBOMs, or software bills of materials.

Companies must know what software components they use. They must be able to track which versions are deployed where. When a warning emerges that a certain package has been contaminated, they must be able to identify the scope of impact within hours.

But SBOMs alone are not enough.

Organizations must also manage the origin of open-source packages, maintainer trust, code change history, release signatures, dependency changes, build environments and developer account security. The entire path from package installation to production deployment must be verified.

Software supply-chain security is no longer a side task for development teams.

It is a core control area of enterprise security.

The case also shows how cybercriminal organizations operate. The AFP described the group as a highly organized syndicate involved in large-scale cybercrime, including data intrusion, identity crime and cryptocurrency-based money laundering. AFP Commander Graeme Marshall said cybercrime groups are becoming increasingly organized and often operate like professional businesses.

That point matters.

Modern cybercrime can no longer be explained as the spontaneous intrusion of an individual hacker. Roles are divided. Malware developers, initial-access brokers, data theft operators, credential sellers, cryptocurrency launderers, extortion specialists and infrastructure operators can all move separately. They buy and sell services inside a criminal ecosystem, split profits and operate across borders.

Open-source supply-chain attacks fit well with this industrialization of cybercrime.

Once attackers distribute a malicious package, they can infiltrate many organizations. Stolen credentials can be sold to other attackers. Exfiltrated data can be used for extortion, fraud or identity theft. Cryptocurrency can be used to receive payment and launder proceeds. Technology and criminal business models combine.

That is why investigations must also cross borders.

This case is an example of international cooperation among the AFP, Western Australia Police and the FBI. The AFP said information from private threat assessment companies was critical to the investigation. This reflects the reality that public agencies alone are not enough to respond to cybercrime.

The first organization to see a threat may be a private security company.

The first organization to discover signs of compromise may be a victim company.

Part of the criminal infrastructure may be overseas.

The suspect may be in another country.

The money may move through cryptocurrency.

Cybercrime response is therefore evolving into a model in which police, intelligence agencies, security companies, platform operators, cloud companies and victim organizations must work together. This is why investigators emphasized early reporting and continuing cooperation.

In the open-source ecosystem, the role of the private sector and community is even larger.

Open-source repository operators, package maintainers, security researchers and developer communities must detect and share suspicious activity. When malicious packages are found, they must be removed quickly, and affected versions and dependencies must be disclosed. Companies must then use that information to determine their internal exposure.

Korean companies and public institutions should not view this as a foreign issue.

Korean organizations also depend heavily on open source. Finance, telecommunications, manufacturing, public services, platforms, gaming and AI services all run on open-source components. A culture of quickly adopting external packages to improve development productivity is now widespread.

But open-source security management often remains weak.

Organizations do not always know exactly which packages they use.

Libraries installed individually by developers may enter production services.

Package update verification processes may be weak.

Secrets in CI/CD environments may be poorly managed.

Developer accounts may lack multi-factor authentication.

Even when open-source vulnerability warnings are issued, impact analysis may be slow.

In this environment, supply-chain attacks can enter quietly and response can be delayed.

The spread of AI development makes the problem even more complex. AI services rely on many external packages, including Python and JavaScript libraries, data-processing tools, model hubs, plugins, agent tools and API wrappers. The culture of rapid experimentation and deployment supports innovation, but it also increases the chance that unverified code will enter internal environments.

In an era when AI agents can generate code and install packages automatically, supply-chain security becomes even harder.

It is no longer enough to manage only the packages humans consciously choose. Organizations must also check libraries recommended by AI tools, automatically generated installation commands, mistyped package names, lookalike packages and malicious dependencies. Open-source repositories accelerate AI development, but they can also become distribution channels for attackers.

That is why the AFP-FBI case matters.

Attackers understand the habits of the developer ecosystem.

They know developers often reuse code quickly.

They know open-source packages are trusted.

They know credentials often remain somewhere in development environments.

They know one package can spread into many organizations.

They hack that trust.

Corporate response must change accordingly.

Firewalls and antivirus tools are not enough. Development pipelines must be treated as a core security target. Package installation policies, dependency scanning, code signing, reproducible builds, secret detection, developer-account MFA, least-privilege access, shorter token lifetimes, repository permission management, anomaly detection and pre-deployment verification must work together.

Most importantly, organizations must prepare on the assumption that incidents will happen.

When it becomes known that an open-source package has been contaminated, an organization must immediately know whether it is affected. It must know which service included the package, which version was deployed, which credentials may have been exposed, which customers must be notified, and what legal reporting obligations apply.

Supply-chain security is not merely a technical issue.

It is an operational capability.

Investigators have said the inquiry is ongoing, and additional arrests or charges have not been ruled out. Large volumes of seized data and electronic devices are undergoing forensic analysis. This means the scope of damage may expand.

In cybercrime investigations, the first announcement is often not the end but the beginning. Seized devices may reveal additional infrastructure, victim organizations, wallet addresses, collaborators, other malicious packages or sales records. One supply-chain attack can also turn out to be connected to ransomware, account takeover or data-sale operations.

Organizations should not treat this case as just another overseas news story.

They should review their packages and dependencies, development environments and credential-management practices. Government, academia and private companies were all reportedly exposed, which means public institutions and research organizations are not exceptions. Academic and research institutions often have limited security budgets and staff, but high open-source dependency. Research data, accounts and cloud resources can be attractive targets.

Open source remains the foundation of digital innovation.

The answer is not to stop using open source.

The answer is to trust open source in a verifiable way.

Open ecosystems provide speed and collaboration, but they also require transparent tracking and responsible use.

This case shows that reality.

The open-source supply chain is not just a collection of free code. It is digital infrastructure on which global companies, governments, universities and public services depend. When that infrastructure is contaminated, the damage does not remain inside one company. It spreads across organizations around the world.

Cybercriminal groups know this.

Now companies and governments must know it too.

The starting point of security is no longer only the entrance to the internal network. It begins with the first line of code a developer imports, the first package installed, and the first dependency added.

That small component can spread to thousands of organizations worldwide.

The age of open source is not over.

But the age of naively trusting open source is ending.