Megalodon GitHub Attack Hits 5,561 Repositories with Malicious CI/CD Workflows
Megalodon did not need to poison application code to create supply-chain risk. It went after the machinery that builds, tests, signs, and ships that code.
Security researchers have disclosed a large automated GitHub campaign that pushed 5,718 malicious commits to 5,561 repositories within a six-hour window on May 18, 2026. The campaign, dubbed Megalodon by SafeDep, injected malicious GitHub Actions workflows carrying base64-encoded Bash payloads designed to harvest CI/CD secrets and cloud credentials at scale.
The campaign is a sharp reminder that modern supply-chain compromise is no longer limited to package registries. The build pipeline itself is now a primary target.
What Happened
According to SafeDep research reported by The Hacker News, Megalodon pushed 5,718 malicious commits across 5,561 distinct GitHub repositories between 11:36 a.m. and 5:48 p.m. UTC on May 18, 2026.
The attackers used throwaway GitHub accounts with random eight-character usernames and forged commit author identities such as build-bot, auto-ci, ci-bot, and pipeline-bot. The commit messages were designed to blend into normal repository maintenance, imitating routine CI updates rather than obvious malware drops.
The payloads were inserted into GitHub Actions workflow files. In affected repositories, the malicious workflows were built to execute inside CI/CD runners and exfiltrate sensitive data to a command-and-control server at 216.126.225[.]129:8443.
One impacted package identified in public reporting was @tiledesk/tiledesk-server, where the payload was bundled into a GitHub Actions workflow file rather than delivered through a normal install-time package script.
What the Payload Tried to Steal
The campaign was built for credential extraction, not vandalism. The malicious workflows targeted secrets that commonly exist in CI/CD runners, build environments, and deployment automation.
SafeDep reported that the payload attempted to collect CI environment variables, process environment data from /proc/*/environ, PID 1 environment values, AWS credentials, Google Cloud access tokens, cloud instance role credentials, SSH private keys, Docker and Kubernetes configuration files, Vault tokens, Terraform credentials, shell history, API keys, database connection strings, JWTs, PEM private keys, GitHub Actions OIDC token request URLs and tokens, GITHUB_TOKEN, GitLab CI/CD tokens, Bitbucket tokens, .env files, credentials.json, service-account.json, and other configuration files.
That list shows the real objective. Megalodon was not just looking for one secret. It was built to strip the runner environment and identify anything that could unlock cloud accounts, deployment infrastructure, source repositories, package publishing access, or downstream systems.
Two Payload Styles: Loud Reach and Quiet Control
Researchers observed two main payload variants.
The first, referred to as SysDiag, was a mass variant that added a workflow triggered on push and pull request events. That approach maximizes execution opportunities because ordinary repository activity can cause the malicious workflow to run.
The second, referred to as Optimize-Build, was more selective. It used the workflow_dispatch trigger, meaning the workflow would run only when manually invoked. That reduces automatic noise and may help the attacker preserve access until a repository becomes operationally useful.
The tradeoff is clear. Push-triggered workflows spread faster and run more often. Manually triggered workflows are quieter and better suited for targeted exploitation after initial repository compromise.
Why This Stands Out
Megalodon targeted the trust layer developers often review the least: CI/CD configuration.
Many code review processes focus on application logic, dependencies, and infrastructure-as-code changes. Workflow files may receive less scrutiny, especially when commits are dressed up as maintenance updates. But in GitHub Actions, workflow files can control what executes, which secrets are exposed, which permissions are granted, and whether the pipeline can mint short-lived cloud credentials through OIDC federation.
That makes a malicious workflow more dangerous than it may look. A single YAML change can convert a trusted build runner into a credential collection point.
The attacker’s use of forged author names such as build-bot and ci-bot is also operationally important. These identities exploit a human expectation: CI changes are supposed to look automated, repetitive, and boring. Megalodon hid in that expectation.
The OIDC Token Risk
One of the most serious elements of the campaign is its interest in GitHub Actions OIDC token material.
OIDC is widely used to reduce long-lived cloud secrets in CI/CD. Instead of storing static AWS, Azure, or Google Cloud keys inside GitHub, a workflow can request a short-lived identity token and exchange it for cloud credentials. Done properly, that is safer than hardcoded secrets.
But if a malicious workflow is allowed to run in the right repository, with the right permissions, against the right branch or environment, it may be able to request those short-lived tokens itself. In that scenario, the attacker does not need to steal a static cloud key. They can abuse the pipeline’s trusted identity path.
That is why Megalodon matters to cloud teams as much as application security teams. The blast radius depends on how tightly each repository’s OIDC trust policy is scoped.
Connection to the Broader TeamPCP and Shai-Hulud Activity
Public reporting places Megalodon in the wider context of recent supply-chain attacks associated with TeamPCP and Mini Shai-Hulud-style activity. Those campaigns have focused on compromising developer ecosystems, package maintainers, CI/CD environments, and automation tokens.
The pattern is increasingly clear: attackers are moving laterally through the software supply chain by stealing the credentials that connect package registries, source repositories, build systems, and cloud infrastructure.
In that model, one compromised token can become a repository commit. One malicious commit can become a poisoned workflow. One workflow execution can become cloud access. One cloud credential can become a broader intrusion.
Defender Takeaways
Security teams should immediately audit repositories for suspicious workflow changes on or around May 18, 2026, especially commits affecting .github/workflows/. Particular attention should be paid to commits from unfamiliar eight-character GitHub usernames, forged author identities such as build-bot, auto-ci, ci-bot, and pipeline-bot, and workflow files containing base64-encoded shell payloads.
Teams should also review workflow triggers. New or modified workflows using on: push, on: pull_request, or workflow_dispatch should be investigated if they appeared unexpectedly, especially where they include shell execution, network calls, environment dumping, metadata service access, or archive-and-upload behavior.
Secrets exposed to affected repositories should be treated as compromised. That includes cloud credentials, deployment keys, SSH keys, GitHub personal access tokens, registry tokens, Vault tokens, Terraform credentials, database credentials, and any tokens available to the runner during the malicious workflow’s execution window.
For cloud environments, defenders should review AWS CloudTrail, Google Cloud audit logs, Azure sign-in and activity logs, and identity federation events tied to GitHub Actions OIDC. Look for unusual token issuance, unexpected repository subjects, unfamiliar workflow names, abnormal IP addresses, and cloud API calls shortly after suspicious workflow executions.
Hardening Steps That Actually Matter
Organizations should restrict default GITHUB_TOKEN permissions to read-only unless write access is explicitly required. Workflows that need elevated permissions should declare them narrowly at the job level, not globally across the repository.
OIDC trust policies should be scoped tightly to specific repositories, branches, environments, and workflow contexts. Broad trust patterns that allow any branch or workflow in a repository to request cloud credentials create exactly the kind of opening Megalodon-style campaigns look for.
Protected branches should require review for changes under .github/workflows/. Security teams should consider CODEOWNERS rules for workflow files, mandatory approval for CI/CD changes, and alerts when workflows are added, renamed, or modified.
Self-hosted runners need extra scrutiny. If a malicious workflow ran on a persistent self-hosted runner, teams should assume the runner may have exposed local files, cached credentials, build artifacts, and network-accessible internal resources. Rebuilding affected runners from known-good images is safer than trying to surgically clean them.
Why This Is a Supply-Chain Warning Shot
Megalodon shows that attackers understand the developer stack as a connected system. Repositories, workflow files, package publishing tokens, cloud federation, and build runners are no longer separate risk categories. They are one attack path.
The campaign’s scale is what makes it stand out: 5,718 commits, 5,561 repositories, and roughly six hours of automated activity. That is not manual opportunism. That is pipeline-level industrialization.
For security leaders, the lesson is direct. CI/CD systems should be treated like production infrastructure because they often hold the keys to production infrastructure.
NeuraCyb's Assessment
Megalodon is dangerous because it attacks the quiet assumptions of software delivery. Developers trust workflow files to automate the build; attackers used them to automate credential theft. The priority now is not only removing malicious YAML. It is proving that exposed tokens were rotated, OIDC trust was tightened, runner environments were cleaned, and future workflow changes cannot pass as harmless CI maintenance without review.
References
SafeDep: Mass GitHub Repo Backdooring via CI Workflows
The Hacker News: Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows
GitHub Docs: Automatic token authentication in GitHub Actions
GitHub Docs: Security hardening deployments with OpenID Connect
