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.<\/p>\n
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.<\/p>\n
This is not a malware story. It is a change-management story wearing a malware costume.<\/p>\n
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.<\/p>\n
Confirmed (SafeDep research, reported by The Hacker News, May 22, 2026):<\/strong><\/p>\n Reported context (treat as adjacent, not single-actor):<\/strong><\/p>\n 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.<\/p>\n Inference (our recommendations, not SafeDep claims):<\/strong> 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.<\/p>\n The attack chain is uncomplicated, which is what makes it instructive.<\/p>\n 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 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 The two variants differ in trigger:<\/p>\n Note what the payload does not do: it does not run at Dependency scanning is necessary and insufficient. Megalodon is a reminder that A modern GitHub Actions runner is, in security terms, a Tier-0 asset. Think about what it routinely holds:<\/p>\n 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.<\/p>\n 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 Megalodon is what that gap looks like at scale.<\/p>\n 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.<\/p>\n The specific gaps that turn a push into a successful workflow execution:<\/p>\n Walk that list against your own org. The honest answer for most teams is that at least three of those apply.<\/p>\n For detection engineers and SOC managers, the IOCs from the SafeDep reporting give you a starting hunt. The behavioral indicators are more durable.<\/p>\n Indicators of compromise (from SafeDep, May 2026):<\/strong><\/p>\n Hunts that survive an IOC rotation:<\/strong><\/p>\n 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.<\/p>\n Defender recommendations, in priority order. None of these require new tooling for most orgs; they require configuration and a meeting.<\/p>\n 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.<\/p>\n 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.<\/p>\n Primary sources: The Hacker News, Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI\/CD Workflows<\/a> (May 22, 2026), citing SafeDep research.<\/p>\n\n
.github\/workflows\/<\/code> containing base64-encoded bash payloads.<\/li>\n216.126.225.129:8443<\/code>.<\/li>\nbuild-bot<\/code>, auto-ci<\/code>, ci-bot<\/code>, and pipeline-bot<\/code>.<\/li>\n\/proc<\/code> 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<\/code>, credentials.json<\/code>, service-account.json<\/code>, and roughly 30 secret regex classes.<\/li>\n<\/ul>\n\n
What Megalodon actually did<\/h2>\n
ci-bot<\/code> or build-bot<\/code>. 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\/<\/code>.<\/p>\n216.126.225.129:8443<\/code>.<\/p>\n\n
push<\/code> and pull_request<\/code>, which gives the attacker mass reach. Any subsequent activity on the repo runs the payload.<\/li>\nworkflow_dispatch<\/code> 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.<\/li>\n<\/ul>\nnpm install<\/code>. 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.<\/p>\n\n
.github\/workflows\/<\/code> is application code with production credentials attached, and most review processes treat it like configuration.<\/p>\n<\/blockquote>\nWhy implicit trust in CI\/CD makes this work<\/h2>\n
\n
GITHUB_TOKEN<\/code> scoped (by default, in many orgs) more broadly than the workflow strictly needs.<\/li>\nauth.py<\/code> will approve a 40-line YAML file because it is, well, just CI.<\/p>\nThe change-management and source-approval gap<\/h2>\n
\n
.github\/workflows\/**<\/code>.<\/li>\nci-bot<\/code> and assume the commit came from a known automation account. Git author fields are user-controlled metadata; they are not authentication.<\/li>\n.github\/workflows\/<\/code> is not on by default and most orgs do not turn it on.<\/li>\n<\/ul>\nDetection engineering<\/h2>\n
\n
216.126.225.129:8443<\/code><\/li>\nbuild-bot<\/code>, auto-ci<\/code>, ci-bot<\/code>, pipeline-bot<\/code><\/li>\n\n
.github\/workflows\/<\/code> authored by accounts created in the last 30 days. GitHub’s audit log surface plus repo commit metadata is enough.<\/li>\nbase64 -d<\/code>, base64 --decode<\/code>, or piped decode into bash, sh, or python. This is rare in legitimate workflows.<\/li>\nworkflow_dispatch<\/code> triggers, especially in repositories that historically only ran on push or PR.<\/li>\norg.add_member<\/code> events for accounts under 90 days old, particularly with random-looking usernames, followed within hours by pushes from those accounts.<\/li>\nx7k2qmpz<\/code>, author ci-bot<\/code>).<\/li>\n<\/ol>\nWhat we’d do this week<\/h2>\n
\n
.github\/workflows\/**<\/code><\/strong> 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.<\/li>\nGITHUB_TOKEN<\/code> default permissions to read<\/code><\/strong> 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.<\/li>\nsub<\/code> claim. If your role trusts repo:org\/*<\/code>, fix that this week.<\/li>\nci-bot<\/code> 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.<\/li>\n<\/ol>\n