MEGALODON_CI: Automated GitHub Actions Workflow Poisoning and CI/CD Credential Harvesting at Scale

Executive Summary

Automated mass commits are replacing legitimate GitHub Actions workflow files with a malicious version named “Optimize-Build.” When the poisoned workflow runs, it decodes and executes a bash credential harvester. The script drains every secret the runner can reach: AWS keys across all configured profiles, GCP OAuth tokens, SSH private keys, GitHub OIDC tokens, kubeconfig, Terraform and Vault credentials, Docker registry auth, package registry tokens, and cloud instance metadata queried from AWS, GCP, and Azure IMDS endpoints — all in a single execution.

This campaign has no CVE. No scanner fires on it. The payload is a base64-encoded shell script injected directly into a workflow YAML file. Every tool that monitors packages and libraries is blind to it. Catching it requires workflow file integrity monitoring, GitHub audit log analysis, or network egress anomaly detection on CI runners.

Each compromised repository gets a unique device ID embedded in the payload at injection time. All exfiltration routes to a C2 server at 216.126.225.129:8443 under the campaign identifier “megalodon.” GitHub code search on the payload base64 prefix (Q0I9Imh0dHA6Ly8yMTYu) returned over 3,500 infected YAML files at time of writing, with an alleged total of 5,000+ repositories reported by OX Security. The two initially confirmed repositories are from unrelated organisations — a commercial live chat platform and a personal geolocation project — confirming automated iteration across a corpus of stolen GitHub tokens or OAuth grants.

OX Security has explicitly linked this campaign to the preceding TeamPCP GitHub breach, framing MEGALODON as a second wave that followed once attacker access to GitHub infrastructure was established.

TL;DR for Engineering Teams

Vulnerability Overview

Technical Anatomy

Root Cause

There is no software vulnerability here. GitHub Actions works exactly as designed: any workflow file committed to a repository runs on the runner with whatever permissions it requests. The attacker gains write access via a stolen PAT, OAuth grant, or compromised account, commits a replacement workflow, and the runner executes it cleanly. The runner has no way to know the workflow was swapped.

GitHub has no built-in enforcement for workflow file integrity. Nothing in the platform detects that a workflow was replaced with a malicious version. Nothing requires cryptographic signing of workflow content. Nothing alerts when a workflow suddenly requests id-token: write — a permission most standard workflows never need. The attacker added that permission deliberately. It unlocks OIDC token generation, and its presence in any replacement workflow is the clearest available signal that something is wrong.

Three-Step Exploit Path

Attack Chain — Phases

Phase 1 — Access Acquisition Attacker obtains write access to GitHub repository via stolen PAT, OAuth grant abuse, or compromised account credential.

Phase 2 — Workflow Injection Automated tooling commits replacement workflow files. All workflow files in .github/workflows/ are targeted. Each injected file receives a unique device ID embedded in the payload. Commits use a hardcoded fake identity — ci-bot@automated.dev or build-system@noreply.dev, dated September 17, 2001 — mirroring TeamPCP use of a fabricated commit date to obscure timing.

Phase 3 — Credential Harvest On next workflow execution, the runner exfiltrates: all environment variables, 28+ credential file paths, AWS CLI profile enumeration, GCP token extraction, source file grep for credential patterns (150 files, 29 file types), OIDC token generation, and all three cloud IMDS endpoints. The credential pattern search explicitly targets AWS keys, Slack tokens, GitHub tokens, PyPI tokens, and npm tokens. Slack token inclusion is notable — it suggests the attacker expects active Slack workspace tokens to be accessible in developer and CI environments.

Phase 4 — Durable Access Harvested SSH keys, long-lived IAM credentials, and git tokens give the attacker repository and cloud access that persists beyond the initial compromise and survives a simple workflow revert.

There is a regex of the second-layer base64 regex confirms the credential pattern search explicitly targets AWS keys, Slack tokens, GitHub tokens, PyPI tokens, and npm tokens alongside generic secret patterns. Slack tokens are not commonly included in harvester tooling of this type — their presence suggests the attacker expects active Slack workspace tokens to be accessible in developer and CI environments.

Affected Scope

Exposure Analysis

GitHub code search on the payload prefix returned 3,500+ infected YAML files in public repositories. That number is expected to grow — the campaign is active and the attack toolchain is automated. Private repository exposure is harder to quantify from the outside, but the blast radius is larger: private repos are more likely to hold production secrets, cloud deployment credentials, and infrastructure access.

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

Real-World Impact: Confirmed Compromises

Tiledesk had multiple workflow files compromised in the same campaign. The attacker iterated through all files in .github/workflows/, not just the primary one. The per-repository device IDs confirm automated tooling generating unique per-target payloads at injection time.

Attack Scenarios

Scenario A — Repository with AWS deployment secrets: The attacker gets AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN from the printenv dump within seconds of the workflow running. Long-lived IAM user credentials expire when rotated, not on a schedule.

Scenario B — Runner with OIDC to AWS: ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN are exfiltrated. The attacker calls the OIDC endpoint directly and gets a short-lived AWS session token within the validity window, typically minutes. Rotating repository secrets alone does not close this. The OIDC trust configuration in AWS must be revoked and rebuilt from scratch.

Scenario C — GCP-connected runner: gcloud auth print-access-token returns an active GCP OAuth2 access token. Combined with the full GCP IMDS dump, the attacker has project-level API access across every service the service account was granted.

