Megalodon and the CI/CD trust problem

On May 18, 2026, between roughly 11:36 and 17:48 UTC, an automated campaign that SafeDep has named Megalodon pushed malicious GitHub Actions workflows into more than 5,500 repositories. The attackers did not exploit a vulnerability in GitHub. They did not need a zero-day in Node, Python, or any package manager. They used valid credentials (compromised PATs and deploy keys, per SafeDep) and a forged author identity that looked like a CI bot, and they pushed workflow files that read like routine pipeline maintenance.

Six hours. 5,718 commits. 5,561 distinct repositories. The payload only does its work after the commit lands and a workflow runs inside a CI runner, which means the credential theft happens with the full trust envelope of your pipeline: cloud OIDC tokens, GITHUB_TOKEN, organization secrets, runner environment variables, and whatever else your build process touches.

This is not a malware story. It is a change-management story wearing a malware costume.

What is confirmed vs what we recommend

Threat intel is more useful when the source layer is explicit. Here is what we are treating as load-bearing fact, and what we are flagging as defender judgment.

Confirmed (SafeDep research, reported by The Hacker News, May 22, 2026):

• Campaign tracked as Megalodon by SafeDep.
• 5,718 malicious commits across 5,561 distinct repositories.
• Activity window approximately 11:36 to 17:48 UTC on May 18, 2026.
• Mechanism: injected files under .github/workflows/ containing base64-encoded bash payloads.
• Command and control endpoint reported as 216.126.225.129:8443.
• Throwaway GitHub accounts with random 8-character usernames; forged git author identities including build-bot, auto-ci, ci-bot, and pipeline-bot.
• Commit messages mimicked routine CI maintenance, with seven message variants observed.
• Push vector assessed as compromised personal access tokens or deploy keys.
• Two payload variants: SysDiag (triggers on push and pull_request) and Optimize-Build (workflow_dispatch only; example observed in @tiledesk/tiledesk-server).
• Harvest scope per SafeDep includes CI env vars, /proc environ, AWS IMDSv2, GCP and Azure instance metadata, SSH keys, Docker and Kubernetes configs, Vault, Terraform state, shell history, GITHUB_TOKEN, GitHub Actions OIDC, GitLab and Bitbucket tokens, .env, credentials.json, service-account.json, and roughly 30 secret regex classes.

Reported context (treat as adjacent, not single-actor):

• OX Security commentary in The Hacker News piece framing developer tooling as a rising target.
• npm credential resets and 2FA bypass remediation (reported by Socket) in the same window.
• TeamPCP activity, including the GitHub internal repository disclosure and VS Code extension exfiltration, in the same May 2026 timeframe.

These three threads are not the same operator unless an IR vendor names them as such. They are the same era. Megalodon is SafeDep’s naming for the GitHub Actions campaign; TeamPCP is separate tracked activity. The shared pattern is the part defenders should internalize: developer trust surfaces (IDE extensions, package registries, CI pipelines) are being attacked as a class, not as isolated incidents.

Inference (our recommendations, not SafeDep claims): the organizational failures that let a workflow-file commit reach a default branch without a human looking at it. Change management, code review on pipeline paths, branch protection, and bot-identity skepticism. We will be explicit about which sections below are defender guidance.

What Megalodon actually did

The attack chain is uncomplicated, which is what makes it instructive.

An attacker, using a credential they already had (PAT or deploy key), pushed a commit to a repository under a freshly minted GitHub account with a random username. The commit author was set to a name like ci-bot or build-bot. The commit message was something that would not raise an eyebrow in a notification email, the SafeDep reporting describes seven variants of pipeline-maintenance phrasing. The commit added or modified a file under .github/workflows/.

That workflow contained a step that decoded a base64 blob and piped it to bash. The decoded bash then ran the harvest: walk environment variables, query cloud instance metadata services, read common credential files, scrape Terraform and Vault and Kubernetes config locations, request the OIDC token, exfiltrate to 216.126.225.129:8443.

The two variants differ in trigger:

• SysDiag registers on push and pull_request, which gives the attacker mass reach. Any subsequent activity on the repo runs the payload.
• Optimize-Build registers on workflow_dispatch only. This is quieter. The workflow sits dormant until someone (the attacker, with the same credential, or a maintainer who notices a new workflow and clicks Run to see what it does) triggers it manually. The @tiledesk/tiledesk-server case in SafeDep’s reporting is this pattern.

Note what the payload does not do: it does not run at npm install. It does not require a downstream consumer to fetch a poisoned package. It runs inside the CI runner of the repository that received the commit, against the secrets and tokens available to that runner. The blast radius is whatever the runner can reach. For most organizations, that is more than the application code.

Dependency scanning is necessary and insufficient. Megalodon is a reminder that .github/workflows/ is application code with production credentials attached, and most review processes treat it like configuration.

Why implicit trust in CI/CD makes this work

A modern GitHub Actions runner is, in security terms, a Tier-0 asset. Think about what it routinely holds:

