Megalodon Campaign Poisons Over 5,500 GitHub Repositories in Massive CI/CD Attack
Table of Contents
A New Wave of Supply Chain Sabotage
GitHub is currently grappling with the aftermath of a massive, automated malware campaign dubbed “Megalodon,” which has successfully poisoned more than 5,500 repositories. The attack focuses on the critical plumbing of modern software development: the Continuous Integration and Continuous Deployment (CI/CD) pipelines. By inserting malicious commits into these pipelines, attackers are able to siphon off high-value secrets and cloud access tokens without ever needing to compromise a developer’s primary account credentials.
Researchers at SafeDep first uncovered the campaign after identifying predatory commits designed to steal credentials. The scale of the operation is significant—5,561 repositories have been infected so far. This follows a similar pattern to the earlier TeamPCP attacks, which compromised roughly 3,800 repositories, suggesting a growing trend of automated “poisoning” where the target is not the software itself, but the environment used to build it.
How Megalodon Operates
The technical execution of Megalodon is deceptively simple but devastatingly effective. The attacker pushes a malicious commit to a repository; if a repository owner merges that commit, the malware triggers automatically within the CI/CD pipeline. Because these pipelines often have elevated permissions to deploy code to production environments, the malware gains access to a goldmine of sensitive data.
According to Moshe Siman Tov Bustan, lead researcher at Ox Security, the malware is specifically designed to hunt for AWS secret keys, Google Cloud access tokens, and Azure metadata. It doesn’t stop at cloud keys; it also scans for SSH private keys, Kubernetes configurations, Vault tokens, and Terraform credentials. The script employs over 30 different regex patterns to scrub source code for any remaining secrets, which are then exfiltrated to the attacker’s server.
Essentially, if a repository is touched by Megalodon and the commit is merged, every CI/CD variable associated with that project should be considered compromised.
The Tiledesk Breach and the ‘Build-Bot’ Cloak
One of the most prominent examples of the attack’s reach is Tiledesk, an open-source live chat and chatbot platform. SafeDep found that the attacker backdoored Tiledesk versions 2.18.6 through 2.18.12. In a sophisticated twist, the attacker did not compromise the npm account of the maintainer. Instead, they poisoned the GitHub repository directly. The maintainer, believing they were publishing a legitimate update, unknowingly pushed the compromised code to the npm registry.
To avoid detection, the attacker used a facade of automation. The malicious commits were attributed to a user named “build-bot,” using the email address build-system[@]noreply.dev, with commit messages such as “ci: add build optimization step.” This mimicry of standard CI bot behavior allowed the commits to blend into the noise of a busy repository. Evidence suggests the attacker used a compromised Personal Access Token (PAT) or deploy key to push directly to the master branch, bypassing the usual pull request (PR) review process.
A Pattern of Imitation
While the tactics mirror those of the TeamPCP crew—who previously targeted the Trivy and Checkmarx ecosystems—security experts believe Megalodon is a different entity entirely. Bustan notes that while the style is similar, the underlying code is distinct. Furthermore, Megalodon appears to be ignoring a “supply-chain attack competition” currently hosted on BreachForums by TeamPCP, as it fails to include the specific encryption keys required for contest entries.
The incident highlights a systemic vulnerability in how developers trust automated commits and the inherent risks of long-lived deploy keys. While npm has attempted to mitigate similar risks by invalidating certain granular access tokens that bypass two-factor authentication (2FA), experts argue this is a superficial fix. The root problem remains: malicious code is reaching production servers because the verification process for the source of that code is fundamentally broken.
