Incident Overview

On 18 May 2026 a coordinated supply‑chain attack named Megalodon compromised more than five thousand public repositories hosted on GitHub. The adversary leveraged the platform’s automated CI/CD system to inject a malicious workflow file into each target repository. The change was made by a throwaway account with a randomized eight‑character username and an author email of [email protected], mimicking a legitimate automated bot. Because the injected workflow was designed to run only on a manual trigger, it remained dormant for the first two days of compromise, evading casual code review and CI monitoring.

Attack Vector

The payload was delivered as a single .github/workflows/ci.yml file. The file was configured to execute on every push and pull_request_target event, but the attacker also deployed a second variant that replaced an existing workflow with a workflow_dispatch trigger. This variant does not appear in the Actions tab until it is manually or programmatically activated, allowing the adversary to keep the backdoor hidden while still retaining full control.

Payload Mechanics

Upon execution the base64‑encoded bash script performs a multi‑phase credential harvest:

• Collects all environment variables exposed to GitHub Actions runners, including CI secrets and the runtime environment of PID 1.
• Extracts AWS credentials from configured profiles, GCP access tokens via gcloud auth print-access-token, and live credentials from metadata services of AWS, GCP, and Azure.
• Gathers SSH private keys, Docker authentication configs, .npmrc, .netrc, Kubernetes context files, Vault tokens, and Terraform credentials.
• Runs a grep scan against the entire source tree for patterns that match API keys, JWTs, database strings, PEM keys, and other cloud tokens.
• Requests an OIDC token from GitHub Actions with write permission, enabling direct impersonation of cloud identities.

All exfiltration traffic is routed to a single C2 server at hxxp://216[.]126[.]225[.]129:8443, which the attacker controls.

Impact on Tiledesk

One of the most visible impacts was on the open‑source live‑chat platform Tiledesk. The attacker replaced the legitimate Docker build workflow with the Optimize‑Build variant through commit acac5a9854650c4ae2883c4740bf87d34120c038. The maintainer, unaware of the poison, pushed several patched versions (2.18.6–2.18.12) to the npm registry. End users of @tiledesk/tiledesk-server therefore received a package that built from a backdoored workflow, exposing their cloud credentials to the adversary.

Indicators of Compromise (IoC)

Organizations should monitor for the following:

• C2 server hxxp://216[.]126[.]225[.]129:8443
• Author emails [email protected] and [email protected] on 18 May 2026
• New or modified files named .github/workflows/ci.yml or workflow_dispatch triggers in existing workflows
• Commits with message patterns such as ci: add build optimization step or chore: optimize pipeline runtime
• Unusual OIDC token requests originating from GitHub Actions runners

Mitigation Recommendations

To defend against this and similar supply‑chain attacks, security analysts should:

1. Audit all .github/workflows directories for unexpected changes and revert any malicious commits.
2. Rotate all secrets that are available to GitHub Actions runners, including API keys, cloud credentials, and SSH keys.
3. Enable workflow approval gates for pull requests that modify CI/CD configurations, especially from external contributors.
4. Pin actions and workflow references to specific commit SHAs rather than using mutable tags.
5. Monitor cloud logs for OIDC token requests that do not align with known workflows.
6. Use GitHub’s built‑in security features such as secret scanning and code scanning to detect hard‑coded credentials.
7. Implement a monitoring system that flags any workflow_dispatch events that trigger hidden or dormant workflows.

Conclusion

The Megalodon campaign demonstrates the importance of securing the CI/CD pipeline and the potential scale of a supply‑chain attack when automated workflows are abused. By applying the recommendations above, organizations can reduce the risk of credential theft, limit the damage from compromised repositories, and maintain the integrity of their open‑source ecosystems.