• A GITHUB_TOKEN scoped (by default, in many orgs) more broadly than the workflow strictly needs.
• An OIDC token that can assume IAM roles in AWS, GCP, or Azure without a long-lived secret in the repo.
• Repository and organization secrets injected as environment variables.
• Deploy keys, registry credentials (Docker Hub, GHCR, ECR), and signing keys.
• Whatever the build process pulls down (Terraform state, kubeconfig, Vault tokens).

If a workflow file you did not write runs on that runner, all of the above is reachable. The attacker does not need persistence; one execution is enough to drain credentials and pivot.

The mental model most teams operate under is that CI/CD is plumbing. Pipelines are configured once, owned by platform engineering, and rarely reviewed line by line. New workflows get added during refactors, feature flags, release automation changes. Reviewers skim them. The same reviewer who would block a suspicious change to auth.py will approve a 40-line YAML file because it is, well, just CI.

Megalodon is what that gap looks like at scale.

The change-management and source-approval gap

This section is defender judgment, not SafeDep’s claim. The campaign exploited credential compromise to get a commit pushed. The reason a commit was sufficient (rather than just a step on the path) is that nothing else caught it.

The specific gaps that turn a push into a successful workflow execution:

• No required review on workflow paths. Most branch protection rules require review on default branch, but do not require a different (or any) reviewer for .github/workflows/**.
• Forged bot identities exploit pattern recognition. Reviewers see an author named ci-bot and assume the commit came from a known automation account. Git author fields are user-controlled metadata; they are not authentication.
• Auto-merge configured on labeled PRs. A bot that can push and label can merge itself, in many orgs.
• PAT and deploy key reuse across repositories. One stolen token grants write access to dozens of repos.
• No separation between push rights and pipeline-modification rights. If you can push code, you can add an exfiltration workflow. CODEOWNERS for .github/workflows/ is not on by default and most orgs do not turn it on.

Walk that list against your own org. The honest answer for most teams is that at least three of those apply.

Detection engineering

For detection engineers and SOC managers, the IOCs from the SafeDep reporting give you a starting hunt. The behavioral indicators are more durable.

Indicators of compromise (from SafeDep, May 2026):

• C2: 216.126.225.129:8443
• Forged author names: build-bot, auto-ci, ci-bot, pipeline-bot
• New workflow files containing base64-decoded bash in run steps
• SysDiag and Optimize-Build workflow names (treat as soft indicators; trivially renamed)

Hunts that survive an IOC rotation:

1. New or modified files under .github/workflows/ authored by accounts created in the last 30 days. GitHub’s audit log surface plus repo commit metadata is enough.
2. Workflow run steps where the command contains base64 -d, base64 --decode, or piped decode into bash, sh, or python. This is rare in legitimate workflows.
3. Egress from runners to IP addresses not on an allowlist of registries, package mirrors, and known internal hosts. If you do not constrain runner egress, this hunt is hard; that is itself a finding.
4. Sudden additions of workflow_dispatch triggers, especially in repositories that historically only ran on push or PR.
5. GitHub organization audit log: org.add_member events for accounts under 90 days old, particularly with random-looking usernames, followed within hours by pushes from those accounts.
6. PAT and deploy key usage from IP geographies or ASNs inconsistent with your developer population.
7. Commits where the GitHub account identity and the git author identity diverge significantly (account x7k2qmpz, author ci-bot).

If you run a SIEM with GitHub audit log ingestion, the last three are queries you can write today. If you do not, the first project for next quarter is getting that log source in.

What we’d do this week

Defender recommendations, in priority order. None of these require new tooling for most orgs; they require configuration and a meeting.

1. Add CODEOWNERS for .github/workflows/** and require review from a security or platform engineering reviewer for any change to that path. Make workflow modifications a different approval surface than application code.
2. Set GITHUB_TOKEN default permissions to read at the organization level. Workflows that need write must opt in per-job. This is one toggle in org settings and it removes most of the post-merge blast radius.
3. Inventory and rotate PATs and deploy keys with any chance of exposure during the May 2026 window. Scope new tokens to specific repositories, not org-wide. Set expirations.
4. Narrow OIDC cloud trust policies. The IAM role your CI assumes should be scoped to specific repositories and specific branches via the sub claim. If your role trusts repo:org/*, fix that this week.
5. Branch protection on default branch: required reviews, no direct push, no force-push, no bypass for admins unless logged and reviewed.
6. Alert on new external collaborators and on first-time pushes from accounts younger than 90 days. Both are cheap signals.
7. Tabletop the merge-approval failure. Walk through: what happens if a commit authored by ci-bot modifies a workflow file and an auto-merge bot approves it on green CI. Who catches it, when, and how. If the answer is nobody, that is the next thing to fix.

This is general guidance, not legal or audit advice. Talk to your auditor about how workflow review maps to your SOC 2, ISO 27001, or PCI change-management controls; in most frameworks, pipeline files fall under change management whether your current process treats them that way or not.

Megalodon is not the last campaign that will treat CI/CD as the soft middle of the supply chain. The pipeline is application code. Review it that way.

Primary sources: The Hacker News, Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows (May 22, 2026), citing SafeDep research.

Nomad Security publishes practitioner threat analysis and helps teams assess developer-trust and pipeline risk through threat research and scoped security assessments.