I am used to package compromises. A maintainer gets their credentials stolen, a malicious version ships to npm or PyPI, and everyone who installs it runs the attacker's code. The pattern is well worn, we know what to look for.
The analysis Socket published on 22 July 2026 describes something else, and that is what caught my eye. Installing the compromised package runs nothing at all. The library code is clean. What is poisoned are the GitHub Actions workflow files at the root of the repositories. And the payload does not target the package users: it turns the repositories themselves into a distributed Internet scanner, tasked with exploiting a critical flaw in cPanel and WHM.
In other words, the repository is not the infection vector. It is the attacker's compute infrastructure. And they use it for free, on GitHub runners.
What happened
The investigation starts from Packagist, the PHP package repository. Ten packages belonging to a legitimate PHP and DevOps developer, dinushchathurya, exposed malicious development versions. This developer is a victim, not the attacker: their GitHub repositories were compromised, and Packagist did its job by automatically syncing, on 12 and 13 July 2026, what the attacker had pushed there.
Each affected version bundled between 55 and 62 malicious workflow files, for a total of 583 files across the ten packages. These are not published stable releases but branch versions, which explains why they slipped past a good share of consumers.
The point I find most instructive fits in one sentence from the analysis: the PHP code is benign. Static data, ordinary search functions, no install hooks, no network activity. The whole attack lives inside .github/workflows/.
Why installing the package triggers nothing
This is the detail that overturns the usual reflexes, and it deserves a pause.
When you install the package through Composer, Packagist places it in your project's vendor/ directory. But GitHub ignores nested workflow files: only the ones located in .github/workflows at the repository root are considered. The malicious workflows therefore end up inert on the consumer's side. Cloning the repository onto your machine runs nothing either.
Execution happens in a single case: when the compromised repository itself receives a push, or when someone manually triggers the workflow. The workflows are declared to wake up on any branch, with a very generous execution budget:
on: push: branches: ['**'] workflow_dispatch:jobs: run: runs-on: ubuntu-latest timeout-minutes: 350Those 350 minutes are not there by accident. An Internet scanner needs time, and the attacker helps themselves to the compromised repository's quota.
The runner as a scanning machine
The sequence on the runner is methodical. The workflow first detects the processor architecture, then downloads the matching payload from a command and control server reachable by raw IP address, with no domain name.
Then comes execution in scanner mode:
/tmp/.svc ipscan \ --source random,all \ --exploit CVE-2026-41940 \ --git \ --envdump \ --ports 80,443,8080,8443,2082,2083,2086,2087The listed ports are the target's signature: 2082, 2083, 2086 and 2087 are the historical ports of cPanel and WHM. The --git and --envdump flags make the intent plain, they hunt for repositories and environment variables.
The whole thing is driven like a real exploitation tool. A heartbeat every 30 seconds reports progress and the last log line, identifying the repository the scan runs from. Results are exfiltrated by HTTP POST, split into chunks, with tracking of line offsets so the same data is never sent twice. The final exfiltration step runs even if the scanner failed.
What the scanner harvests on the servers it reaches is dizzying: AWS credentials, GitHub and GitLab tokens, OpenAI and Google API keys, Stripe keys, SendGrid and Mailgun credentials, database information, SSH material, Git remotes, and remote code execution results.
The targeted flaw, and why it hurts
The technical target is CVE-2026-41940, an authentication bypass in the login flow of cPanel and WHM, present on versions after 11.40. The figures speak for themselves.
| Indicator | Value |
|---|---|
| CVSS score | 9.8 (critical) |
| Vector | Network, no authentication or interaction |
| EPSS | 98.1% probability of exploitation within 30 days |
| CISA KEV catalog | Yes, confirmed exploitation |
An EPSS of 98.1% combined with a listing in CISA's catalog of actively exploited vulnerabilities means exploitation is not a theoretical hypothesis. It is underway, at scale.
The hierarchy between the two products explains the attacker's interest. cPanel administers a hosting customer's account, with its sites, databases and mailboxes. WHM is the control plane above it, which creates and manages several cPanel accounts. Compromising a WHM therefore potentially opens several hosted environments at once.
How big is this, really
This is the point I want to be precise about, because it is where a lot of approximations creep in.
A GitHub code search, starting from a unique identifier left by the campaign, returns roughly 6,100 matching workflow files. Widening it to the other markers (command server address, scanner arguments, credential file names, exfiltration endpoints), the count climbs to 15,000 to 16,000 files.
What these numbers do establish, on the other hand, is that the campaign goes far beyond the initial PHP maintainer's case. Identical, highly distinctive code shows up in unrelated repositories, including established projects with a normal development history. The victim developer's account was suspended, which cut off one launch path, but the operation should be considered still active.
What I take away for our pipelines
This case confirms something I have repeated since the compromises of Trivy and Checkmarx KICS: a CI workflow is executable code, not configuration. It deserves the same review, the same access controls and the same monitoring as application code. As long as we treat pipeline YAML as a housekeeping detail, this kind of campaign will thrive.
Three blind spots strike me as particularly exposed here.
Workflow review. On many projects, a change under .github/workflows goes through with the same lightness as a README edit. That is exactly what the attacker exploits: they push 59 files at once, and nobody looks.
Runner network egress. A runner that downloads a binary from a raw IP address, then sends POSTs every 30 seconds to that same IP, is aberrant behavior that no legitimate build produces. You still have to be watching.
Development versions. Locking your dependencies to known commit references rather than moving branches would have avoided the automatic sync of the poisoned versions.
What I would do right now
Here is what I would apply, in this order.
On your repositories, require a mandatory review of any change touching .github/workflows, and check that no unknown workflow has slipped in. Review your OAuth grants and GitHub apps, and rotate your credentials if any doubt remains. Keep your Actions run logs, they are your only trace if the incident concerns you.
On your organization, cut the GITHUB_TOKEN permissions to the strict minimum, which I detail in the guide on workflow permissions. Monitor the network egress of your runners and alert on any download from a raw IP address: that is precisely the job of a tool like Harden Runner. Pin your actions by commit SHA rather than by tag.
On your PHP dependencies, ban unreviewed development versions, verify the commit references in your lock files, and move back to stable versions.
And if you run cPanel or WHM exposed on the Internet, apply the CVE-2026-41940 patch without waiting, then run the indicator-of-compromise detection script provided by cPanel on any machine that stayed exposed during the window.
Key takeaways
- The PHP package code is clean: the attack lives in the repository's workflow files, not in the library.
- Installing the package runs nothing. Only a push to the compromised repository triggers the payload.
- The compromised repositories serve as distributed scanning infrastructure, on GitHub runners, at the victim's expense.
- The final target is CVE-2026-41940, a cPanel and WHM authentication bypass, CVSS 9.8, EPSS 98.1%, present in the CISA KEV catalog.
- The 6,100 to 16,000 files spotted are matching files, not confirmed compromised repositories.
- A CI workflow is executable code and must be reviewed, restricted and monitored as such.
Useful links
- GitHub Actions: 15 security pitfalls that expose your pipelines
- Checkmarx/KICS compromised: when scanners become the attack surface
- Shai-Hulud returns: an npm worm loots the AntV ecosystem
- Securing GitHub Actions
- OWASP Top 10 CI/CD
- Plumber, CI/CD pipeline scanner