GitHub Actions Runners Abused to Attack cPanel and WHM Servers
Attackers are abusing GitHub Actions runners as distributed infrastructure to exploit cPanel and WHM servers and steal cloud credentials, Socket says.
Attackers are turning GitHub Actions into a free, distributed attack platform. According to research published by Socket around July 23, 2026, and follow-up reporting from The Hacker News and Cybersecurity News, a large-scale campaign is abusing GitHub Actions runners to reach out to cPanel and WHM servers, attempt exploitation, and steal cloud credentials. The runners do the work, so the traffic originates from GitHub's own hosted infrastructure rather than from servers the attacker had to rent or compromise. That matters because CI/CD compute is trusted, ephemeral, and cheap to spin up many times in parallel. It is another case of software supply chain infrastructure being pointed at the people who depend on it.
What happened
Socket's research team documented a campaign that weaponizes GitHub Actions, the CI/CD automation built into GitHub, to run offensive tooling at scale. According to the three reports, the attackers use GitHub-hosted runners as distributed infrastructure to contact cPanel and WHM endpoints, attempt to break in, and exfiltrate credentials, including cloud provider keys found on the targeted hosts. Socket describes the activity as large-scale and distributed. The Hacker News framed it as attackers weaponizing GitHub Actions runners against cPanel and WHM. Cybersecurity News emphasized the theft of cloud credentials as the end goal.
The exact number of abused repositories and runner jobs, the specific exploitation techniques, and the full list of indicators are in Socket's writeup. We could not independently verify those granular details, so treat counts and specific payloads as claims from the primary research until you confirm them against the source. What all three sources agree on is the core pattern: GitHub Actions is the delivery mechanism, and cPanel and WHM servers are the targets.
Why GitHub Actions is an attractive attack platform
GitHub Actions runs jobs on ephemeral virtual machines that GitHub provisions on demand. For public repositories, that compute is free within generous limits, and jobs can be fanned out across a matrix of parallel runners. An attacker who scripts a scan or an exploit into a workflow file gets a fleet of short-lived machines at no cost and with almost no setup.
The network position is the part defenders underestimate. GitHub-hosted runners egress from Microsoft Azure address ranges that many organizations already allowlist or treat as low risk. Traffic from those ranges is less likely to trip IP reputation filters than traffic from a random VPS or a residential proxy. The runners are also short-lived, which frustrates attribution and blocklisting. Spin up, attack, tear down, repeat.
There is no persistent server to seize and no botnet to maintain. That combination, free parallel compute plus reputable source addresses plus disposability, is why abuse of CI/CD runners keeps showing up in offensive campaigns.
Who is affected
The direct targets are cPanel and WHM servers. cPanel is the web hosting control panel used by shared hosts, resellers, and many small and midsize businesses. WHM (WebHost Manager) is its administrative layer for provisioning and managing accounts. cPanel typically listens on TCP 2083 over TLS and 2082 in plaintext, while WHM listens on 2087 over TLS and 2086 in plaintext. Any credentials stored on those machines are exposed if the server is taken, and cloud API keys are called out by Cybersecurity News as a specific prize.
GitHub and its users are affected indirectly. The platform is the abused resource, and organizations with permissive Actions settings can have their runners pulled into this kind of activity through forks or malicious workflows. If you operate hosting infrastructure or run GitHub Actions with loose controls, you are in scope. This is not a compromise of a specific npm, PyPI, or other package, so there is no single malicious version number to pin down.
How the GitHub Actions abuse works
At a high level the mechanics are simple, which is what makes them effective. A workflow file placed in a repository under .github/workflows/ runs whatever the attacker specifies on a GitHub-hosted runner. Triggers such as push, schedule, and pull requests from forks can start those jobs, and a matrix strategy multiplies one job into many concurrent runners.
In this campaign, according to the reporting, those runners execute tooling that reaches out to cPanel and WHM login endpoints, attempts exploitation or credential attacks, and then collects and exfiltrates anything useful, with cloud credentials named as a goal. Because the work is spread across many ephemeral runners on trusted address space, the scanning looks distributed and blends into normal cloud traffic. The attacker collects the loot centrally while GitHub absorbs the compute and the source IPs.
How to check if you are affected
Start with your cPanel and WHM logs and look for authentication activity from cloud and CI address ranges. GitHub publishes the current Actions egress ranges through its meta API, so you can pull them and compare against your access logs.
# Current GitHub Actions egress ranges
curl -s https://api.github.com/meta | jq -r '.actions[]'
# Recent cPanel and WHM login attempts
tail -n 200 /usr/local/cpanel/logs/login_log
# WHM/cPanel access log, filter for login activity
grep -Ei 'login|failed|POST' /usr/local/cpanel/logs/access_log | tail -n 200
If cPHulk brute force protection is enabled, review its history for spikes of failed logins and for source addresses that fall inside the GitHub Actions ranges you pulled above.
# Review cPHulk brute-force history (WHM API)
whmapi1 get_cphulk_login_history | head -n 100
GitHub organization owners should check who is running what. Review recent workflow runs for unfamiliar repositories, look for sudden spikes in Actions minutes or billing, and pay attention to workflow runs triggered by outside contributors through forks.
# List recent workflow runs in a repo
gh run list --limit 50
# Inspect a suspicious run
gh run view <run-id> --log
Remediation
For cPanel and WHM operators, tighten access to the control panel ports and rotate anything that could have been taken. Enable cPHulk, require two-factor authentication for cPanel and WHM logins, and restrict the WHM and cPanel ports to known administrative addresses at the firewall. Below is an example of allowing one trusted address to reach WHM on 2087 and blocking the rest.
# Example: restrict WHM (2087) to a trusted admin IP with firewalld
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="2087" protocol="tcp" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="2087" protocol="tcp" drop'
firewall-cmd --reload
# Enable cPHulk brute-force protection
whmapi1 enable_cphulk
If any cloud credentials were stored on an affected server, rotate them now and assume they are burned. That means AWS, GCP, or Azure keys, API tokens, database passwords, and any SSH keys present on the host. Prefer SSH key authentication over passwords and keep cPanel and WHM on the current release.
For GitHub organization owners, lock down Actions so your runners cannot be conscripted. In Settings, Actions, General, set fork pull request workflows to require approval for all outside contributors, restrict allowed actions to a verified list, and disable Actions entirely on repositories that do not use them. If you see abuse coming from your own account, treat it as a potential credential or token compromise and rotate personal access tokens and Actions secrets.
FAQ
Is this a cPanel vulnerability or a GitHub problem?
Based on the current reporting, it is primarily abuse of GitHub Actions as attack infrastructure, not a single new cPanel or WHM vulnerability. The attackers use GitHub-hosted runners to attack cPanel and WHM servers over their normal login ports. Weak or reused credentials, missing two-factor authentication, and exposed control panel ports are what let those attacks succeed. Both platform hardening on GitHub and server hardening on cPanel and WHM are relevant.
How do I know if my cPanel or WHM server was hit by this campaign?
Pull the current GitHub Actions egress ranges from https://api.github.com/meta and compare them against the source addresses in your cPanel login log and WHM access log. A burst of authentication attempts from those ranges, especially from many addresses in a short window, is a strong signal. Check cPHulk history for the same pattern, and review recent successful logins and any new API tokens or cron jobs on the server.
Can I block GitHub Actions IP ranges from reaching my cPanel server?
You can, and for most hosting environments there is no legitimate reason for GitHub Actions runners to log into your cPanel or WHM. Better still, restrict those ports to a small allowlist of known administrative addresses rather than trying to enumerate and block every abusive range. Allowlisting fails closed, while blocklisting the published ranges only covers what is published today.
What should GitHub organization owners do to stop their runners being abused?
Require approval for workflows triggered by forks from outside contributors, restrict the actions that are allowed to run, and disable Actions on repositories that do not need them. Watch for unusual spikes in Actions minutes, which often reveal abuse before anything else does. If the activity traces back to your own tokens or secrets, rotate them and audit who has write access.