Notifications
Clear all
Topic starter
18/08/2026 2:52 pm
TL;DR: Megalodon injected malicious GitHub Actions workflows into 5,561 public repositories in six hours, stealing cloud credentials, SSH keys, API tokens, and OIDC tokens by abusing weak branch protection and pipeline trust, according to StepSecurity. The campaign shows that CI pipelines are identity infrastructure, and standing workflow privilege is now a material secret-exfiltration risk.
NHIMG editorial — based on content published by StepSecurity: Megalodon Threat Intel on mass GitHub Actions secret exfiltration across 5,500+ public repositories
By the numbers:
- The campaign touched 5,561 repositories across GitHub in a single six-hour window.
Questions worth separating out
Q: What fails when GitHub Actions workflows can be modified to run attacker-controlled code?
A: The failure is trust in the workflow file as a safe automation boundary.
Q: Why do CI/CD pipelines create non-human identity risk?
A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically.
Q: What do security teams get wrong about short-lived OIDC tokens in CI/CD?
A: They often assume short-lived tokens are safe by default.
Practitioner guidance
- Lock down workflow file changes Require mandatory review for every modification under .github/workflows/, and separate workflow approval from normal application code approval.
- Constrain GitHub Actions OIDC trust Bind federated cloud roles to exact repository, branch, and environment claims, and remove wildcard trust conditions that let any workflow mint usable cloud access.
- Inventory CI-held secrets as privileged identities Classify cloud keys, SSH material, registry tokens, and pipeline OIDC paths as governed identities with owners, expiry, and revocation procedures.
What's in the full analysis
StepSecurity's full blog covers the operational detail this post intentionally leaves for the source:
- Decoded payload behaviour and the exact exfiltration sequence used inside the runner
- Repository search patterns for identifying forged workflow files and malicious bot-authored commits
- Confirmed affected organisations, package propagation details, and campaign indicators of compromise
- The evolving technical analysis of campaign infrastructure and additional repository scope
👉 Read StepSecurity's analysis of Megalodon and GitHub Actions secret exfiltration →
GitHub Actions secret theft at scale: what IAM teams missed?
Explore further
18/08/2026 3:35 pm
Pipeline identity is now part of the enterprise identity estate: CI runners hold the same kind of reusable access that IAM teams worry about in service accounts and workload identities. The difference is that pipelines often receive far weaker governance, even though they can mint cloud tokens, access registries, and move secrets at machine speed. Practitioners should treat build systems as privileged identities with lifecycle, review, and revocation requirements.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: How should teams respond when a workflow compromise may have exposed pipeline secrets?
A: Containment should start by revoking affected cloud roles, rotating any secrets accessible to the runner, and disabling suspicious workflows before the next execution cycle. Teams should then inspect commit provenance, branch protection gaps, and outbound runner activity to determine whether the compromise was direct workflow injection or a broader repository breach.
👉 Read our full editorial: Megalodon exposes how GitHub Actions become secret exfiltration paths