Scenario D — Package registry compromise: npm, PyPI, or Docker Hub tokens exfiltrated from ~/.npmrc, ~/.pypirc, or ~/.docker/config.json let the attacker publish under the organisation’s registry identity. A CI credential theft becomes a supply chain attack on everyone downstream.

Detection Guidance

Log Indicators

• GitHub Audit Log: commits to .github/workflows/ from ci-bot@automated.dev and build-system@noreply.dev
• Git log: commits dated September 17, 2001 in any workflow file path: git log --before="2002-01-01" -- .github/workflows/
• GitHub Actions run logs: jobs named “check” running base64 commands in run: steps
• Network egress logs: POST requests carrying X-Mega-DID, X-Mega-Plat, or X-Mega-File headers
• AWS CloudTrail / GCP Audit Log: credential use from unexpected IPs or user-agent strings containing curl following a CI run

IOC Table

Detection Queries

GitHub code search — find all infected workflow files across public repositories:

https://github.com/search?q=Q0I9Imh0dHA6Ly8yMTYu&type=code

This query searches for the base64 payload prefix and returns currently infected public YAML files. Run the same string grep locally across your own repositories:

grep -rn "Q0I9Imh0dHA6Ly8yMTYu" .github/workflows/

Find malicious commits by date (hardcoded fake date September 17, 2001):

git log --before="2002-01-01" -- .github/workflows/

GitHub Audit Log — workflow file modifications (gh CLI):

gh api /orgs/{org}/audit-log --paginate \

  -F phrase=”action:workflows.created OR action:workflows.updated” \

  | jq '.[] | select(.data.workflow_path | contains(".github/workflows"))'

Grep all workflow files in a repository for the malicious pattern:

grep -rn "base64 -d.*bash\|base64 -d | bash" .github/workflows/

Check for id-token: write permissions added to workflows:

grep -rn "id-token: write" .github/workflows/

Scanner References

• Phoenix Security — GitHub Actions workflow integrity scanner: monitors commits to .github/workflows/ for injection patterns and unexpected permission additions
• StepSecurity Harden-Runner: monitors runner process execution and network egress at job level — detects curl POST to unexpected external IPs
• Poutine (Boost Security): static analysis scanner for GitHub Actions workflow security misconfigurations including dangerous run: patterns
• GitHub Advanced Security — secret scanning does not detect this attack (no CVE, no package); workflow file monitoring via code scanning rules is required

Remediation Guidance

Immediate Actions

1. Audit all .github/workflows/ files across every repository. Search for base64 -d | bash in any run: step. Any match is a confirmed compromise.
2. For every repository where a workflow was modified: rotate all secrets accessible to runners — AWS access keys, GCP service account keys, SSH private keys, Docker Hub tokens, npm tokens, GitHub PATs stored as secrets.
3. Revoke and reissue all OIDC trust configurations (AWS IAM OIDC providers, GCP Workload Identity Federation, Azure federated credentials) connected to affected repositories. Rotating repository secrets alone is not sufficient.
4. Block outbound connections to 216.126.225.129 at network egress for all self-hosted runners.
5. Review the GitHub audit log for the past 30 days for unexpected OAuth application grants, new PAT authorisations with push scope, and GitHub App installations with contents: write.

Platform Responses

npm responded by invalidating granular access tokens with write access that bypass 2FA (npm statement, May 2026). This reduces account hijacking risk for npm registry tokens but does not address malicious workflow files already present in repositories or tokens exfiltrated before the revocation.

Structural Mitigations

• Enable required pull request reviews for all changes to .github/workflows/ using branch protection rules and CODEOWNERS with security team routing.
• Audit every workflow for id-token: write. This permission should only appear in workflows that explicitly document OIDC usage.
• Scope repository secrets to specific environments and workflows using GitHub Environments with deployment protection rules.
• Replace long-lived IAM user credentials in CI runners with OIDC wherever possible — but treat OIDC configurations as requiring rotation after any repository-level compromise.
• For self-hosted runners: restrict IMDS access using IMDSv2 hop limit reduction (set hop limit to 1).
• Pin GitHub Actions to commit SHAs rather than branch or tag references.

Remediation Ownership Plan

Phoenix Security Platform Recommendations

MEGALODON_CI has no CVE. Every traditional vulnerability scanner is blind to it. Detection requires controls at the workflow integrity and CI/CD posture layer — which is what Phoenix Security’s ASPM platform is built for.

Phoenix Security maps CI/CD workflow findings to the runtime assets they protect, identifies which runners hold credentials for live cloud workloads, and assigns remediation ownership to the teams responsible for each affected repository. A scattered incident becomes a tracked, owned backlog.

• Attack surface management: identify all repositories with active GitHub Actions workflows and surface those lacking workflow file protection controls
• Contextual deduplication: correlate runner compromise signals across repositories into a unified finding set, avoiding duplicate escalations to the same team
• Reachability analysis: identify which compromised runner secrets have reachable paths to production cloud workloads — prioritise rotation for runners with IAM roles attached to live environments
• Remediation campaigns: create a MEGALODON_CI campaign in Phoenix, assign workflow audit and secrets rotation tasks to owning teams, track verification status per repository
• Ownership attribution: map GitHub repositories to responsible engineering teams automatically — no manual triage of which team owns which repo workflow
• phxintel.security: Phoenix threat intelligence portal maintains the MEGALODON_CI IOC list including the C2 IP, device IDs, workflow signatures, and detection queries for SIEM integration

External References