TeamPCP Hackers Arrested After Supply-Chain Attacks Hit the Open-Source Ecosystem

• The Mess: Australian authorities have arrested and charged two people allegedly linked to TeamPCP, a cybercrime group associated with a series of attacks against open-source projects and developer infrastructure. The operation has been connected to compromises involving projects and services such as Trivy, LiteLLM, Telnyx, SAP and TanStack, potentially affecting more than 1,000 organizations.

This story is different from a normal vulnerability.

There isn’t one CVE to patch.

There isn’t one server to disconnect.

The problem is the software supply chain.

Developers install packages.

CI/CD pipelines pull dependencies.

Containers download images.

Applications call APIs.

And somewhere in that chain, a malicious modification can travel much further than the original compromised project.

That’s exactly why TeamPCP has attracted so much attention.

The Attackers Didn’t Need to Hack Every Victim

This is the fundamental advantage of a supply-chain attack.

Imagine an attacker wants to compromise 1,000 companies.

The traditional approach is:

attack company #1 → attack company #2 → attack company #3 → repeat.

That’s slow.

A supply-chain attack changes the equation:

compromise software used by 1,000 companies → let the software distribute the attack.

One successful compromise can therefore create a huge downstream blast radius.

That’s why open-source repositories have become such attractive targets.

Trivy Was One of the Important Targets

One of the incidents associated with TeamPCP involved Trivy, a popular open-source vulnerability scanner.

The compromise of a developer’s credentials allowed attackers to manipulate the project’s release process and distribute malicious code through what appeared to be legitimate software.

That’s the nightmare scenario for developers.

You don’t download something from an obviously malicious website.

You run:

trivy

because it’s a trusted security tool.

The package appears legitimate.

The repository is legitimate.

The project is legitimate.

And yet the software can still contain malicious code.

This is exactly what makes supply-chain compromises so difficult to detect.

LiteLLM Was Also Targeted

Another incident involved LiteLLM, an open-source framework used to interact with multiple large-language-model APIs.

This is particularly interesting because it connects two of today’s biggest attack surfaces:

software supply chain + AI infrastructure.

A developer using LiteLLM may not even realize that a compromise of the package could potentially reach environments containing:

• API keys;
• cloud credentials;
• model-provider credentials;
• internal applications;
• CI/CD secrets;
• proprietary source code.

An attacker doesn’t necessarily need to attack an AI company directly.

Compromising a component used by AI applications can provide another route.

More Than Just Open Source

The incidents associated with TeamPCP weren’t limited to small GitHub projects.

Reports linked the group to attacks involving Telnyx, SAP and TanStack, demonstrating how broadly the campaign touched developer and enterprise infrastructure.

That’s what makes this story more significant than another malicious-package incident.

The attackers were apparently looking for high-value points in the software ecosystem.

Compromise the right developer.

Compromise the right repository.

Compromise the right package.

And suddenly the victim list grows.

Now Two Suspects Have Been Arrested

Australian authorities have arrested two people allegedly associated with the operation.

The arrests are significant because supply-chain campaigns can be extremely difficult to attribute.

Attackers can use:

• stolen developer accounts;
• compromised servers;
• temporary infrastructure;
• anonymous cryptocurrency wallets;
• fake identities;
• legitimate cloud services.

By the time investigators discover the malicious package, the infrastructure used to publish it may already be gone.

An arrest therefore provides investigators with a completely different opportunity.

Devices.

Accounts.

Credentials.

Chat histories.

Cryptocurrency transactions.

Infrastructure records.

Potentially much more evidence connecting individual operators to the attacks.

Of course, an arrest and a charge are not a conviction.

The allegations still have to be tested through the legal process.

The Open-Source Security Problem Isn’t Going Away

This is the bigger story.

Modern software is effectively built from thousands of dependencies.

A typical application may contain:

your code → framework → libraries → packages → transitive dependencies → build tools → container images → CI/CD actions.

You may know the first few components.

You probably don’t manually inspect every dependency underneath them.

That’s the problem.

An attacker doesn’t necessarily have to compromise your company.

They can compromise something your company trusts.

And that trust relationship is the attack surface.

Developers Need to Treat Dependencies Like Production Infrastructure

There are several practical lessons here.

First:

pin dependency versions.

Don’t blindly pull whatever the latest package happens to be.

Second:

verify package integrity.

Use checksums, signatures and trusted registries where available.

Third:

protect developer accounts.

A stolen maintainer account can be more valuable than an exposed server.

Use phishing-resistant MFA wherever possible.

Fourth:

limit CI/CD permissions.

A build pipeline should not automatically have unrestricted access to production.

And fifth:

monitor unexpected changes.

A tiny change to a release package can have enormous consequences.

The AI Connection Makes This Even More Interesting

There’s another reason I would keep TeamPCP on our radar.

Developers are increasingly using AI coding assistants and autonomous agents.

That means AI-generated code is becoming another layer in the dependency chain.

A future attack doesn’t necessarily have to compromise a package directly.

It could compromise:

developer → AI agent → repository → CI/CD → production.

And we’ve already seen today’s other story showing attackers using Cursor as part of real-world intrusions.

Put the two trends together and the security problem becomes obvious.

The modern developer environment is becoming increasingly automated.

That creates enormous productivity gains.

It also creates enormous opportunities for attackers.

Bugstoday Opinion

This is one of those stories where the arrest is almost less interesting than the underlying attack model.

The important question isn’t:

“Who are TeamPCP?”

It’s:

“How many organizations can one compromised developer dependency reach?”

That’s the fundamental weakness of the modern software ecosystem.

We trust code because somebody else already trusted it.

We install packages because thousands of developers use them.

We pull containers because they’re hosted in trusted registries.

We run GitHub Actions because they’re part of the normal development workflow.

And attackers know this.

That’s why software supply-chain attacks are becoming so attractive.

You don’t have to break through the front door of every company.

Sometimes you compromise the thing everyone inside the building already trusts.

Bugstoday verdict: the TeamPCP arrests are good news for investigators, but the bigger warning is still the supply chain. One compromised developer account or package can potentially turn trusted software into a delivery mechanism for hundreds or thousands of organizations.