In a single day, attackers pushed 5,718 malicious commits across 5,561 public GitHub repositories in roughly six hours. SafeDep, the security firm that discovered the campaign, named it Megalodon. This wasn't a targeted intrusion; it was automated, scaled, and designed to exploit the trust relationships your CI/CD pipeline relies on.
Here's what happened, which controls failed, and what you need to change in your workflows.
What Happened
Attackers used compromised Personal Access Tokens (PATs) or deploy keys to push commits that modified GitHub Actions workflow files. The malicious commits added steps that triggered on workflow_dispatch events—manual workflow triggers that many teams don't monitor closely.
When these workflows executed, they ran attacker-controlled code that exfiltrated secrets available in the CI environment. The primary target: OIDC federation tokens used to authenticate with cloud providers like AWS, Azure, and GCP. With these tokens, attackers could pivot into cloud infrastructure without needing long-lived credentials.
The scale came from automation. Once the attackers had valid credentials to repositories, they scripted the commit-push-execute cycle across thousands of targets simultaneously.
Timeline
The attack compressed into a narrow window:
Hour 0-1: Initial commits pushed to repositories using compromised credentials. Workflow files modified to include malicious steps triggered by workflow_dispatch.
Hour 1-3: Attackers manually triggered workflows or waited for legitimate triggers. Malicious steps executed during CI runs, harvesting secrets and OIDC tokens.
Hour 3-6: Additional waves of commits pushed to remaining repositories. By hour six, 5,561 repositories had been compromised.
Post-attack: SafeDep identified the pattern and published indicators of compromise. GitHub began working with affected repository owners.
The six-hour window matters. If your monitoring doesn't catch unauthorized workflow changes within a shift, you're giving attackers a full workday to operate.
Which Controls Failed
Credential hygiene: The attack required valid PATs or deploy keys. These credentials were either leaked in previous breaches, phished, or extracted from compromised developer machines. Organizations that rotate credentials quarterly or implement short-lived tokens would have limited the attacker's window.
Workflow file integrity monitoring: None of the affected repositories detected unauthorized changes to .github/workflows/*.yml files. Your version control system records every commit, but if no alert fires when a workflow file changes, that audit trail doesn't help.
Secrets exposure in CI: The malicious steps successfully extracted secrets from the GitHub Actions environment. This means secrets were either directly accessible to workflow steps or OIDC tokens had excessive permissions.
Manual trigger monitoring: The workflow_dispatch event type allows manual workflow execution. Most teams monitor failed runs or unusual resource consumption, but few alert on unexpected manual triggers—especially from non-standard accounts or IP ranges.
What Standards Require
ISO/IEC 27001:2022 Annex A.9.2.1 (User registration and de-registration): Requires formal processes for granting and revoking access rights. Compromised credentials that remain valid for months violate this control. Your PAT lifecycle should mirror your employee lifecycle—when someone leaves or a credential is suspected of compromise, revocation should be immediate and automated.
NIST 800-53 Rev 5 CM-3 (Configuration Change Control): Mandates analysis and approval of changes to information systems. Workflow files are executable code that runs with privileged access to secrets. Treating them as configuration—rather than code that requires review—creates the gap this attack exploited.
SOC 2 CC6.1 (Logical and Physical Access Controls): Requires restricting access to information assets. OIDC tokens that can authenticate to production cloud resources from any workflow, without scoping or approval gates, fail this criterion. Your cloud provider's IAM should enforce conditions on OIDC token use: require specific repository sources, branch names, or approval workflows.
PCI DSS v4.0.1 Requirement 6.3.2: For organizations handling payment data, this requirement mandates that custom scripts and code are reviewed before deployment to production. GitHub Actions workflows execute in an environment with access to production secrets—they are custom code and should be reviewed.
Lessons and Action Items
1. Implement workflow file monitoring
Add a detection rule that alerts on any commit modifying files in .github/workflows/. This should fire immediately, not in a daily digest. You want to know within minutes, not hours.
If you use GitHub Enterprise, the audit log API exposes workflow changes. Query it every five minutes and alert on:
- New workflow files
- Changes to existing workflows by users who aren't on your platform team
- Addition of
workflow_dispatchtriggers to workflows that previously lacked them
2. Scope your OIDC tokens
Configure your cloud provider's OIDC trust policy to require specific conditions:
subclaim must match your organization and repository patternrefclaim must match protected branches only (main, release/*)actorclaim should exclude service accounts you don't recognize
AWS example: your IAM role's trust policy should include conditions like "StringEquals": {"token.actions.githubusercontent.com:sub": "repo:yourorg/*:ref:refs/heads/main"}.
3. Rotate and audit credentials now
List all PATs and deploy keys with write access to repositories. For each:
- When was it created?
- Who owns it?
- When was it last used?
Any token over 90 days old should be rotated. Any token without a clear owner should be revoked. GitHub's API lets you script this audit.
4. Require workflow approval for manual triggers
GitHub Actions supports environment protection rules. Create an environment named "manual-trigger" and require approval from your platform team before workflows can run. Update workflows that use workflow_dispatch to specify this environment.
This adds friction, but that's the point. Manual triggers from unexpected accounts should require a human decision.
5. Reduce secrets in CI environments
Every secret available to your CI environment is a target. Replace long-lived secrets with OIDC federation where possible. For secrets that must remain (API keys for third-party services), use GitHub's environment secrets rather than repository secrets, and scope them to specific workflows.
The Megalodon attack succeeded because it found thousands of repositories with the same architectural weakness: workflows that could be modified by compromised credentials and executed with access to valuable secrets. Your repository might not have been in that initial batch, but the technique is now public and easy to replicate.
The six-hour window tells you how fast you need to respond. If your workflow monitoring doesn't exist or runs daily, you're giving attackers the time they need.
