A security researcher just uncovered something unsettling: attackers turning GitHub‘s own automation tools into a sprawling botnet aimed squarely at web hosting infrastructure, with cPanel and WHM servers as the primary target.
Researchers at Socket first spotted the campaign after finding malicious development versions hidden across ten Packagist PHP packages tied to a legitimate developer whose GitHub account attackers had compromised. The packages themselves weren’t the actual weapon. They contained ordinary reference data and lookup functions, nothing that would trigger malware on install. The real danger sat somewhere less obvious: hundreds of GitHub Actions workflow files the attacker buried in each repository, ready to activate under the right conditions.
Here’s the part that makes this campaign genuinely clever. Simply installing the compromised packages through Composer wouldn’t trigger anything, since GitHub ignores nested workflow files buried inside a dependency’s vendor directory. The attack only springs to life when someone pushes to the compromised repository directly or manually triggers the workflows. At that point, GitHub spins up its own disposable Ubuntu-based runners and hands them straight over to attacker-controlled code, essentially turning GitHub’s own infrastructure into free attack compute.
Once active, those runners detect their processor architecture and pull down a matching payload from an attacker-controlled server. From there, the payload runs an internet-scale scanner built to exploit a known vulnerability in cPanel and WHM deployments, while simultaneously harvesting anything valuable it can find: AWS credentials, GitHub and GitLab tokens, API keys for services like OpenAI and Stripe, database logins, and SSH data. The workflows stream all of it back to the attacker in real time through a heartbeat system that reports in every 30 seconds, letting whoever’s running this monitor thousands of compromised runners simultaneously.
The scale here is what’s genuinely alarming. Searching GitHub’s codebase for unique identifiers tied to this campaign’s command-and-control infrastructure turned up somewhere between 15,000 and 16,000 matching workflow files scattered across unrelated repositories, far beyond the original compromised developer account. That doesn’t necessarily mean tens of thousands of confirmed victims, since forks and cloned repositories inflate the count, but it does confirm this extends well past one isolated incident.
GitHub has since suspended the compromised developer account, cutting off one entry point. Given the surviving forks, mirrors, and still-active infrastructure behind it, researchers are treating this as an ongoing threat rather than a closed case.
