Hijacked GitHub Repos Turned Into Attack Machines Hunting cPanel Servers

Key points

• Attackers poisoned 10 PHP software packages tied to a legitimate developer, dinushchathurya, on the Packagist registry between 12 and 13 July.
• The malicious code turned GitHub's automation service into a distributed scanning network aimed at cPanel and WebHost Manager (WHM) servers, the tools most web hosts use to run customer websites.
• Any developer who pulled in one of the dev versions of these packages risked handing over their GitHub automation to the attackers.
• The campaign shows how the software supply chain, meaning the chain of open-source code that ends up inside real products, can be quietly weaponised.
• Removing the packages does not undo damage on servers that were already probed or breached.

Someone has been quietly turning GitHub into a hunting rig.

Researchers have pulled apart a campaign that hijacked open-source software packages and used them to attack the machines that run huge chunks of the web. The target: cPanel and WebHost Manager, better known as WHM. These are the dashboards your web hosting company almost certainly uses to create websites, mailboxes and databases for its customers. Break in there, and you can reach thousands of sites at once.

The attack, first reported by The Hacker News, worked through Packagist, the main directory where PHP developers publish and download reusable code. Between 12 and 13 July, ten packages linked to a real and well-known PHP developer, dinushchathurya, were pushed out in booby-trapped "development" versions. Dev versions are the bleeding-edge builds people grab when they want the newest features. They are also the ones most likely to slip past review.

How did the hackers actually pull this off?

They turned other people's GitHub accounts into free attack servers. When a developer installed one of the poisoned packages, the code reached into that developer's GitHub Actions, which is GitHub's built-in system for running automated jobs like tests and deployments. The attackers then used those runners to scan the wider internet for cPanel and WHM logins to attack.

Think of it this way. Instead of renting servers to launch attacks, the criminals borrowed the computing power of every developer who trusted the wrong package. That makes the traffic look like it is coming from thousands of legitimate GitHub jobs, not one obvious bad guy.

It is a neat trick, and a nasty one.

What was targeted?

cPanel and WHM. If you have ever logged into a web host to set up a WordPress site or a business email address, you have almost certainly touched cPanel. WHM is the higher-level version that hosting companies themselves use to manage all their customers on one server. A single WHM break-in can expose every website on that box.

Should ordinary website owners be worried?

Maybe, but not in a panic way. If your website runs on shared hosting, the risk sits with your hosting provider, not with you personally. Ask them two plain questions: is our cPanel or WHM protected by two-factor authentication, and are admin logins restricted by IP address? Honestly, two-factor login on the hosting panel would blunt most of what this campaign is trying to do. It should have been switched on years ago.

If you are a developer, check whether any of your projects pulled in dev-tagged packages from that author over the summer. If they did, rotate your GitHub tokens and review recent Actions runs for jobs you did not start.

Why this matters beyond one campaign

Supply-chain attacks used to mean stealing secrets from a developer's laptop. Now they mean quietly renting out that developer's cloud automation to attack somebody else. The victim and the weapon are two different people, and neither of them knows it is happening. Expect more of this shape, not less.