Notifications
Clear all
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.
NHIMG editorial — based on content published by OXSecurity: Breaking News: The TeamPCP breach of GitHub was just the opening act
By the numbers:
- Over 5,000 GitHub repositories have allegedly been infected with CI/CD credential-stealing malware.
- Our analysis confirms 3,500+ repositories already carrying an infected YAML file.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams stop malicious CI/CD workflow commits from executing?
A: Protect workflow files with mandatory review, branch protection, and commit provenance checks before they can run in production pipelines.
Q: Why do CI/CD pipelines make secret theft easier for attackers?
A: Pipelines often concentrate cloud keys, package tokens, environment variables, and deployment credentials in one execution path.
Q: How should security teams reduce risk from compromised GitHub Actions workflows?
A: Security teams should treat workflows as privileged non-human identities.
Practitioner guidance
- Enforce provenance checks on workflow changes Require signed commits, protected branches, and explicit review for any change that touches GitHub Actions or other CI/CD workflow files.
- Reduce standing secret exposure in pipelines Move away from long-lived credentials in build jobs and limit AWS keys, GitHub tokens, and other secrets to the smallest possible execution scope.
- Audit repositories for malicious YAML and bot-like commits Search for unexpected workflow edits, repeated hardcoded bot identities, and the infected YAML patterns described in the article across all active repositories.
What's in the full analysis
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact infected YAML patterns and encoded payload markers used to identify compromised repositories.
- The command sequence the malware uses to enumerate AWS profiles and harvest local secret material.
- The named C2 endpoint and immediate containment steps described by the vendor.
- The repository search approach for finding affected projects at scale.
👉 Read OXSecurity's analysis of the Megalodon GitHub CI/CD malware campaign →
GitHub CI/CD malware and fake commits: are your controls keeping up?
Explore further
02/08/2026 12:48 pm
Commit provenance is now an identity control, not a developer convenience. When a repository accepts a workflow change from an apparently automated source, it is making an identity decision about what code may execute and who may inherit that trust. The attacker does not need to break the pipeline if the pipeline already trusts the commit path. Practitioners should treat repository provenance as part of identity governance, not as a separate DevOps concern.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
A question worth separating out:
Q: Which controls matter most when protecting CI/CD credentials?
A: The most effective controls are least privilege by pipeline stage, pre-commit and CI scanning, immutable pinning of third-party actions, and short-lived credentials issued at runtime. Together they reduce exposure, limit lateral use, and make stolen pipeline secrets far less useful.
👉 Read our full editorial: GitHub CI/CD malware campaigns expose secrets governance gaps
