Megalodon Backdoored 5,561 GitHub Repos in Six Hours to Loot CI/CD Secrets

The fastest supply-chain attacks no longer wait for a maintainer to make a mistake, because the attacker already holds the keys. Between roughly 11:36 and 17:48 UTC on May 18, 2026, a threat actor that researchers track as TeamPCP, and that Google Threat Intelligence Group labels UNC6780, pushed 5,718 malicious commits into 5,561 GitHub repositories inside a single six-hour window. The campaign, named Megalodon by the analysts who pulled it apart, was documented in detail by StepSecurity and then named in a formal advisory that CISA published on May 28, 2026.

Each commit dropped a GitHub Actions workflow file into the default branch of a public repository, and that workflow carried a base64-encoded bash payload designed to run the moment the next pipeline fired. The committer identities were forged to read like routine automation, with throwaway accounts presenting as build-bot, auto-ci, and pipeline-bot, so a glance at the commit history looked like ordinary CI housekeeping rather than an intrusion in progress. What made the campaign efficient instead of merely noisy was its targeting, because the actor did not spray commits at random but went after repositories whose maintainers had already been compromised by infostealer malware, weaponizing GitHub tokens harvested from stealer logs almost as quickly as those logs were collected.

StepSecurity found that more than a third of the affected repository usernames matched machines that were already infected by credential-stealing malware, which tells you the supply chain here began long before May 18 and ran straight out of the criminal infostealer economy and into GitHub. Reporting from SecurityWeek and The Hacker News placed Megalodon alongside the Nx Console extension compromise that breached GitHub internal repositories earlier in the month, and CISA named both in the same advisory, treating them as a connected wave of supply-chain abuse aimed squarely at CI/CD pipelines.

The detection and response gap

This campaign was built to slip past the assumptions that most monitoring programs still quietly rely on, and each of those assumptions maps to a control that never fired:

• Workflow files are executable code arriving through a normal git push. Teams scrutinize application code in pull requests yet wave through a new file under .github/workflows as configuration noise, so an injected workflow on the default branch lands without the review any other code change would draw.
• Stolen tokens defeat identity controls. Because the commits were authenticated with legitimate credentials lifted from infostealer logs, every push looked like the rightful owner working as usual, and access controls that trust a valid token had nothing to raise a hand about.
• Exfiltration hides inside the pipeline. A workflow that reads secrets and then phones home is hard to separate from a workflow that deploys to production, since both legitimately touch GitHub Actions secrets and reach out to cloud APIs over egress that is already allowed.
• The window was hours, not weeks. Thousands of repositories were hit before most maintainers had finished their morning coffee, which is far faster than any control built around periodic scanning or the occasional human review of commit histories.

Downstream exposure is the part that turns one bad morning into a quarter of cleanup, because any organization that consumed an affected repository inside its own pipeline after May 18 may have leaked cloud credentials, API keys, and signing material through a workflow file it never authored and never read.

Mapping the behavior to MITRE ATT&CK

Translating the Megalodon kill chain into ATT&CK turns a vague sense of dread into a concrete list of detections a blue team can build and then validate:

• T1195.002 Compromise Software Supply Chain: injecting workflow files into thousands of repositories that other projects pull in as dependencies.
• T1078 Valid Accounts: pushing commits with legitimate GitHub credentials harvested from infostealer logs rather than brute forcing a way in.
• T1059.004 Unix Shell and T1027 Obfuscated Files or Information: the base64-encoded bash payload decoding and executing inside the runner.
• T1552.001 Credentials In Files and T1528 Steal Application Access Token: sweeping GitHub Actions secrets, cloud tokens, and API keys that the workflow can reach.
• T1071.001 Web Protocols: shipping the stolen secrets back out over ordinary HTTPS so the exfiltration blends into normal CI traffic.

Operationalizing a response

If your organization runs GitHub Actions, or depends on public repositories that do, treat any workflow change after May 18, 2026 as suspect until a human has actually looked at it. A practical sequence keeps the cleanup from sprawling:

1. Audit every .github/workflows directory for files added or modified since May 18, paying particular attention to commits from unfamiliar accounts or any author resembling build-bot, auto-ci, or pipeline-bot.
2. Rotate the full set of CI/CD secrets for any repository that executed a workflow after that date, including GitHub Actions secrets, AWS, GCP, and Azure credentials, container registry and Kubernetes configs, SSH private keys, API keys, and database connection strings.
3. Review GitHub organization audit logs for unexpected commits, new OAuth app authorizations, and repository permission changes around the campaign window.
4. Pin actions to specific commit SHAs rather than mutable tags, and enable branch protection with required signed commits so an unauthorized push cannot quietly land a workflow on a default branch.
5. Hunt the second-order signal in runner egress by looking for workflow runs that read secrets and then open outbound connections the pipeline has no legitimate reason to make.

How BlueTeamAutomation closes the loop

Doing all of that by hand, across every repository and every secret, after the fact, is the slow and error-prone path that an attacker is counting on. BlueTeamAutomation runs the full blue-team workflow against this class of CI/CD supply-chain threat continuously and on hardware you control, so the detections already exist before the next six-hour window opens:

• BAS validation. BASzy emulates the Megalodon behavior end to end, an injected workflow that reads secrets and exfiltrates them over HTTPS, so you learn whether your controls fire while it is still a drill instead of an incident.
• EDR. On-device detection catches a CI runner spawning a shell to decode and execute a base64 payload, which is the local signal that fires even when the outbound traffic looks perfectly legitimate.
• SIEM correlation. GitHub audit events, runner process telemetry, and egress logs collapse into one timeline, so an injected workflow plus an anomalous secret read plus an unexpected outbound connection becomes a single correlated alert rather than three unrelated ones that nobody stitches together.
• SOAR response. Automated playbooks revoke and rotate the exposed secrets, disable the offending workflow, and open the incident within the minutes that actually decide how much a campaign like this ends up costing you.
• Compliance evidence. Every validation run, detection, and response action is captured as audit-ready evidence for SOC 2, ISO 27001, and the incident-response obligations your auditors and customers expect you to meet.

The uncomfortable lesson from Megalodon is that your CI/CD pipeline is now a primary target rather than background plumbing, and that an attacker holding stolen tokens can rewrite thousands of build configurations faster than any human team can read them. Continuous validation, local detection, and automated response are the only controls that operate on that timescale, and they are what separates catching a poisoned workflow on its first run from explaining to your customers why their secrets walked out through your pipeline.