Megalodon campaign hit 5,500 GitHub repos with malicious CI/CD workflows

A large automated supply chain campaign called Megalodon injected malicious GitHub Actions workflows into more than 5,500 public repositories in less than seven hours, giving attackers a way to steal CI secrets, cloud credentials, SSH keys, and OIDC tokens from affected pipelines.

According to SafeDep’s Megalodon analysis, the campaign pushed 5,718 malicious commits to 5,561 repositories on May 18, 2026, between 11:36 and 17:48 UTC. The attacker used throwaway GitHub accounts and forged bot-like author names to make the commits look like routine CI maintenance.

The attack did not need to change application code. It targeted the build layer by adding or replacing workflow files inside .github/workflows, which can execute automatically when repositories run GitHub Actions jobs.

The campaign hid behind routine CI commit messages

Megalodon used commit author names such as build-bot, auto-ci, ci-bot, and pipeline-bot. Commit messages were designed to blend into normal developer activity, including phrases such as “ci: add build optimization step” and “chore: optimize pipeline runtime.”

StepSecurity’s technical breakdown said the attacker never had to touch application code because the pipeline itself was the target. Once a poisoned workflow ran, it could harvest credentials exposed to that CI job.

The campaign shows why CI/CD workflows now need the same level of review as source code. A single suspicious workflow change can expose secrets even when the main application files look clean.

Campaign detail	What researchers reported
Campaign name	Megalodon
Date	May 18, 2026
Time window	11:36 to 17:48 UTC
Malicious commits	5,718
Affected repositories	5,561
Main target	GitHub Actions workflow files

Two workflow variants were used

Researchers described two main Megalodon workflow variants. The mass variant used the name SysDiag and added a workflow that could trigger on push and pull request activity.

The second variant used the name Optimize-Build and relied on workflow_dispatch, which lets a workflow run manually. The Hacker News reported that this targeted variant sacrificed automatic reach for operational stealth because it could sit dormant until triggered.

Both patterns created a dangerous outcome for repository owners. If the malicious workflow ran inside a CI environment with secrets or cloud access, the attacker could steal data without changing the application itself.

Variant	How it worked	Why it mattered
SysDiag	Added a new workflow file that could run during normal repository activity	Maximized the chance of automatic execution
Optimize-Build	Used a manual workflow_dispatch trigger	Created a quieter backdoor that could activate later

The payload targeted cloud and developer secrets

The injected workflows carried base64-encoded shell payloads designed to drain secrets from CI runners. These payloads searched environment variables, process environments, cloud metadata endpoints, SSH directories, Docker configs, Kubernetes configs, Vault tokens, Terraform credentials, and source code.

Phoenix Security’s analysis described the campaign as a zero-CVE CI/CD workflow poisoning attack. The same report noted that there is no traditional software patch because remediation requires reverting workflow changes, revoking access, and rotating exposed secrets.

One of the highest-risk targets was GitHub Actions OIDC. OIDC can remove the need for long-lived cloud secrets, but a malicious workflow with the right permissions can still request a short-lived identity token and exchange it with a cloud provider.

• AWS access keys, secret keys, session tokens, and instance metadata credentials.
• GCP access tokens and cloud metadata credentials.
• Azure instance metadata credentials.
• GitHub Actions OIDC request tokens and request URLs.
• SSH private keys, Docker auth files, Kubernetes configs, and Vault tokens.
• npm, PyPI, GitLab, Bitbucket, and other package or source control tokens.
• API keys, JWTs, database connection strings, PEM keys, and other source code secrets.

Tiledesk was one of the notable downstream cases

The Tiledesk project became one of the more visible downstream cases. StepSecurity said nine Tiledesk repositories were confirmed as affected, and that @tiledesk/tiledesk-server versions 2.18.6 through 2.18.12 carried the poisoned workflow through npm distribution.

The key detail is that the application code did not need to contain a traditional backdoor. The workflow file created the risk because it could run during CI and access secrets from the build environment.

The Tiledesk GitHub repository describes tiledesk-server as the main API component of the open-source Tiledesk platform. That made the npm propagation important because downstream users may have installed affected versions without realizing the build workflow had been poisoned.

This was not a normal package-only compromise

Megalodon differs from many npm supply chain attacks because it attacked repositories and CI/CD workflows directly. A poisoned package usually relies on install scripts or runtime code. Megalodon instead used GitHub Actions as the execution surface.

That makes detection harder for teams that only scan application dependencies. A repository may pass dependency checks while still carrying a malicious workflow file that can run inside a privileged CI environment.

The Hacker News report also noted that the payloads targeted source code secrets, cloud credentials, and CI tokens, which raises the risk of follow-on compromises across cloud accounts and package registries.

Attack surface	Typical risk	Megalodon impact
Source code	Backdoors or malicious logic in application files	Application code may look untouched
Dependencies	Malicious package install or runtime behavior	Downstream npm packages may still carry poisoned build metadata
CI/CD workflows	Secret theft during automated builds	Primary execution path for credential harvesting
Cloud identity	Short-lived token theft or role impersonation	OIDC permissions increased cloud exposure risk

