Do Son 
At a Glance
| Actor or group | Unattributed threat actor; no group name published |
| Activity type | GitHub Actions abuse, internet scanning, credential theft |
| Targets | Internet-facing cPanel and WHM servers; GitHub repositories |
| Scale | 583 malicious workflows in 10 Packagist packages; ~6,100 to 16,000 matching files on GitHub |
| Law-enforcement status | No charges announced; one maintainer account suspended |
| Source | Socket threat research |
TL;DR
Socket researchers traced 583 malicious workflow files across ten PHP packages on Packagist. The files hijacked free GitHub runners and pointed them at cPanel and WHM servers. Code searches suggest the same attack code sits in thousands of unrelated repositories.
What Happened
Between July 12 and 13, 2026, Packagist synchronized malicious development versions for all ten packages tied to the PHP and DevOps developer dinushchathurya. Each version carried between 55 and 62 workflow files.
Those YAML files told GitHub to launch temporary Ubuntu runners after any push. The runners then checked their processor architecture and pulled a matching Linux payload from 43[.]228[.]157[.]68.
Next, the payload scanned the open internet, targeted cPanel and WHM services, and attempted to exploit CVE-2026-41940, an authentication bypass flaw.
The Malware Never Sat in the PHP Code
This case breaks the usual malicious-package pattern. Installing an affected library did not trigger anything, because Composer drops dependencies into the vendor directory, where GitHub ignores nested workflows.
Socket’s write-up is blunt about the real execution layer: “The campaign’s execution layer is GitHub Actions, not PHP.” The library code itself stayed benign, holding only static reference data and lookup functions.
Who Is Behind It
Nobody has been named, charged, or arrested. Attribution confidence therefore remains low. Researchers describe an unnamed threat actor who allegedly gained push access to the maintainer’s repositories and committed the workflows there.
Investigators can, however, link the activity with high confidence through code reuse. Fourteen recovered workflows queried the same unique DNSHook callback hostname, which gave analysts a reliable pivot.
Impact and Scale
The GitHub Actions abuse extends well past one maintainer. A search for the DNSHook identifier returned roughly 6,100 matching workflow files. Broader queries using the C2 address, scanner arguments, and exfiltration endpoints returned about 15,000 to 16,000 files.
Socket cautions against reading those numbers as a victim count: “These figures represent matching files, not confirmed compromised accounts or repositories.” Some accounts may be staging infrastructure rather than victims.
The stolen data set is broad. Scanners looked for AWS keys, GitHub and GitLab tokens, OpenAI and Google credentials, Stripe keys, mail-service keys, database logins, SSH material, and Git remotes.
WHM raises the stakes further. One compromised control plane can expose many hosting customers at once.
What Comes Next
The suspended maintainer account closed one launch path. It did not close the campaign. Forks, mirrors, cached snapshots, stolen credentials, and the C2 server may all remain live.
How Defenders Can Respond
- Patch cPanel and WHM against CVE-2026-41940 without delay.
- Restrict panel ports 2082, 2083, 2086, and 2087 to trusted networks.
- Audit Actions run history for unexpected workflows and long-running jobs.
- Require review before workflow files change on any branch.
- Rotate cloud, payment, and source-control secrets after any suspected exposure.
Finally, treat the operation as ongoing. Defenders should keep hunting for the C2 address and the DNSHook hostname across their own repositories.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
