SAN FRANCISCO, 21 MAY 2026 — A coordinated supply-chain attack codenamed Megalodon backdoored 5,561 GitHub repositories in six hours through 5,718 malicious commits on 18 May 2026, exfiltrating CI/CD secrets, cloud credentials, OIDC tokens, and source-code secrets to an attacker-controlled command-and-control server in one of the largest GitHub Actions poisoning campaigns reported to date.
Key Takeaways
- 5,718 malicious commits pushed to 5,561 GitHub repositories in a single six-hour window using automation that disguised authorship as innocuous CI bots.
- The exfiltration target is the CI secret store — GitHub Actions secrets, environment variables, OIDC tokens, cloud-credential federation, SSH keys, and source-code embedded secrets.
- Two payload variants observed: a mass-spread "SysDiag" workflow added on every push/pull, and a targeted "Optimize-Build" variant that replaces existing workflows to create dormant backdoors firing only via attacker command.
- C2 traffic exfiltrated to 216.126.225.129:8443 — a single IP that defenders can immediately block.
- At least one downstream casualty: a maintainer unknowingly published seven backdoored versions of
@tiledesk/tiledesk-server(2.18.6 through 2.18.12) to npm between 19-21 May 2026 before the compromise was discovered.
The Facts
The Megalodon campaign was disclosed by SafeDep on 21 May 2026, which reported that all of the malicious commits were pushed on 18 May in a six-hour window. Other security firms, including StepSecurity, published their own analyses and technical indicators.
The campaign operated on a single guiding principle: GitHub Actions secrets are valuable, ubiquitous, and protected only by the assumption that workflow files are trustworthy. Once an attacker can add or modify a workflow file in a repository, the secrets stored against that repository — including federated cloud credentials, container registry tokens, npm publish tokens, and AWS/GCP/Azure OIDC connections — are within reach.
The attack mechanics worked as follows. The attacker used a large pool of throwaway GitHub accounts and forged commit authorship metadata (apparent authors included build-bot, auto-ci, ci-bot, and pipeline-bot) to push commits that appear at a casual glance to be routine automated commits. The commits add or modify GitHub Actions workflow files, injecting a base64-encoded bash payload triggered on subsequent CI runs. When the workflow executes, the payload exfiltrates the runtime environment — including all CI secrets exposed to the workflow — to the attacker's command-and-control server.
SafeDep's analysis identifies the C2 endpoint as IP address 216.126.225.129 on port 8443. Defenders should immediately block outbound connections to this address from CI infrastructure and audit logs for any historical connections to it.
The first concrete downstream impact is @tiledesk/tiledesk-server, an open-source customer service platform. Seven infected versions (2.18.6, 2.18.7, 2.18.8, 2.18.9, 2.18.10, 2.18.11, and 2.18.12) were published to the public npm registry between 19 and 21 May. The affected versions have since been removed from npm, but any organisation that installed one of them during that window should treat the installing environment as potentially compromised.
The underlying primitive (GitHub Actions secret exfiltration via injected workflows) remains generic, and the next campaign is a matter of when, not if.
Technical Deep-Dive
The Megalodon campaign exploited two structural properties of GitHub Actions: secret-availability scoping and workflow-trust assumptions.
GitHub Actions secrets are scoped at the repository (or organisation) level. Any workflow file in a repository can request any secret defined for that repository, with the secret value injected into the workflow runtime as an environment variable. This design is intentional — it makes workflows simple to author — but it also means that whoever can author a workflow file can access every secret. There is no per-workflow-file ACL on which secrets can be requested.
Workflow trust is the second weakness. GitHub assumes that any commit to the default branch (typically main) is trustworthy because the commit must pass code review through pull requests for protected repositories. But many public-facing open-source repositories — especially those with low maintenance activity — have no branch-protection rules, no required reviews, and no automated checks that flag suspicious workflow changes. Megalodon's primary target list was exactly this profile: forgotten or lightly-maintained public repositories where an unreviewed commit would not draw immediate attention.
The two payload variants describe two different operational goals.
SysDiag (mass variant) adds a new workflow file triggered by push and pull_request events. The workflow runs base64 -d | bash on a hard-coded payload that collects the GitHub Actions secret environment, the OIDC token (if cloud federation is configured), the local checked-out source tree, and a list of known cloud-credential file paths. The collected data is gzipped and exfiltrated to the C2 over an HTTPS POST. SysDiag maximises automated execution: the next time anyone — including the maintainer themselves — pushes to the repo or opens a pull request, the payload runs.
Optimize-Build (targeted variant) replaces an existing workflow with one that adds a workflow_dispatch trigger. This trigger lets the attacker fire the workflow on demand via the GitHub API, without needing a code push to occur. Optimize-Build creates a dormant backdoor: even if the repository becomes quiet for months, the attacker can fire the workflow whenever they choose, exfiltrating the current state of the secret store at that moment. Optimize-Build is the more dangerous variant because it persists longer and is harder to detect — the workflow file looks like a legitimate build workflow that simply has a manual-trigger option added.
The exfiltrated data is significant in volume and value. GitHub Actions secrets routinely include:
- AWS, GCP, Azure, and DigitalOcean access keys — direct cloud-resource access
- Docker Hub, GHCR, and Quay tokens — container registry write access
- npm, PyPI, Maven, and Crates.io publish tokens — package supply-chain entry points
- GitHub Personal Access Tokens — further repository access
- HashiCorp Vault credentials — secret-store master access
- SSH private keys — production-server access
- Database connection strings — direct data access
- API keys for third-party services — OpenAI, Stripe, Datadog, PagerDuty, Slack, and so on
The expected post-exploitation activity from Megalodon's haul has not yet fully played out. Of the 5,561 affected repositories, an unknown subset stored cloud credentials of meaningful production scope. The window between compromise (18 May) and broad credential rotation (still ongoing) is the window of maximum risk.
ASEAN Perspective
GitHub Actions adoption is concentrated in software-development-heavy economies and across enterprise CI/CD migration projects. Southeast Asia has both, and the Megalodon impact is distributed accordingly.
Singapore's technology sector is among the most GitHub Actions-heavy in the region, with active deployment across the financial-services tech industry, government digital services (GovTech), and the local startup ecosystem. The Cyber Security Agency of Singapore wrote to the boards of Critical Information Infrastructure owners on 5 May 2026, setting out expectations that include a review of cyber-risk posture in light of AI-enabled threats; Megalodon is the kind of event such a review should cover. Singapore-based banks and CII operators should treat any GitHub Actions audit findings from the past month as urgent.
Indonesia has the largest absolute developer population in ASEAN, with significant adoption of GitHub Actions across both the startup ecosystem and the broader enterprise IT sector. Indonesian organisations that maintain even one public-facing GitHub repository should validate that no Megalodon commits were merged during the campaign window. Indonesian fintech firms in particular should rotate any production AWS/GCP credentials that were stored in GitHub Actions secret stores between 17 May and 22 May.
Malaysia's enterprise developer community has been a steady adopter of GitHub-based CI/CD over the past three years. Malaysian banks and telcos that use GitHub Enterprise Cloud (not the on-premises Server variant) inherit the same exposure as public-cloud users. Malaysian DevSecOps teams should validate that branch-protection rules are enforced on all production repositories and that no workflow files were modified during the campaign window.
Vietnam's software-outsourcing sector is a high-risk target for follow-on attacks using credentials exfiltrated from Megalodon. Vietnamese outsourcing firms typically manage CI/CD secrets across many client tenancies; any compromise of a single Vietnamese outsourcer's GitHub organisation can cascade into client environments. Vietnamese CTOs should run an immediate audit.
Philippines and Thailand have smaller absolute GitHub Actions footprints but similar exposure profiles. The Thai fintech sector and Filipino BPO technology teams should treat the Megalodon advisory as an immediate-priority item.
A unifying point for the region: any ASEAN organisation that publishes packages to npm, PyPI, Docker Hub, or any other public registry should validate that no packages were published from a compromised CI pipeline between 17 and 22 May. The Tiledesk casualty is the first such impact; it will not be the last.
What Organisations Should Do
The detection and remediation playbook for Megalodon is concrete and time-sensitive:
-
Block outbound connections to 216.126.225.129:8443 from all CI infrastructure. This is the known C2. Network-level blocking should be in place by end of business today.
-
Audit GitHub Actions workflow files modified between 17 May and 22 May 2026. Specifically, look for new workflow files or modifications to existing workflows that include base64-encoded payloads, bash piping, or
workflow_dispatchtriggers added without corresponding maintainer activity. The SafeDep and StepSecurity write-ups list indicators of compromise. -
Rotate all GitHub Actions secrets in any affected repository. This includes cloud credentials, API tokens, registry tokens, and SSH keys. If you cannot determine whether a repository was affected, rotate. The cost of unnecessary rotation is hours; the cost of a missed rotation is enterprise compromise.
-
Enforce branch protection on all production repositories. Require pull-request review for changes to
.github/workflows/. Use CODEOWNERS to require security team review on workflow changes. These controls do not retrofit the past five days but prevent the next campaign. -
Adopt federated identity (OIDC) instead of long-lived secrets where possible. AWS, GCP, and Azure all support GitHub Actions OIDC federation that issues short-lived tokens per workflow run rather than storing long-lived access keys. Federated tokens are scoped, time-limited, and substantially reduce the blast radius of any future exfiltration.
-
Add secret-scanning to your CI pipeline. GitHub's native Secret Scanning is free for public repositories. For private repositories, GitHub Advanced Security or third-party tools (TruffleHog, GitGuardian, Gitleaks) cover the same surface. Detect-and-revoke is the last-line-of-defence when prevention fails.
RECATOOLS Verdict
We believe Megalodon is the inflection point at which the industry must accept that GitHub Actions secrets are no longer trustworthy for the most sensitive credentials in your environment.
The campaign is significant not for its sophistication — the technique is elementary — but for its automation. Five thousand five hundred repositories backdoored in six hours is a scale that no manual attacker could achieve. It implies a fully-automated pipeline: scanning public GitHub for low-protection repositories, generating throwaway author identities, queuing and pushing commits, and harvesting the results. Building that pipeline is no longer hard. The next attacker to do it will go faster and target more carefully.
The right response is to stop storing long-lived secrets in GitHub Actions where possible, and to treat any secret that must be stored as compromised by default. Federated identity (OIDC) is the architectural answer for cloud credentials. Short-lived, scoped tokens reduce the blast radius from "everything that secret can do, forever" to "what one specific workflow can do during one specific minute."
For the open-source maintainer community, our recommendation is harder. Many low-activity public repositories are casualties of the trust assumptions built into open source itself: anyone can fork, anyone can pull-request, and a quiet repository is also a low-attention repository. The Tiledesk pipeline poisoning is the first concrete demonstration of how this cascade plays out. We expect more such incidents over the next 90 days.
For ASEAN organisations, the immediate action is the credential rotation. The structural action is the OIDC migration. The cultural action is to stop treating CI/CD as plumbing that someone else's team owns — DevSecOps is now a board-level risk register item, and Megalodon is the case study.
Frequently Asked Questions
How do I know if any of my repositories were affected?
Search your .github/workflows/ directories for files added or modified between 17 May 2026 and 22 May 2026. Look for base64-encoded payloads, curl or wget to unfamiliar IPs, and workflow_dispatch triggers added to existing workflows. GitHub's audit log API can list all workflow file changes in a date range. Security firms including SafeDep and StepSecurity have published indicators of compromise for the campaign.
What secrets are most at risk if my repository was affected? Any secret that was accessible to GitHub Actions workflows in the affected repository between 17 May and 22 May 2026 should be considered compromised. This includes AWS/GCP/Azure access keys, package registry tokens, container registry credentials, SSH keys, database connection strings, and third-party API keys. Federated OIDC tokens are also exposed but are time-limited, so the blast radius is narrower.
Did GitHub do anything wrong here? We have not seen a detailed public account from GitHub of its response to the campaign. The deeper question is whether GitHub Actions' secret-availability model — where any workflow file can request any repository secret — is appropriate for the threat model in 2026. Several security researchers have argued for granular per-workflow-file ACLs on secret access. GitHub has not committed to that change.
Should I disable GitHub Actions in my organisation until this is fully understood? For most organisations, the answer is no — disabling CI/CD breaks routine development workflows and creates worse problems than the supply-chain risk. The correct response is to apply branch protection, enable secret scanning, migrate to OIDC where possible, and audit recent workflow changes. For organisations in highly regulated sectors (finance, healthcare, critical infrastructure), a temporary pause on automated deployments while audits complete may be justified — but a full Actions disable is rarely the right answer.
Correction, 18 October 2026: An earlier version said the malicious commits were pushed between 18 and 21 May and that SafeDep disclosed the campaign on 18 May; all commits landed on 18 May, and SafeDep's disclosure is dated 21 May. Unsupported statements about GitHub's and Tiledesk's responses, unnamed companies' adoption claims and an answer referring to a later incident have been removed.
View author profile → · Editorial policy
