A Malware Campaign Is Using GitHub Actions to Hunt Unpatched cPanel Servers

Three months after cPanel shipped an emergency fix for CVE-2026-41940, the critical authentication bypass has found a second delivery system, and this time it runs on GitHub’s own machines. On July 22, the security firm Socket reported that a malware operation has been abusing GitHub Actions, the automation service built into code repositories, to turn its free cloud build machines into a distributed fleet that scans the internet for cPanel and WebHost Manager servers still exposed to the flaw, then tries to break in. The campaign surfaced in the PHP package ecosystem, but the packages were never the weapon. The attacker’s code lived in the automation workflows attached to them.

The novelty here is the infrastructure. Rather than rent servers or assemble a botnet from infected machines, whoever runs this campaign simply executed their scanner on GitHub’s own runners, on Microsoft’s compute and bandwidth, at no cost to themselves. Socket was careful on one point: the developer whose account carried the ten poisoned packages is a victim of the account takeover, not the person behind it. And one caveat belongs up front. Socket’s figures count malicious files, not confirmed break-ins; no one has published how many cPanel servers this particular campaign actually compromised. What is documented is the machinery, and it is pointed squarely at hosting infrastructure.

Key facts

• What Socket reported: on July 22, 2026, a campaign abusing GitHub Actions runners to scan for and exploit CVE-2026-41940 on cPanel and WHM servers
• The delivery: 10 PHP packages on Packagist, under one compromised developer account, each carried between 55 and 62 malicious workflow files, 583 in total, synced July 12 to 13
• The scale marker: roughly 6,100 workflow files across GitHub carried the campaign’s unique identifier, though Socket cautions these are file matches, not confirmed compromised accounts
• What it steals: cloud and AI API keys, code-repository tokens, payment and email-service credentials, database logins and SSH material
• The flaw itself: CVE-2026-41940, a CVSS 9.8 authentication bypass in cPanel and WHM, exploited from February and patched April 28, 2026
• The exposed surface: a Shodan search returns roughly 1.5 million cPanel instances reachable from the internet, the population this scanner sweeps
• Indicators: payload host 43.228.157.68 and a callback domain on dnshook.site; cPanel publishes an IOC detection script for exposed servers

How a Poisoned Package Became a Scanning Fleet

The chain is short and inventive. The attacker gained control of a legitimate PHP developer’s GitHub account and added dozens of malicious workflow files to the developer’s repositories, which double as packages on Packagist, PHP’s main package registry. Between July 12 and 13, Packagist automatically synced the tampered development versions. Each workflow, when it runs, starts a fresh GitHub-hosted Linux machine, checks its processor type, and downloads a matching scanner from a server at 43.228.157.68. The scanner is tuned for its target: it probes the ports cPanel and WHM answer on, attempts the CVE-2026-41940 bypass against anything that responds, and rifles compromised servers for secrets, cloud provider keys, GitHub and GitLab tokens, OpenAI and Google API keys, Stripe and email-service credentials, database logins and SSH material, reporting results back over the same channel.

The poisoned Packagist versions were how the operation came to light, but the exploit never ran from the PHP library code, which Socket found to be benign. It ran inside the GitHub Actions workflows, on GitHub’s cloud runners. Broader searches for the campaign’s other fingerprints returned as many as 15,000 to 16,000 matching files, though Socket frames every one of these counts as file matches rather than confirmed victims. For the many developers who use these packages, the practical risk is narrower still: a routine Composer install does not run the workflow files, which execute only on GitHub’s own infrastructure, not from a project’s vendor directory. The exposure a developer should worry about is the one the original maintainer suffered, an account takeover that let someone plant workflows in their name.

On who is behind it, Socket named no threat actor. The Hacker News reported that the activity shares tactical overlaps with earlier GitHub-abuse campaigns that Trend Micro tracks under the name Water Curse, a link Socket itself did not draw.

The Second Act of a Flaw the Industry Already Patched

For hosting operators, the important word is second. CVE-2026-41940 is not new to this industry. It was exploited as a zero-day from late February, went 64 days before cPanel’s April 28 patch, and drove a spring wave of mass exploitation that Shadowserver’s honeypots measured at more than 44,000 unique IP addresses scanning for and exploiting the flaw. That wave has receded. What the July campaign represents is the long tail: an automated, cheap, and scalable hunt for the servers that never applied the fix.

That is why a three-month-old flaw is worth an operator’s attention again. A vulnerability stops being dangerous not when the patch ships but when the last exposed server installs it, and until then the only real variable is how cheaply an attacker can find the stragglers. Running the scan on GitHub’s free runners drives that cost toward zero. The roughly 1.5 million internet-facing cPanel instances that Shodan sees are not all vulnerable, but they are the haystack this fleet searches, and every unpatched host in it has gone from statistically overlooked to actively enumerated. A patch released in April protects only the servers that installed it.

What to Check If You Run cPanel or WHM

The remediation has not changed, only the urgency. Confirm that every cPanel and WHM instance is on a patched build; the fixed versions have been available since April 28. cPanel publishes an indicator-of-compromise detection script, and any server that was slow to update should be run through it rather than assumed clean, because a control-panel compromise cannot be reliably cleaned in place. On the network side, alert on outbound connections to the payload host at 43.228.157.68 and on callbacks to the campaign’s dnshook.site domain.

Hosts that also build software on GitHub have a second front. Because the campaign runs on GitHub Actions, the defensive steps Socket recommends are automation hygiene: require review for any change under a repository’s workflows directory, keep automation tokens scoped to the minimum, watch for build jobs that download executables from raw IP addresses, and rotate credentials if a repository shows unfamiliar workflow files. The same free automation that ships so much of modern hosting can, with a stolen account, be turned into someone else’s scanning engine.

About the Data

This article draws on Socket’s July 22, 2026 threat report as the primary source for the campaign, corroborated by The Hacker News, and on Rapid7, Help Net Security, SecurityWeek, the National Vulnerability Database and CISA for the flaw and its earlier exploitation. The workflow-file counts and the 1.5 million exposed instances are Socket’s code-search matches and a Shodan exposure estimate; the 44,000 figure is Shadowserver’s count of unique IP addresses attacking the flaw in the spring. None of the three is a count of servers compromised in this July campaign, a number no source has published. Indicators come from Socket. This is reporting, not security advice for a specific system.