GitHub Actions and Packagist abuse: what IAM and PAM teams should watch

TL;DR: Socket’s July 22 research shows ten compromised Packagist development versions under dinushchathurya/* carried 583 malicious workflow files that used GitHub-hosted Linux runners to exploit CVE-2026-41940, scan for cPanel and WHM targets, and exfiltrate credentials, while the package code itself was not the execution layer. The case reinforces that repository workflows are executable supply-chain content, and CI systems now need identity-grade controls for runners, secrets, and privileged automation, according to Corgea.

NHIMG editorial — based on content published by Corgea covering the GitHub Actions and Packagist supply-chain campaign: Large-Scale GitHub Actions Abuse Powers a Distributed cPanel and WHM Exploitation Campaign

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

Questions worth separating out

Q: What breaks when GitHub Actions workflows are treated as low-risk automation?

A: Teams lose the boundary between code and execution.

Q: Why do CI runners increase non-human identity risk?

A: CI runners act on behalf of repositories, but they often receive tokens, cloud keys, and deployment credentials that outlive a single job.

Q: What do teams get wrong about secrets in build automation?

A: Teams often assume build secrets are safe because the job is temporary, but the credential usually outlives the run.

Practitioner guidance

• Restrict workflow write access Require code-owner review and branch protection for every .github/workflows change, including reused or templated jobs, because the workflow file itself is executable supply-chain content.
• Harden runner secret exposure Move secrets to the narrowest possible job scope, disable broad environment inheritance, and rotate any credentials reachable from CI after suspicious workflow activity.
• Inventory and quarantine CI trust paths Identify which repositories can trigger GitHub-hosted runners, which secrets those runners can read, and which external services they can reach, then quarantine any workflow with internet scanning or arbitrary download behaviour.

What's in the full report

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact injected workflow structure used to trigger on push and manual dispatch across compromised repositories
• The full command-line pattern used by the runner payload to scan for CVE-2026-41940 and dump environment data
• The repository and DNS correlation pivots defenders can use to identify related workflow abuse across their estate
• The specific response steps for cPanel and WHM operators, including vendor IOCs and affected build boundaries

👉 Read Corgea's analysis of the Packagist and GitHub Actions supply-chain campaign →

GitHub Actions and Packagist abuse: what IAM and PAM teams should watch?

Explore further

View Full Forum →  |  NHI Foundation Course →