Topic starter
02/08/2026 11:34 am
TL;DR: A malware campaign called Megalodon is spreading through GitHub repositories via fake automated commits, with OXSecurity reporting 3,500+ infected YAML files and over 5,000 repositories allegedly affected, while the malware steals cloud and developer credentials from CI/CD pipelines. The attack shows that repository trust, commit provenance, and pipeline execution controls must be treated as identity controls, not just code hygiene.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Megalodon: New CI/CD Malware Spreads Across GitHub, Infecting ~5,000+ Repositories”.
By the numbers:
- 3,500+ repositories already carrying an infected YAML file show the campaign has moved beyond isolated compromise, according to OXSecurity.
- Over 5,000 GitHub repositories have allegedly been infected with CI/CD credential-stealing malware, according to OXSecurity.
Key questions
Q: What breaks when CI/CD pipelines can be modified by untrusted repository input?
A: When untrusted repository input can change pipeline logic, attackers can turn build automation into code execution.
Q: Why do CI/CD systems increase the impact of compromised credentials?
A: CI/CD systems often hold powerful secrets that can unlock source code, deployment pipelines, cloud environments, and internal services.
Q: What are the signs that a repository infection is becoming a supply chain issue?
A: Repeated workflow patterns, identical malicious YAML across many repositories, and bot-like commits that appear legitimate are strong warning signs.
Practitioner guidance
- Tighten workflow change approval Require separate approval for repository changes that modify CI/CD workflows, reusable actions, or bot-triggered automation paths.
- Reduce pipeline secret exposure Remove broad cloud keys and long-lived API tokens from build jobs, then limit each runner to the smallest credential set needed for the task.
- Inventory infected repositories Search repositories for suspicious YAML patterns, fake bot identities, and repeated workflow signatures that indicate the same malware family.
Bottom line: A fake commit can be enough to turn CI/CD into an execution and exfiltration channel when workflow trust is not separately governed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:48 pm
Commit provenance has become an identity control, not a code review detail. This campaign succeeds because the pipeline treats a merged commit as evidence of legitimacy, even when the commit was designed to impersonate automation. That assumption was tolerable when repository changes were mostly human-authored and slow. It fails when malicious code can masquerade as a bot and inherit execution trust immediately. Practitioners need to recognise that provenance now governs who or what is allowed to run, not just what gets merged.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams compare secret rotation with pipeline isolation when CI/CD is compromised?
A: Secret rotation is necessary after exposure, but it does not stop malware from reusing the same trust path if the pipeline still has broad privileges. Pipeline isolation changes where secrets can be read, which limits what the attacker can do next. In practice, rotation addresses the stolen material, while isolation addresses the mechanism that exposed it.
👉 Read our full editorial: GitHub CI/CD malware campaigns expose secrets governance gaps