According to Socket, GitHub Actions abuse in Packagist repos ran cPanel scanning from temporary cloud runners.
The incident began with malicious development versions across ten Packagist packages associated with the PHP and DevOps developer known as dinushchathurya. Socket says an attacker gained access to the developer’s GitHub repositories, inserted malicious files under .github/workflows/, and pushed those changes to branches that Packagist then synchronised as development releases earlier this month.
The PHP libraries did not execute the attack. Socket’s analysis found ordinary PHP code containing static reference data and lookup functions, with no install-time hooks, shell commands, or outbound network activity. The attacker instead used each repository’s top-level GitHub Actions configuration to run code in GitHub’s CI environment.
Package installation exposed the malicious files to consumers, but it did not trigger them. GitHub ignores workflow files stored inside a dependency’s vendor directory. A local repository clone also did not launch the malware. The workflows ran when a push reached the compromised repository or when an operator manually started them through GitHub Actions.
A compromised maintainer account became a runner fleet
Socket reports that each malicious Packagist development version contained between 55 and 62 workflow files, totalling 583 files across the ten packages. The srilankan-local-authorities@dev-main package version contained 59 of them.
Each workflow configured GitHub Actions to start on pushes to any branch and through the workflow_dispatch event. GitHub then provisioned an Ubuntu runner, a temporary virtual machine that normally supports build and test work. The workflow checked the runner’s processor architecture, downloaded a matching Linux executable from a server at 43[.]228[.]157[.]68, assigned execute permissions, and ran it.
Socket identified download endpoints for 32-bit x86, 64-bit x86, 32-bit ARM, and 64-bit ARM payloads. The reported SHA-256 hash for the recovered AMD64 sample is:
22f721fd3a81d2e27cbf90a122bb977f630c50b79daa98350f0e57b04dfa81f1
The workflow passed scanner arguments that targeted ports commonly associated with web services and cPanel or WHM administration interfaces, including 80, 443, 8080, 8443, 2082, 2083, 2086, and 2087. Socket says the payload attempted exploitation of CVE-2026-41940, which the report describes as a cPanel and WHM authentication bypass issue.
This architecture gave the attacker short-lived compute capacity and outbound network access without placing scanning infrastructure on their own servers. Each compromised repository could generate fresh runners after ordinary development activity. 59 near-identical workflows in one repository also increased the available execution paths, though Socket has not published data showing how many ran successfully.
GitHub-hosted runners limit persistence because GitHub destroys them after a job completes. That disposal model did not protect external targets. The attacker used each runner as a temporary launch point, then sent collection data back to their server before GitHub removed the machine.
The workflow code handled collection and exfiltration
The downloaded executable performed the scanning and exploit attempts, according to Socket’s account. The workflow files supplied an operational layer around it: execution monitoring, file collection, and data transfer.
A background process sent a status update to the attacker’s /api/github-heartbeat endpoint every 30 seconds. The HTTP POST request included the repository name and the latest scanner log line. That gave the operator a running view of work occurring inside each GitHub Actions job.
The workflows also watched output files for newly-acquired material. Socket says the monitored content included AWS credentials, GitHub and GitLab tokens, OpenAI and Google API credentials, Stripe keys, SendGrid and Mailgun credentials, database connection data, SSH material, Git remote information, environment variables, and configuration files.
The scripts sent data to /api/github-results in chunks and recorded line offsets so they could avoid sending the same content repeatedly. Socket reports that live collection sent up to 2,000 new lines in each request, then a final stage sent up to 5,000 lines even if the scanner process failed.
That design reduces the campaign’s dependence on a single successful job completion. A runner could fail during scanning and still transmit data already written to a results file. It also means a standard CI log review may not show the full output if the attacker redirected scanner results into temporary files before sending them externally.
cPanel and WHM servers sat downstream of the repo compromise
The campaign focused on internet-facing cPanel and WHM systems, Socket says. cPanel gives individual hosting customers control of sites, databases, email accounts, and application settings. WHM manages the server-level environment and can administer multiple cPanel accounts.
A successful WHM compromise could expose multiple customer environments from one server. A cPanel compromise could expose one customer’s website files, databases, mailboxes, deployment credentials, and application secrets. The operational risk extends past the hosting environment when attackers obtain source-control tokens or cloud access keys. Those credentials may provide paths into repositories, cloud workloads, payment platforms, and email delivery services.
The campaign also illustrates why package registry monitoring alone would have missed the execution path. Packagist reflected the malicious repository state, yet GitHub Actions created the compute environment and delivered the payload. Security teams investigating an affected package need to inspect the linked source repository, branch history, Actions run history, audit logs, secrets configuration, OAuth grants, and GitHub App permissions.
Socket says the GitHub account associated with dinushchathurya has since faced suspension. That action removed one source of runner jobs, although Socket cautions that it does not remove workflows copied into other repositories or address credentials already collected from downstream systems.
Search results show broader code reuse, not confirmed victim counts
Socket found a DNS callback identifier in 14 recovered workflows: f5b0b742-240a-4811-8a5b-b0ba6060685d.dnshook[.]site. The workflows used nslookup against that hostname, allowing the operator to record a DNS request and confirm that a command ran even where a job did not return useful output.
Socket says a GitHub Code Search query for that identifier returned about 6,100 matching workflow files. Searches for the command-and-control address, scanner command, credential filenames, heartbeat endpoint, and exfiltration code returned roughly 15,000 to 16,000 matching files.
Those figures do not establish the number of compromised repositories or accounts. One repository can hold many copies of a workflow, GitHub can group identical search results, and some repositories may belong to the campaign operator. The repeated workflow code across unrelated repositories does show that the dinushchathurya packages formed one visible part of a wider operation, rather than a package-specific incident.
Synthetic test results would not settle the exposure question either. The relevant evidence sits in production systems: GitHub Actions job logs, workflow commit history, runner network telemetry, cPanel access records, server process data, and credential-use events. Organisations need to correlate these records with the reported IP address, API paths, payload hash, DNS hostname, and workflow patterns.
Governance starts with repo write access
Repository owners should require review and approval for changes under .github/workflows/, then alert on workflows that download executables from raw IP addresses, invoke curl or wget before running an unknown binary, or send outbound POST requests containing environment data. Teams should limit GITHUB_TOKEN permissions to the minimum each workflow needs and review organisation-level controls that govern which Actions can run.
Self-hosted runners require tighter treatment because they can retain files, credentials, and network access after a job ends. GitHub-hosted runners disappear after execution, yet they still require egress monitoring and workflow review because attackers can use them to scan external systems.
Packagist users should avoid unreviewed development versions, verify Composer lockfile commit references, and pin dependencies to known-good commits or stable releases. cPanel and WHM operators should apply the vendor’s patch guidance for CVE-2026-41940, run cPanel’s IOC detection script where applicable, rotate server-side secrets after suspected exposure, and inspect unauthorised sessions.
The first approval gate for any affected repository should sit on changes to .github/workflows/, where this campaign placed its downloader, scanner launch command, and exfiltration logic.
See also: Cisco open-sources Antares AI models for vulnerability detection
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
