5,561 GitHub repos got malicious CI/CD commits injected in 6 hours. The commits looked exactly like routine bot maintenance. Here is what happened and how to check if you were hit.
On May 18, a campaign researchers are calling Megalodon pushed malicious commits into 5,561 GitHub repositories in just under six hours. The attacker used throwaway accounts with forged identities like build-bot, auto-ci, and pipeline-bot to make everything look like normal automated maintenance. Most people who got hit probably did not look twice at the commits.
The malicious code was hidden inside GitHub Actions workflow files, base64-encoded so it would not immediately stand out during a review. The moment a repo owner merged one of these commits, the malware ran automatically inside their CI/CD pipeline and started pulling everything it could find. AWS credentials, GCP tokens, SSH keys, Kubernetes configs, Vault tokens, .env files, database strings, shell history. All of it sent to an external server.
The reason this is particularly serious is that CI/CD pipelines typically run with elevated access to production environments. Compromising a pipeline is not just one machine. It is every environment that pipeline has keys to.
This is the same group behind the GitHub breach earlier this week, TeamPCP. They are using tokens stolen from each environment to move into the next one, which is why the number of affected packages keeps growing.
If you maintain any public GitHub repositories, go check your recent commits and look for anything from accounts you do not recognize, especially ones with random usernames or generic bot names. Open your .github/workflows/ folder and look for recently modified files with base64 strings inside run blocks. The known attacker server is 216.126.225[.]129:8443, so any outbound connection to that address in your pipeline logs is a confirmation.
If a malicious workflow ran in your environment, rotate everything. AWS keys, GCP service accounts, SSH keys, GitHub tokens, and anything stored in your CI/CD variables. Assume it is all compromised and start fresh.
npm has also invalidated all granular write-access tokens that bypass 2FA as a direct response to this campaign. If you publish packages on npm, you will need to generate new tokens.