# GitHub's Own Servers Are Running This cPanel Attack Campaign
When researchers at Socket started pulling apart the compromise of a Sri Lankan PHP developer's GitHub account last week, they expected to find the usual: a poisoned package slipping malware onto developers' machines. What they found instead rewrites the threat model for anyone running cPanel or WebHost Manager — and for anyone who thinks they understand what a supply chain attack looks like.
The attacker didn't need your machine. They used GitHub's.
## The Technique Nobody Saw Coming
Between July 12 and 13, 2026, someone with access to the GitHub account of a developer known as dinushchathurya — a legitimate PHP maintainer with packages covering Sri Lankan administrative data, mobile number validators, and SMS utilities — began stuffing those repositories with malicious GitHub Actions workflow files. Ten Packagist packages were hit. Across all of them, 583 workflow YAML files were embedded, each wired to launch the moment a repository received a push or a workflow was manually triggered.
Those workflows spun up GitHub-hosted runners. And those runners — running on GitHub's own compute infrastructure, pulling from GitHub's own IP ranges — downloaded a Linux payload from a C2 server at 43.228.157[.]68, fingerprinted the runner's architecture, and began hunting the internet for cPanel and WHM servers vulnerable to CVE-2026-41940.
CVE-2026-41940 is an authentication bypass in cPanel and WebHost Manager that grants remote attackers elevated control without valid credentials. The payload didn't just poke at the door — it kicked it open, then systematically harvested everything inside: credentials, config files, environment variables, database access details, SSH material, Git tokens, AWS keys, Stripe keys, SendGrid credentials, OpenAI API keys, and more. Results were exfiltrated via HTTP POST back to the attacker.
The PHP packages themselves were irrelevant to the attack chain. They were just the mechanism for getting malicious workflow files accepted into GitHub repositories under a trusted developer's name.
## Who's Actually Burning GitHub's Compute Here
This is where it gets interesting. Socket identified roughly 6,100 workflow files on GitHub carrying a unique DNSHook identifier — f5b0b742-240a-4811-8a5b-b0ba6060685d — suggesting this campaign extends well beyond one compromised developer account. Dozens of GitHub repositories, presumably compromised through similar account takeover methods, are participating in what amounts to a distributed scanning and exploitation fleet.
GitHub is, effectively, running the attacker's botnet. Every runner that spins up to execute these malicious workflows costs GitHub money and compute. cPanel administrators seeing suspicious connection attempts would trace them back to GitHub's legitimate IP ranges. Standard blocklists wouldn't fire. Rate limiting heuristics might not trigger if the scanning load is distributed across many runners running in parallel.
This is the clever part. Traditional malicious package campaigns try to execute on the victim developer's machine. This one entirely bypasses that surface and redirects attack compute toward a different class of victim: the hosting providers and web operators running cPanel and WHM.
## What cPanel at Scale Actually Means
cPanel and WebHost Manager aren't niche software. They run on tens of thousands of shared hosting servers globally. A successful WHM compromise doesn't just expose one site — it exposes every site hosted on that server, every database, every mail account, every customer credential stored there. Hosting providers running unpatched instances of cPanel are looking at a credential harvest that could cascade into hundreds of downstream compromises per server.
The attacker's playbook after initial access is textbook but thorough: SSH keys open doors to other infrastructure; stolen Git tokens enable further repository access; cloud API keys enable lateral movement into AWS, GCP, or Azure; payment processor credentials enable direct monetization. Socket characterizes this as "opportunistic server-side credential theft" — grab everything, sort it later, monetize or weaponize as the market allows.
Defenders running cPanel or WHM need to apply patches for CVE-2026-41940 immediately if they haven't already. Any server that has been externally exposed should be treated as potentially scanned; incident response should focus on checking for signs of auth bypass attempts in cPanel access logs and reviewing whether any hosted credential files have been accessed outside normal patterns.
---
## HackWire Analysis
The 6,100 workflow file count is the number that should keep security teams up at night. One compromised developer account is a contained incident. Six thousand workflow files with a shared identifier is infrastructure — and it's infrastructure that's been growing undetected inside GitHub's own platform.
This attack exposes a gap in how the industry thinks about software supply chain risk. The conventional model is: attacker poisons package → developer installs package → malware runs on developer's machine. This campaign inverts that entirely. The packages were a red herring. The real payload was the workflow files, and the real victims were never the developers installing the packages — they were cPanel admins who had nothing to do with the PHP ecosystem at all.
That's a significant precedent. It means attackers can now use compromised developer accounts and open-source hosting infrastructure as pivot points to attack entirely separate categories of targets. The supply chain becomes a launching pad, not just a delivery mechanism.
For GitHub specifically, this surfaces a real policy question. Workflow files in compromised repositories can silently recruit GitHub's free compute tier into attack operations that have nothing to do with the repository's stated purpose. Detection of this pattern — workflows downloading external payloads and performing network scanning — should be feasible with behavioral analysis, but clearly isn't happening at a speed that stops campaigns like this.
For hosting providers: CVE-2026-41940 should have been emergency patched the day it dropped. The window between public disclosure and weaponization is collapsing. With GitHub Actions available as free distributed compute, attackers can run internet-scale scanning operations within hours of a usable CVE. Patch lag that used to be measured in weeks is now measured in days or less.
— HackWire Editorial
---
## Related Coverage