A new software supply chain campaign known as Megalodon has poisoned thousands of GitHub repositories with malicious GitHub Actions workflows designed to steal secrets from CI/CD environments.
According to research from SafeDep, the automated campaign unfolded on May 18 during a six-hour window. In that short period, the threat actor pushed 5,718 malicious commits to 5,561 GitHub repositories.
The campaign targeted one of the most sensitive areas of modern software delivery: the CI/CD pipeline. By modifying GitHub Actions workflows, attackers attempted to harvest credentials, cloud secrets, SSH keys, OpenID Connect tokens, and source code secrets from affected repositories.
This is another major reminder that the software supply chain is now one of the most valuable targets for cybercriminals.
What Happened?
The Megalodon campaign used dummy accounts and forged author identities to inject malicious GitHub Actions workflows into repositories.
These workflows were designed to execute inside GitHub Actions environments and exfiltrate sensitive data to an attacker-controlled command-and-control server.
The stolen data could include:
- CI/CD secrets
- cloud credentials
- SSH keys
- OpenID Connect tokens
- repository secrets
- source code secrets
- deployment credentials
This type of attack is especially dangerous because CI/CD environments often have privileged access to cloud infrastructure, package registries, production deployments, and internal systems.
If attackers steal those secrets, they may be able to move far beyond the original repository.
Two Payloads: Loud Infection and Stealth Backdoor
SafeDep described Megalodon as having two different payload styles.
The first payload added a malicious YAML workflow file called SysDiag. This workflow was triggered whenever a push or pull request occurred, allowing the malicious code to run as part of normal repository activity.
The second payload was more targeted and stealthy. Instead of adding an obvious new workflow, it replaced existing workflows with a workflow_dispatch trigger.
This matters because workflow_dispatch workflows do not automatically run. They remain dormant until manually triggered, including through the GitHub API.
That makes the backdoor harder to spot.
There may be no failed build, no visible CI error, and no obvious suspicious workflow run in the Actions tab until the attacker decides to activate it.
Why GitHub Actions Are a High-Value Target
GitHub Actions are deeply integrated into software development. They build code, run tests, publish packages, deploy applications, rotate infrastructure, and interact with cloud platforms.
That means workflows often have access to powerful secrets.
A compromised workflow can become a direct path to:
- cloud accounts
- production deployment systems
- package publishing tokens
- private repositories
- container registries
- infrastructure-as-code pipelines
- internal APIs
- developer credentials
For attackers, compromising GitHub Actions can be more valuable than compromising a single endpoint. It gives them access to automation trusted by the organization.
Tiledesk Repositories Were Backdoored
SafeDep first detected Megalodon after its Malysis engine identified suspicious activity in a bundled GitHub Actions workflow file for the npm package @tiledesk/tiledesk-server@2.18.12, part of the open-source chatbot platform Tiledesk.
Further investigation found that nine Tiledesk repositories were backdoored.
The maintainers unknowingly published poisoned code to downstream users, which helped spread the infection.
This is one of the defining risks of software supply chain attacks. A trusted open-source project can accidentally become a distribution path for malicious code.
The maintainers may not be malicious. The users may not be careless. But once the repository is poisoned, downstream consumers can still be exposed.
Why the Campaign Was So Fast
The campaign lasted only around six hours, but it spread widely during that time.
Researchers have not confirmed exactly why the campaign stopped. One hypothesis is that the attackers used a fixed list of valid credentials obtained from earlier supply chain attacks against developers.
If true, the attackers may have simply burned through their available credential list during the attack window.
This would fit a broader trend: attackers are chaining supply chain incidents together. Credentials stolen in one campaign can become the fuel for the next campaign.
Many Repositories Remained Infected
Additional research from OX Security found that thousands of repositories were still carrying the malicious YAML file after the attack window closed.
Even if the attacker’s initial push activity stopped, poisoned repositories can remain dangerous until they are cleaned.
That is an important point for defenders.
A supply chain attack does not end when the campaign stops. It ends only when affected repositories are identified, cleaned, secrets are rotated, and downstream users are informed.
If malicious workflows remain in repositories, they may still be triggered later.
Possible Link to TeamPCP Remains Unconfirmed
Megalodon appeared around the same period as other major supply chain attacks linked to the emerging threat group TeamPCP.
Some similarities have been noted, including fake bot identities and unusual hardcoded commit dates. However, researchers have not confirmed a direct link between Megalodon and TeamPCP.
There are currently no strong technical indicators, public claims, or shared infrastructure tying the two together.
The more cautious assessment is that Megalodon may be part of the same broader ecosystem of supply chain-focused cybercrime, but attribution remains unconfirmed.
It is also possible that different groups are sharing access, credentials, or tactics.
Why This Matters for the Software Supply Chain
Megalodon shows how quickly attackers can compromise software delivery systems when they obtain repository access.
The campaign did not need to exploit a complex zero-day vulnerability in GitHub itself. Instead, it appears to have abused repository access, workflow modification, and trusted automation.
That makes the attack practical and scalable.
Modern software supply chain security must account for:
- stolen developer credentials
- poisoned workflows
- malicious commits
- forged author identities
- compromised maintainers
- infected package releases
- downstream dependency spread
- dormant CI/CD backdoors
- secret exfiltration from automation environments
The repository is no longer just where code lives. It is where automation, credentials, infrastructure, and deployment trust intersect.
What Organizations Should Do Now
Organizations should audit GitHub repositories for signs of Megalodon-style compromise.
Recommended actions include:
- search all repositories for unexpected GitHub Actions YAML files
- look for workflow files named SysDiag
- review recent commits from unknown or suspicious identities
- check for forged author names and unusual commit metadata
- inspect workflows using
workflow_dispatchunexpectedly - review workflows that were recently modified without clear approval
- block outbound connections to known Megalodon command-and-control infrastructure
- examine recent GitHub Actions logs for secret access or exfiltration behavior
- revoke and rotate all potentially exposed CI/CD secrets
- rotate SSH keys, API keys, cloud keys, and deployment tokens
- review OpenID Connect trust relationships
- check package publishing history for unauthorized releases
- notify downstream users if poisoned packages may have been published
If suspicious workflow activity is found, assume secrets available to that workflow may have been exposed.
GitHub Actions Hardening Recommendations
To reduce risk from similar attacks, security teams should strengthen GitHub Actions governance.
1. Restrict workflow permissions
Use least privilege for GITHUB_TOKEN permissions. Do not allow broad write access unless required.
2. Require review for workflow changes
Changes to .github/workflows/ should require code owner review and stronger approval controls.
3. Monitor for new or modified workflows
Alert when new workflow files are added or when existing workflows are changed.
4. Limit the exposure
Only expose secrets to workflows that truly need them. Avoid making sensitive secrets available to pull request workflows.
5. Use environmental protection rules
Require approvals before workflows can access production deployment secrets.
6. Review OIDC trust policies
Ensure cloud roles using GitHub OIDC are tightly scoped to specific repositories, branches, and workflows.
7. Audit dormant workflows
Review workflow_dispatch workflows and confirm they are expected, documented, and approved.
8. Detect suspicious outbound activity
CI/CD runners should be monitored for unexpected outbound connections, especially to unknown domains or IP addresses.
The Bigger Pattern: CI/CD Is the New Attack Surface
Megalodon is part of a larger wave of attacks targeting developer infrastructure, package ecosystems, and automation pipelines.
Threat actors are increasingly targeting:
- GitHub repositories
- GitHub Actions
- npm packages
- developer credentials
- open-source maintainers
- package publishing workflows
- CI/CD secrets
- cloud deployment pipelines
The reason is simple: CI/CD systems often contain the keys to the kingdom.
If attackers compromise a build pipeline, they may be able to steal secrets, publish malicious packages, deploy backdoors, or access production systems.
Final Thoughts
The Megalodon campaign shows how fast a software supply chain attack can spread when attackers gain access to repositories and CI/CD workflows.
In just six hours, thousands of repositories were poisoned with malicious commits. Some workflows were designed to run immediately, while others acted as dormant backdoors waiting for activation.
GitHub Actions workflows must be treated as sensitive infrastructure, not simple automation scripts.
Organizations should audit repositories, monitor workflow changes, restrict permissions, rotate exposed secrets, and enforce strong controls around CI/CD automation.
The modern software supply chain is only as secure as the workflows that build and deploy it.
