Between July 12 and 13, 2026, attackers compromised ten Packagist packages tied to a legitimate PHP developer's account. They injected 583 malicious GitHub Actions workflow files across those packages, with 55 to 62 files per package. When developers pulled these compromised dependencies, the workflows triggered automatically, launching attacks against cPanel and WHM servers to steal credentials, SSH keys, database access tokens, and cloud service credentials.
This was a real supply chain attack, turning your CI/CD runner into an adversary's launch platform.
Timeline
July 12, 2026: Attackers gained access to dinushchathurya's Packagist account and began publishing malicious development versions of ten legitimate packages.
July 12-13, 2026: The compromised packages spread, each containing dozens of GitHub Actions workflow files designed to execute immediately when pulled into a repository.
Post-deployment: The malicious workflows scanned for cPanel and WHM servers, attempted authentication bypass, and exfiltrated credentials, environment variables, configuration files, Git tokens, payment service credentials, and other secrets.
Discovery: Socket's research team identified the campaign and published findings, prompting removal of the malicious packages.
Which Controls Failed or Were Missing
Repository Access Controls
The attacker gained write access to a legitimate developer's Packagist account. There was no public evidence of multi-factor authentication enforcement or session monitoring that could have detected the compromise early.
Workflow Review Process
GitHub Actions workflows executed without human review. The 583 malicious files ran automatically when developers integrated the compromised packages. No pre-execution approval gate existed.
Secrets Management
The payload successfully harvested credentials from multiple sources: environment variables, configuration files, and local storage. This suggests secrets were stored in plaintext or easily accessible formats within the CI/CD environment.
Network Segmentation
The GitHub Actions runners had network access to scan for and communicate with external cPanel and WHM servers. There was no apparent network isolation limiting what the runners could reach.
Dependency Verification
The packages were pulled without cryptographic signature verification or integrity checks that could have flagged the unauthorized modifications.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software, and third-party software components. You can't protect what you don't track. The compromised packages would fall under this inventory requirement, and your change detection should have flagged the sudden injection of 55-62 workflow files per package.
Requirement 6.4.3 specifically addresses scripts loaded or executed from external sources. GitHub Actions workflows are exactly that, executable code loaded from your dependency tree. The requirement states these scripts must be authorized and their integrity verified before execution. Automatic workflow execution without review violates this control.
ISO 27001 Control 8.30 covers outsourcing and requires you to manage security risks in supplier relationships. Your CI/CD pipeline is part of your software supply chain. When you pull dependencies, you're entering a supplier relationship. The standard requires defined security controls for these relationships.
NIST 800-53 Rev 5 Control SA-10 addresses developer security testing and evaluation. It requires you to verify that security functions operate as intended before deployment. Workflows that execute without validation fail this control.
SOC 2 Type II CC6.6 requires logical access controls, including authentication and authorization for system components. GitHub Actions runners are system components. The lack of workflow approval gates and unrestricted network access from runners violates this criterion.
Lessons and Action Items for Your Team
Require Workflow Approval
Configure your GitHub repositories to require manual approval for workflows from first-time contributors or modified workflow files. In GitHub, go to Settings → Actions → General → Fork pull request workflows and enable "Require approval for all outside collaborators."
This won't catch every scenario, but it adds friction for attackers trying to inject malicious workflows through compromised dependencies.
Isolate Your Runners
Self-hosted runners should operate in isolated network segments with explicit egress rules. If your runners don't need to scan the internet for cPanel servers, don't let them. Use network policies to restrict outbound connections to only the services your builds actually require.
For GitHub-hosted runners, use OIDC tokens instead of long-lived credentials, and scope them as narrowly as possible.
Move Secrets Out of the Environment
Stop storing credentials in environment variables or configuration files that workflows can read. Use dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) with short-lived tokens and audit logging.
If a workflow needs a credential, it should request it through an authenticated API call that logs the access, not read it from a file.
Verify Dependency Integrity
Implement Sigstore or similar cryptographic verification for your dependencies. Pin specific versions and verify checksums before installation. If a package suddenly gains 60 workflow files, your verification should fail.
Use tools like Socket, Snyk, or GitHub's dependency review to scan for suspicious changes in your dependency tree before they reach production.
Monitor Workflow Execution
Set up alerts for workflow executions that deviate from baseline behavior: unusual network connections, credential access patterns, or execution times. Your SIEM should ingest GitHub Actions logs.
Look for workflows that run immediately after dependency updates, especially if they're accessing files outside the expected build context.
Audit Third-Party Accounts
Review access controls on your package registry accounts (npm, PyPI, Packagist). Enforce MFA. Rotate credentials. Monitor for unauthorized publishes.
The initial compromise here was account access. Better identity controls would have prevented the entire chain.
This attack worked because CI/CD security often stops at scanning code for vulnerabilities. It doesn't extend to "what can the build system itself do?" Your runners have network access, credential access, and automatic execution privileges. That makes them valuable targets, not just build tools.
