Australian police arrest two alleged TeamPCP members over open-source supply chain attacks
The arrests follow a self-spreading package worm, and show why install scripts and long-lived tokens are the weak points developers must fix.
The Australian Federal Police have arrested two men from Western Australia, aged 21 and 23, who are alleged to be members of TeamPCP, a cybercrime and data extortion group linked to a long-running series of software supply chain attacks, KrebsOnSecurity reported on 27 August. In its statement the AFP said the suspects belonged to a syndicate that allegedly built malicious open-source software used to steal from thousands of businesses worldwide.
The AFP did not name the men. KrebsOnSecurity, which said it had identified the younger suspect in June and had been in contact with him since, named them as Ruben Ian Thomson, 21, of Cottesloe, and Michael Gaebler, 23. The pair face a combined 14 cybercrime charges. Thomson was refused bail, and both are due to appear in court on 18 September.
According to the report, TeamPCP emerged in late 2025 and is blamed for embedding malicious code in hundreds of open-source tools. Its best-known tooling is a self-propagating worm called Shai-Hulud, which spread through developer credentials and is said to have compromised at least 3,800 code repositories on GitHub. A March 2026 attack on the LiteLLM project harvested credentials from more than 2,500 organisations, with AI infrastructure and developer secrets a recurring target. In May the group published source code for a third iteration of the worm alongside a $1,000 contest.
The article also draws on interviews with a person described as TeamPCP's spokesperson and on research from Charlie Eriksen of Aikido Security, and traces the operational clues that KrebsOnSecurity says likely led investigators to the group's leader.
Why it matters
Arrests are rare in supply chain crime, so the case will be watched for which evidence trails proved decisive. The campaign showed that one compromised maintainer account can cascade through thousands of downstream projects, because the ecosystem trusts published packages by default. Token hardening, install-script controls and publishing provenance are the defences this case is likely to accelerate.
Arrests are rare in supply chain crime, so the case will be watched for which evidence trails proved decisive.
Developer machine or CI runner compromised
A poisoned package is installed; its install-time script runs with the developer's privileges.
Tokens and keys harvested
Registry publishing tokens, cloud keys and API secrets are read from the environment and home directory.
Packages republished
Stolen tokens push modified versions of every package the victim maintains, each carrying the payload.
Next install repeats the cycle
Another maintainer or build pulls the new version, and the worm gains more tokens and more packages.
Credentials monetised
Harvested secrets are used for access, sold, or held over victims for extortion.
What you can learn from this
- A supply chain attack poisons the well rather than the house. Instead of attacking an organisation directly, the adversary compromises a component that thousands of organisations import automatically. Package registries are attractive because a new version is pulled by every build that does not pin an exact version. The attacker writes code once; the victims' own tooling distributes it. The same logic applies to container base images, CI actions and editor extensions, which are all packages by another name.
- Install-time scripts run with your privileges. Many package managers allow a package to execute a script during installation, intended for compiling native code or setting up configuration. That script runs as the developer or the CI runner, with access to environment variables, home directories and any credentials cached there. This is why malicious packages so often do their work at install time, before the code is ever imported. Disabling scripts by default and re-enabling them only for packages that need them is the single change that removes most of this risk.
- Worms turn stolen tokens into new publications. A self-propagating package worm reads publishing tokens from the compromised machine, then uses them to push modified versions of every package that developer maintains. Each new version carries the same payload, so each install by another maintainer repeats the cycle. Propagation speed depends on how many long-lived, broadly scoped tokens are sitting on developer laptops and build servers. The worm does not need a vulnerability in any software; it only needs the trust relationships that already exist between maintainers.
- Credentials are the real product. Cloud keys, registry tokens and API secrets harvested from build environments can be sold, used for extortion, or turned into access to production systems. The reported focus on AI infrastructure credentials reflects where high-value compute and data now sit. Extortion follows because stolen data creates leverage independent of any ransomware. A token that can read a bucket of training data or a key that can launch GPU instances has an obvious resale value.
- Provenance and pinning break the chain at two points. Lockfiles with exact versions and integrity hashes stop a build from silently picking up a new release. Trusted publishing and build attestations let registries verify that a release came from a known source repository and workflow rather than from a token on a laptop. Neither is perfect, but together they remove the two conditions the worm relies on: automatic upgrades and reusable tokens. Short-lived tokens issued per build, rather than stored on disk, close the remaining gap by giving the worm nothing durable to steal.
We teach this
How to use this in practice
- Inventory and expire your publishing tokens. Run
npm token list, check~/.pypircand~/.npmrc, and reviewgh auth status. Revoke anything you cannot explain and recreate what you need with the shortest expiry and narrowest scope offered. Done looks like: no token older than 90 days, and none with publish rights on a machine that does not publish. Write down where each remaining token lives and what it can do, because that list is the blast radius of your next compromised laptop. Repeat for any secrets stored in repository settings. - Turn off install scripts and see what breaks. Add
ignore-scripts=trueto a project's.npmrc, or usepip install --only-binary=:all:for Python, then reinstall from a clean directory. Done looks like: a short list of packages that genuinely need scripts, which you can allow individually, and a default that no longer executes arbitrary code on install. Run your test suite afterwards to confirm the project still builds, and record which script each allowed package needs and why. - Pin and audit one real project. Commit the lockfile if it is not already tracked, install with
npm ciorpip install -r requirements.txt --require-hashes, and then runnpm auditorpip-audit. Done looks like: a build that fails if a dependency changes without a lockfile update, and an audit report with zero unreviewed high-severity findings. Add the audit command to CI so the check runs on every pull request rather than only when someone remembers. - Draw the ingress map. Sketch every path by which third-party code enters your build: registries, container base images, CI actions, editor extensions, and copy-pasted scripts. Mark which of them verify provenance and which trust a bare version string. Done looks like: a one-page diagram with each unverified path circled, which becomes your to-do list for the month. Then pick the one path with the most traffic and least verification and spend an hour closing it, for example by pinning a CI action to a commit hash instead of a tag.
Sources
- Two Alleged 'TeamPCP' Hackers Arrested in Australia — Krebs on Security
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report