An attacker pushed 5,718 malicious commits across 5,561 GitHub repositories in just six hours. This campaign, known as Megalodon, didn't rely on a zero-day or novel vulnerability. Instead, it exploited the trust model of CI/CD pipelines: automatic execution of workflow files. This incident underscores the urgent need for enhanced security measures in CI/CD pipelines to prevent supply chain attacks.
What Happened
The attacker used disposable GitHub accounts with random usernames and forged commit author identities to avoid detection. Each compromised repository received a malicious workflow file designed to execute on common triggers like push events, pull requests, and scheduled runs.
Once triggered, these workflows accessed every secret stored in the repository's GitHub Actions configuration, such as AWS credentials, database passwords, and API tokens. The exfiltration occurred through the normal GitHub Actions execution environment, making it difficult to distinguish from legitimate activity.
SafeDep's analysis identified this campaign as part of a broader pattern of supply chain attacks. The speed and scale point to automation rather than manual compromise of individual repositories.
Timeline
Hour 0-1: Initial wave of commits to approximately 1,800 repositories. The attacker established throwaway accounts and began systematic injection of malicious workflow files.
Hour 2-4: Peak activity with over 3,000 additional repositories compromised. Workflow files were designed to trigger on multiple event types to maximize execution opportunities.
Hour 4-6: Final commits pushed. The attack wound down as the attacker completed the campaign across 5,561 total repositories.
Post-attack: Workflows executed as developers pushed code, created pull requests, or scheduled jobs ran. Each execution exfiltrated secrets to attacker-controlled endpoints.
The six-hour window suggests either rate limiting by GitHub's platform or deliberate pacing to avoid detection. Forged author identities meant commit history showed familiar names, not the throwaway accounts actually pushing the changes.
Which Controls Failed
Access control to workflow files. GitHub Actions workflows stored in .github/workflows/ execute with repository secrets. The attacker gained unauthorized write access to these directories across thousands of repositories.
Workflow approval requirements. Many repositories ran workflows without requiring approval for changes to workflow files themselves, allowing immediate execution of malicious workflows.
Secret scope limitations. Secrets configured at the repository level were accessible to any workflow in that repository. The attacker didn't need to compromise individual secrets—just inject a workflow that could read them.
Monitoring for bulk repository modifications. The attack touched 5,561 repositories in six hours. This should have triggered alerts for anomalous activity, but either monitoring wasn't configured or alerts didn't reach security teams in time.
Commit verification. Forged author identities worked because commit signing wasn't enforced. GPG-signed commits would have made the forgery obvious, but most repositories don't require signature verification.
What Standards Require
ISO/IEC 27001:2022 Control 8.3 requires authentication and authorization for access to systems and applications. For CI/CD pipelines, this means:
- Treat workflow files as executable code requiring code review.
- Restrict write access to workflow directories to authorized personnel.
- Require approval for changes to workflows from someone other than the author.
NIST 800-53 Rev 5 CM-3 mandates review and approval of system changes before implementation. Your GitHub Actions workflows are system configuration. They need:
- Pull request requirements for
.github/workflows/changes. - Required reviewers who understand the security implications.
- Branch protection rules that prevent direct commits.
SOC 2 Type II CC6.6 requires restricting access to information assets. Your CI/CD secrets are information assets. The control requires:
- Least privilege access to secrets.
- Logging of all secret access.
- Regular review of who can access which secrets.
PCI DSS v4.0.1 Requirement 6.4.2 includes secure coding practices for deployment automation. If your workflows process cardholder data or deploy to systems that do:
- Review workflows for security vulnerabilities.
- Route changes to workflows through change control.
- Log and monitor workflow execution.
Lessons and Action Items
Require pull requests for workflow changes. Set branch protection rules that require PR approval for any changes to .github/workflows/. Your security team or platform engineering team should review workflow modifications.
Scope secrets to specific workflows. GitHub supports environment-based secrets that require manual approval before workflow execution. Move production secrets to environments with required reviewers.
Enforce commit signing. Enable GPG signature verification on protected branches. This makes forged author identities useless—unsigned commits get rejected.
Monitor workflow additions and modifications. Set up alerts for changes to workflow files, especially bulk modifications across multiple repositories. Your SIEM should ingest GitHub audit logs and flag patterns like multiple workflow files added in a short timeframe.
Audit repository access tokens. Review who has personal access tokens and OAuth apps with write access to repositories, what scopes they have, and when they were last used. Rotate tokens that have broader access than necessary.
Implement workflow approval requirements. For repositories containing sensitive secrets, require manual approval before any workflow runs.
Review your blast radius. If an attacker compromises one repository, how many others can they reach? Segment your infrastructure so compromise of one repository doesn't cascade.
The Megalodon attack succeeded by exploiting the automation that makes CI/CD efficient. Your action items should make that automation more secure without breaking your deployment velocity. Start with workflow file protection and secret scoping—those two changes would have prevented the exfiltration even if the attacker successfully injected malicious workflows.
