Megalodon: Active GitHub Actions Supply Chain Attack Harvesting CI/CD Secrets at Scale

Executive Summary

An active supply chain campaign tracked as Megalodon is compromising thousands of GitHub repositories by injecting malicious workflow steps that exfiltrate credentials, secrets, and cloud credentials from CI/CD environments. This attack is ongoing right now. As of May 21, 2026, the attacker's ingest server shows 575,352 files stolen and 449 GB of exfiltrated data. Within a three-minute observation window alone, the count grew by 2,365 files and 12 GB. Ossprey Security is tracking the campaign infrastructure and recommends immediate detection sweeps on all repositories using GitHub Actions.

What Is Happening

Compromised repositories receive commits that add a malicious step labeled "Optimize-Build" to existing GitHub Actions workflow files. The step decodes a base64-encoded bash payload that performs three actions: harvests environment variables, cloud credentials, and CI/CD tokens from the runner; scans the repository workspace for hardcoded secrets across 30-plus file extensions; and exfiltrates everything to an attacker-controlled ingest server at 216.126.225.129. The payload targets over 30 credential formats including AWS keys, GitHub tokens, SSH keys, GCP service account credentials, Azure tokens, and HashiCorp Vault tokens.

The exfiltration scale is consistent with an automated campaign actively hitting thousands of repositories simultaneously.

Indicators of Compromise

Network

• C2 IP: 216.126.225.129

• Active port: 8080 (live C2)

• Hardcoded port: 8443 (non-responsive)

• ASN: AS14956 (RouterHosting / Cloudzy, Ashburn VA)

Workflow Artifacts

• Malicious step label: Optimize-Build

• Base64-encoded bash payload injected inline into workflow YAML

• Associated commit email: ci-bot@automated.dev

TTPs

Detection

Run the following against all repositories with GitHub Actions workflows:

# Check for the Optimize-Build step label
grep -r "Optimize-Build" .github/workflows/

# Check for direct C2 IP reference
grep -r "216\.126\.225\.129" .github/workflows/

# Check for inline base64-decoded bash payloads (common injection pattern)
grep -rE 'echo "[A-Za-z0-9+/]{200,}" \| base64 -d'

# Check for the Optimize-Build step label
grep -r "Optimize-Build" .github/workflows/

# Check for direct C2 IP reference
grep -r "216\.126\.225\.129" .github/workflows/

# Check for inline base64-decoded bash payloads (common injection pattern)
grep -rE 'echo "[A-Za-z0-9+/]{200,}" \| base64 -d'

# Check for the Optimize-Build step label
grep -r "Optimize-Build" .github/workflows/

# Check for direct C2 IP reference
grep -r "216\.126\.225\.129" .github/workflows/

# Check for inline base64-decoded bash payloads (common injection pattern)
grep -rE 'echo "[A-Za-z0-9+/]{200,}" \| base64 -d'

Review GitHub Actions run history for any workflows that executed an "Optimize-Build" step, particularly on unexpected branches or triggered by unfamiliar commits.

Immediate Remediation

If you find evidence of the Optimize-Build step in any workflow, treat the runner environment as fully compromised.

1. Rotate all secrets immediately - GitHub Actions secrets, AWS access keys, GCP service account keys, Azure credentials, SSH deploy keys, npm tokens, Docker registry credentials, and any API keys accessible during CI runs

2. Revoke OAuth apps with write access to affected repositories

3. Audit deploy keys across all affected repositories and remove any that cannot be accounted for

4. Review cloud IAM - check for unexpected role attachments or permissions grants made through runner identity (OIDC or instance profile)

5. Examine recent commits for unauthorized branch protection changes or additional workflow modifications beyond the Optimize-Build step

6. Check shell history on any self-hosted runners - the payload targets .bash_history and .zsh_history

7. Scope the blast radius - the payload sweeps /proc/[PID]/environ on Linux, meaning any credentials held in memory by co-running processes on a shared runner are also at risk

For GitHub-hosted runners, the runner environment is ephemeral and not directly recoverable. Focus on credential rotation and access review.