Attackers Weaponize GitHub Actions Against cPanel Hosts

Ten malicious Packagist packages, published under the account of a legitimate PHP developer across July 12 and 13, 2026, turned a set of compromised GitHub repositories into distributed attack infrastructure — pointed at cPanel and WebHost Manager (WHM) hosting control panels. The Hacker News reported the research on July 23.

The packages span 10 entries associated with “dinushchathurya,” a developer with an established presence in the PHP and DevOps ecosystem. The disclosure doesn’t establish whether that account was compromised or used as cover; what researchers found is a set of malicious development-channel releases distributed under that identity in the July 12–13 window.

How the runner environment got turned outward

What distinguishes this from a standard malicious-package drop is what happened after installation. According to the research, the compromised repositories were leveraged as attack infrastructure proper — the GitHub Actions runner environment, which exists to build and test software, was used to direct attacks outward against cPanel and WHM targets.

cPanel and WHM are the dominant management interfaces for shared Linux web hosting. WHM root-level access gives an attacker control over every site under that host — the same credential that manages one customer account often touches dozens more. That blast radius is why hosting control panels have been a recurring target across multiple campaigns over multiple years.

The use of the runner environment as the outbound attack layer is the variation worth tracking. CI/CD infrastructure has appeared as a pivot point in a number of recent campaigns — the AsyncAPI npm compromise that shipped the Miasma multi-C2 loader earlier this month documents a comparable pattern, where pipeline compromise rather than token theft was the entry point. The target here is cPanel/WHM rather than internal secrets, but the mechanism — build runner with network egress, turned outward — is the same setup.

A build runner with cached credentials and open network egress is lateral movement opportunity. The malicious package is just what pulls the trigger.

What to check

If your team manages PHP or Composer-based projects with dev-dependency resolution, audit composer.json for packages in the dinushchathurya namespace or unexpected dev-channel updates landing between July 12 and 13. Lockfile discrepancies against expected state are the signal; composer install workflows that run without a committed lockfile are the specific exposure.

For cPanel and WHM administrators: access and API authentication logs from that window are worth reviewing for anomalous entries.

The Hacker News write-up carries indicators of compromise and the full campaign breakdown. For the broader pattern of package-registry attacks using developer impersonation, see also the fake payment-processor SDK campaign and the jscrambler preinstall-hook incident from earlier this month.

The same attack keeps working because the same assumptions keep holding. Supply-chain hardening is less about any single tool and more about auditing what you’ve decided to trust by default.