Inside the Megalodon GitHub Supply‑Chain Attack

The operation ran between approximately 11:36 and 17:48 UTC, suggesting a highly automated system designed to compromise large numbers of repositories quickly before maintainers noticed the changes.

How attackers injected thousands of commits so quickly

The campaign relied on automation and social camouflage to make malicious commits look like normal CI maintenance.

Fake CI bots and disposable accounts

Attackers created throwaway GitHub accounts with randomized usernames and spoofed automation identities such as:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

These identities made commits appear to come from routine automation systems rather than a human attacker.

Forged commit metadata

Commit authorship data and messages were crafted to look legitimate—often resembling routine workflow updates or CI configuration tweaks. This helped the commits blend into normal development activity and delayed suspicion.

Targeting weak branch protection

The campaign focused on repositories where branch protection rules were weak or missing. Without mandatory pull‑request reviews or restrictions on who can modify workflows, attackers could push workflow changes directly to the repository’s default branch.

Poisoned GitHub Actions workflows

Each malicious commit inserted a GitHub Actions workflow file containing a Base64‑encoded Bash payload. When the CI pipeline executed, the script ran inside the GitHub Actions runner and began harvesting credentials.

This design meant the attack often remained dormant until the next CI run triggered the workflow.

What the payload tried to steal

The Base64‑encoded script embedded in the workflows was designed to collect sensitive data from the CI environment and send it to attacker‑controlled infrastructure.

Reported targets included:

• CI/CD environment variables
• Cloud provider credentials (AWS, Google Cloud, Azure)
• SSH private keys
• API tokens and application secrets
• GitHub Actions OIDC tokens
• Other configuration secrets exposed in the runner environment

The malware gathered environment variables, system information, and secrets accessible to the CI runner before exfiltrating them to a command‑and‑control server.

Because CI pipelines often contain deployment credentials, compromising a build environment can open paths to cloud infrastructure, package registries, and production deployments.

Why stealing OIDC tokens is especially dangerous

A major objective of the Megalodon payload was GitHub Actions OIDC tokens.

Modern CI/CD pipelines frequently use OpenID Connect (OIDC) federation to authenticate to cloud providers without storing long‑lived credentials. Instead, a workflow requests a short‑lived identity token that cloud providers exchange for temporary access credentials.

This approach improves security by eliminating static API keys or service‑account credentials. However, it introduces a new risk: if an attacker can steal the token during pipeline execution, they may temporarily impersonate the CI job’s identity.

Because these tokens are trusted by cloud identity systems, a stolen token can potentially be exchanged for temporary cloud access with the same permissions granted to the deployment pipeline.

That means a compromised CI workflow could lead to:

• cloud infrastructure access
• deployment pipeline hijacking
• secrets retrieval from cloud services

Even though OIDC tokens expire quickly, the permissions attached to them can still make short‑term access highly valuable for attackers.

Why the attack mattered

The Megalodon campaign illustrates a shift in supply‑chain attacks away from modifying application code and toward compromising automation infrastructure.

By targeting CI workflows instead of source code, attackers can:

• steal credentials automatically when pipelines run
• access deployment systems and cloud environments
• remain hidden inside routine automation changes

Because thousands of repositories rely on CI pipelines with powerful credentials, a single workflow modification can expose secrets across many downstream systems.

Was Megalodon connected to the GitHub VS Code extension breach?

Around the same time, GitHub disclosed a separate security incident involving a poisoned Visual Studio Code extension installed on an employee device. The malicious extension enabled attackers to access roughly 3,800 internal GitHub repositories before the compromise was contained.

That breach was traced to a compromised developer environment and involved credential harvesting through a trojanized extension distributed via the VS Code marketplace.

Some security reporting notes similarities in timing and tactics between that incident and other supply‑chain attacks targeting development tooling. However, public evidence has not confirmed that the internal GitHub breach directly enabled the Megalodon campaign.

For now, the two incidents are best understood as separate but contemporaneous supply‑chain security events affecting the developer ecosystem.

The broader lesson for CI/CD security

Megalodon demonstrates how quickly automation can scale a supply‑chain attack across thousands of repositories. By combining impersonated bots, automated commits, and poisoned CI workflows, attackers turned routine build infrastructure into a credential‑harvesting system.

The incident reinforced several defensive priorities for software teams:

• strict branch protection rules
• mandatory reviews for workflow changes
• minimal permissions for CI jobs
• careful monitoring of automation accounts and workflow updates

As development pipelines increasingly control cloud deployments and production infrastructure, the security of CI/CD workflows has become a critical part of software supply‑chain defense.