A new campaign documented by Socket shows that attackers do not need to install malware directly on the machines of PHP library users. Instead, they compromise source-code repositories, inject hundreds of malicious workflows, and turn GitHub Actions into infrastructure for scanning and exploiting cPanel and WHM servers across the Internet.
The case matters because it expands how we should think about software supply chain attacks. The risk is not only in source code that developers download, but also in CI/CD automation that can execute commands on behalf of a compromised repository. For web hosting platforms, one compromised server can expose multiple websites, databases, email accounts, API keys, and payment information.
The campaign began with Packagist packages, but did not execute through the PHP library path
According to Socket, the activity involved 10 Packagist packages tied to the legitimate developer account dinushchathurya. On 12 and 13 July 2026, Packagist automatically synchronized development versions containing malicious changes from GitHub into the PHP ecosystem.
The unusual point is that the malicious code did not sit in the normal execution path of the PHP library. The affected packages contained a total of 583 GitHub Actions workflow files, with roughly 55 to 62 workflows per package. If a user only installed the package through Composer, these workflows usually remained under the vendor directory and did not run automatically. The real attack mechanism was in compromised GitHub repositories, where the .github/workflows directory was in the right location for GitHub Actions to trigger a runner.
How a runner becomes a temporary scanner and exploitation node
When a compromised repository receives a push or a workflow is manually triggered, GitHub provisions a temporary runner. The malicious workflow checks the runner's processor architecture, downloads the matching Linux payload from the attacker's command server, and starts scanning cPanel/WHM systems that may be exploitable.
The main target is CVE-2026-41940, an authentication bypass vulnerability in cPanel and WHM that had already been warned as exploited in the wild. If successful, the payload searches for sensitive information such as configuration files, environment variables, database credentials, SSH keys, GitHub/GitLab tokens, AWS keys, email service credentials, payment keys, and data useful for follow-on exploitation.
Scale revealed through a DNSHook indicator
Socket said the malicious workflows continuously sent execution status and collected data back to the attacker's infrastructure. A distinctive DNSHook indicator appeared in roughly 6,100 workflow files on GitHub, while searches for the C2 address, scanner command, credential-related filenames, and extraction logic suggested around 15,000 to 16,000 matching files.
These figures do not mean the same number of accounts were compromised, because one repository can contain many workflows and some repositories may have been attacker-controlled infrastructure. Still, the presence of the same highly specific code pattern across many unrelated repositories indicates a broader campaign, not an isolated incident involving one package set.
Why cPanel and WHM are attractive targets
cPanel and WHM often administer critical components of a web server: website files, email accounts, databases, certificates, application configuration, and, in many hosting models, multiple customers on the same server. When this management layer is bypassed, the impact can spread from one website to the entire hosting environment.
The more dangerous aspect is that data collected from one server can be used to expand the campaign. Git tokens, cloud keys, SMTP credentials, payment keys, or API keys can lead to other repositories, deployment systems, and service accounts. This is why attacks against CI/CD and control panels are increasingly treated as operational risk, not just source-code risk.
Defensive lessons for operations and development teams
Organizations using cPanel/WHM should prioritize checking patches related to CVE-2026-41940, review authentication logs, administrative access logs, unusually accessed configuration files, and signs of credential extraction. Hosting systems that serve multiple websites or multiple customers should be inventoried separately because the cascading impact is often larger than a single standalone server.
For development teams, enforce multi-factor authentication on GitHub accounts, control write access to workflows, review changes under .github/workflows, limit secrets available to runners, and monitor unusual workflow behavior. In important repositories, workflow changes should be reviewed like infrastructure changes, because a short YAML file can grant command execution inside an automation environment.
Conclusion
This campaign shows that the boundary between code repositories, automation systems, and production servers is becoming increasingly blurred. A compromised GitHub account may not only distribute a malicious package; it can also activate a temporary runner network to scan and exploit third-party infrastructure.
For the cybersecurity community, the core lesson is not to treat CI/CD as a harmless auxiliary utility. If abused, GitHub Actions can become low-cost, highly scalable distributed attack infrastructure with traces that are difficult to tie back to a fixed server.
VNCyberS compiled from Socket and The Hacker News
Tiếng Việt
English