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 between 18 May and 21 May 2026, exfiltrating CI/CD secrets, cloud credentials, OIDC tokens, and source-code secrets to an attacker-controlled command-and-control server in what security researchers are calling the largest GitHub Actions poisoning campaign ever recorded.

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 first publicly disclosed by SafeDep on 18 May 2026 after the firm's monitoring infrastructure detected an unusual surge of new GitHub Actions workflow commits across thousands of public repositories. Within hours, multiple independent security vendors — StepSecurity, OX Security, and Cybernews — confirmed the campaign's scope and shared 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.

The Hacker News confirmed 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 with significant production deployment in Europe and Latin America. The Tiledesk maintainer did not initially notice that their CI pipeline had been compromised, and unknowingly published 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) to the public npm registry between 19 and 21 May. Tiledesk has since pulled the affected versions and issued an advisory, but any organisation that pulled one of those versions during the three-day window is potentially compromised at the source-tree level.

GitHub responded with operational countermeasures on 19 May: removing the throwaway accounts, revoking any tokens observed in the exfiltration patterns, and applying additional rate limiting to new-account workflow commits. As of the time of writing, the campaign appears contained — but 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-21 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 Singapore Cyber Security Agency issued a directive to Critical Information Infrastructure owners on 5 May 2026 requiring cybersecurity reviews; Megalodon is exactly the kind of event that the CSA's directive anticipated. 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 (Tokopedia, GoTo, Bukalapak engineering teams) 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 — one of the largest in the world by per-capita developer count — 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:

  1. 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.

  2. 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_dispatch triggers added without corresponding maintainer activity. The StepSecurity blog includes specific YARA-style indicators.

  3. 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.

  4. 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.

  5. 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.

  6. 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. Multiple security vendors (StepSecurity, OX Security, SafeDep) have published free scanning tools specifically for the Megalodon indicators of compromise.

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? GitHub's response to the campaign was reasonable: account takedown, token revocation, and rate limiting on suspicious patterns. 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.

What is the connection between Megalodon and the Laravel-Lang attack? Both are May 2026 supply-chain attacks but the techniques differ. Megalodon targets the CI/CD pipeline through workflow file injection; the Laravel-Lang attack targets package distribution through malicious version-tag commits in forked repositories. They are likely operated by different threat actors, although the chronological proximity (within four days of each other) suggests a possible shared infrastructure or learning pattern. No formal attribution has been published as of 23 May 2026.

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.