How many GitHub repositories were affected by the Megalodon attack?

The Megalodon attack compromised 5,561 GitHub repositories, with attackers pushing 5,718 malicious code updates across those repositories in a single six-hour window.

What method did the attackers use to carry out the Megalodon attack?

Attackers used fake contributor identities to submit pull requests or directly modify GitHub Actions YAML workflow files, which then executed automatically within GitHub's CI/CD pipeline environment.

What types of credentials and data were stolen during the attack?

The malicious workflows targeted cloud provider credentials such as AWS, GCP, and Azure access keys, SSH private keys, and plaintext secrets embedded in source code or configuration files.

Did the Megalodon attack rely on zero-day exploits or malware?

No, the attackers did not use zero-day exploits or sophisticated malware; instead, they exploited the trusted nature of GitHub's own CI/CD infrastructure by injecting malicious workflow files.

Why is automation considered a defining characteristic of the Megalodon attack?

Executing nearly 5,720 code pushes across more than 5,500 repositories in six hours required scripted tooling to identify targets, authenticate, and submit changes in parallel, expanding the attack surface faster than human monitoring teams could track.

Megalodon Attack Hits 5,561 GitHub Repos in Six Hours

A GitHub CI/CD supply chain attack named Megalodon has set a new benchmark for automated, large-scale repository compromise. In a single six-hour window, attackers pushed 5,718 malicious code updates across 5,561 GitHub repositories, using fake identities to inject workflow files designed to silently drain cloud credentials, SSH keys, and source code secrets. The sheer speed and volume of the campaign signals a shift toward industrialized pipeline attacks that outpace most teams' ability to detect or respond in real time.

How the Megalodon Attack Worked: Fake Identities and Automated Workflow Injection

The attackers behind Megalodon did not rely on zero-day exploits or sophisticated malware delivered to end-user machines. Instead, they exploited the trusted nature of GitHub's CI/CD infrastructure itself. By constructing fake contributor identities, they submitted pull requests or directly modified workflow configuration files, specifically the YAML files that GitHub Actions uses to define automated build and deployment pipelines.

Once a malicious workflow file lands in a repository, it executes automatically whenever the pipeline triggers, typically on push events or pull request merges. That execution happens inside GitHub's own runner environment, which often has access to repository secrets, environment variables, and tokens scoped to cloud providers. The Megalodon workflows used that access window to exfiltrate data outbound, likely to attacker-controlled infrastructure, before any repository maintainer had reason to review the change.

The campaign's defining characteristic is its automation. Executing nearly 5,720 distinct code pushes across more than 5,500 repositories in six hours is not a manual effort. It requires scripted tooling that can identify targets, authenticate with fake identities, craft plausible-looking workflow modifications, and submit them in parallel. This level of automation means the attack surface expanded faster than any human monitoring team could track.

What Credentials Were Stolen and Why That Matters for Developers

The payload of each malicious workflow was credential harvesting. The targets included cloud provider credentials, most commonly AWS, GCP, and Azure access keys stored as GitHub Secrets or referenced inside workflow environment variables. SSH private keys used for server access or inter-service authentication were also in scope, along with any plaintext secrets embedded in source code or configuration files.

Those credential types carry cascading risk. A stolen AWS access key tied to an IAM role with broad permissions can allow an attacker to spin up infrastructure, exfiltrate data stores, or pivot laterally into connected services within minutes. SSH keys can provide persistent access to production servers long after the original breach is detected and the GitHub repository is cleaned up. The value of this data extends well beyond the repositories themselves.

This is not a hypothetical risk pattern. Earlier this year, a CISA contractor exposed AWS keys and plaintext passwords on a public GitHub repository, demonstrating that credential mismanagement in development environments affects even organizations with dedicated security mandates. Megalodon simply industrialized the same exploit path that individual human errors have already demonstrated repeatedly.

It is also worth noting that credential theft tools and pipelines are themselves targets. The recent Bitwarden CLI supply chain attack showed that even the tools developers use to manage secrets can be compromised upstream, meaning the trust chain extends beyond any single repository or pipeline configuration.

Defense-in-Depth for Development Teams: Secrets Management, Encrypted Comms, and Access Controls

Megalodon exploited several weaknesses that are common across open source and private repositories alike. Addressing them requires a layered approach rather than a single control.

First, secrets should never be stored as plaintext inside workflow files, environment configuration files, or source code. GitHub's encrypted Secrets feature provides a baseline, but those secrets should also follow the principle of least privilege. A workflow that deploys to a staging environment does not need production database credentials. Scoping secrets tightly limits the blast radius when a workflow is compromised.

Second, branch protection rules and required reviewers for workflow file changes create a human checkpoint that automated attacks must bypass. Requiring at least one approved review before any modification to .github/workflows/ files can slow or block the kind of rapid automated injection Megalodon relied on.

Third, pinning third-party GitHub Actions to specific commit SHAs rather than floating tags prevents a separate but related attack vector where compromised action publishers silently update a tag to point to malicious code. This has been the mechanism in several recent GitHub Actions supply chain incidents.

Finally, audit logging and anomaly detection on workflow runs can surface unexpected outbound network connections or unusual secret access patterns. GitHub's audit log API and third-party CI/CD security tools can help surface these signals.

How to Audit Your GitHub Repositories and CI/CD Pipelines Now

If your organization maintains GitHub repositories with active CI/CD pipelines, a few immediate steps are worth prioritizing.

Review all files under .github/workflows/ for any recently added or modified entries, particularly those added by contributors you do not recognize. Check the commit history for workflow files specifically, not just the default branch view.

Rotate any secrets that were active during the period of the attack or that you cannot confidently confirm were unexposed. For cloud credentials, review provider-side access logs for unusual API calls during the same window.

Audit which repository contributors and applications have write access. Fake identity attacks depend on the ability to push code, so tightening contributor permissions and enabling required reviews for workflow changes removes a key entry point.

Finally, consider adopting a dedicated secrets scanning tool that runs on every commit, catching credentials before they are ever committed to a repository. Several open source and commercial options integrate directly with GitHub.

What This Means For You

The Megalodon campaign is a practical illustration of why CI/CD pipelines have become a primary attack surface. Developers and security teams who treat pipeline security as secondary to application security are leaving a wide-open path to their most sensitive credentials.

Start with a secrets audit this week. Review who can modify your workflow files, rotate credentials you cannot verify as clean, and enable branch protection on your default branch if you have not already. The speed of the Megalodon attack means that by the time an alert fires, exfiltration may already be complete. Prevention and access scoping are the only reliable defenses.