OIDC reduced long-lived secrets but did not remove risk

GitHub’s official OIDC guidance explains that workflows can use OpenID Connect to access cloud resources without storing long-lived GitHub secrets. That is still a strong security improvement when teams configure trust boundaries correctly.

However, OIDC does not protect a workflow after attackers control the workflow itself. A malicious job with id-token: write can request a token and attempt to exchange it with a trusted cloud provider, depending on the cloud-side policy conditions.

The safer setup requires strict subject conditions, environment protections, least-privilege roles, and limited workflow permissions. Without those controls, attackers can turn a poisoned workflow into a cloud identity theft path.

GitHub Actions hardening should start with workflow review

GitHub’s secure use reference recommends least privilege for workflow secrets and GITHUB_TOKEN permissions. It also advises teams to rotate exposed secrets and avoid storing sensitive data as plaintext inside workflow files.

Those recommendations apply directly to Megalodon-style attacks. If a workflow file receives an unexplained new run step, base64 payload, broad permissions block, or cloud identity permission, teams should review it before it ever runs.

GitHub also recommends keeping GITHUB_TOKEN permissions as narrow as possible. Repository owners should set read-only defaults and grant write or id-token permissions only to jobs that truly need them.

What repository owners should check now

Repository owners should search for Megalodon indicators in commits and workflow files. Any repository that received an unexpected CI workflow commit on May 18, 2026 should receive urgent review.

The SafeDep report lists SysDiag and Optimize-Build as key workflow names and describes forged bot-like commit identities used by the attacker. Teams should also search for suspicious base64-encoded run commands in workflow YAML files.

If a poisoned workflow ran, teams should assume secrets accessible to that runner may have been exposed. Removing the workflow alone does not invalidate stolen credentials.

• Search .github/workflows for SysDiag, Optimize-Build, and unfamiliar workflow_dispatch entries.
• Review commits from build-bot, auto-ci, ci-bot, pipeline-bot, or other unexpected bot-style authors.
• Look for base64-encoded shell commands inside workflow run steps.
• Revert malicious commits and compare workflows against a known clean branch.
• Check Actions logs for unexpected runs around May 18, 2026.
• Review cloud audit logs for unusual token exchanges or role assumptions.
• Rotate all secrets reachable by affected runners.

Key indicators reported by researchers

The campaign used infrastructure and identifiers that defenders can use for hunting. Teams should treat these indicators as leads, not as the only possible signs of compromise.

Phoenix Security also warned that traditional vulnerability scanners may miss this class of issue because no CVE exists and the malicious logic lives in workflow changes rather than a vulnerable dependency.

Security teams should combine indicator searches with workflow integrity monitoring, branch protection review, and cloud identity log analysis.

Indicator type	Indicator
Campaign name	Megalodon
C2 server	216.126.225.129:8443
Workflow name	SysDiag
Workflow name	Optimize-Build
Forged author names	build-bot, auto-ci, ci-bot, pipeline-bot
Sample affected npm package	@tiledesk/tiledesk-server 2.18.6 through 2.18.12
Sample commit	acac5a9854650c4ae2883c4740bf87d34120c038

How teams can reduce future CI/CD poisoning risk

Repository owners should require review for workflow file changes. Attackers know that developers often scan application code first and overlook CI YAML files, so workflow directories need stronger protection.

The GitHub Actions security guidance says workflows should use least privilege, mask sensitive data, and rotate exposed secrets. Teams should also prevent workflows from using broad default permissions unless a job needs them.

The GitHub OIDC documentation also recommends planning cloud trust conditions so untrusted repositories cannot request cloud access tokens. That cloud-side policy layer matters because a poisoned workflow may try to mint short-lived tokens.

• Protect .github/workflows with CODEOWNERS and required reviews.
• Pin third-party actions to commit SHAs instead of mutable tags where possible.
• Use least-privilege GITHUB_TOKEN permissions by default.
• Grant id-token: write only to jobs that truly need cloud federation.
• Constrain OIDC trust by repository, branch, workflow, and environment.
• Use protected environments and manual approvals for deployments.
• Monitor workflow file changes and unexpected workflow_dispatch executions.

Developer credentials remain a major supply chain risk

Follow-up reporting linked the campaign to compromised developer credentials and infostealer infections. That means repository owners should not focus only on GitHub settings. They also need endpoint hygiene for developers with repository access.

The Tiledesk repository example shows why open-source projects with npm publishing workflows face added exposure. If CI credentials, registry tokens, or cloud identities leak, one repository compromise can create downstream package risk.

Megalodon’s lesson is simple: CI/CD pipelines are now a primary supply chain target. Teams need to review workflow changes as carefully as source code, and they should treat any unexpected pipeline execution as a possible credential theft event.

FAQ