Megalodon exposes how GitHub Actions become secret exfiltration paths

At a glance

What this is: This is a supply chain attack analysis showing how Megalodon used GitHub Actions workflow injection to steal secrets from thousands of repositories and turn CI runners into exfiltration paths.

Why it matters: It matters because CI pipelines now carry identity and secret handling risk, so IAM, PAM, and NHI teams must treat workflow permissions, branch protection, and OIDC minting as governance controls, not just developer tooling.

By the numbers:

• StepSecurity reports that 5,561 GitHub repositories were backdoored within a single six-hour window.
• The campaign produced 5,718 malicious commits, according to StepSecurity.

Context

GitHub Actions is a high-trust execution layer, not just a build automation tool. When workflows can read injected secrets and mint OIDC tokens, a compromised workflow file becomes an identity and credential abuse path rather than a simple code issue.

Megalodon shows how weak branch protection and broad workflow permissions collapse the boundary between source control and secrets handling. That makes CI/CD governance relevant to IAM, NHI, and cloud teams because the pipeline itself can act as a non-human identity with standing privilege.

The pattern is not unusual in modern software delivery. Repositories that allow workflow changes without strong review gates are exposed to the same class of abuse whenever attackers can reach the default branch.

Key questions

Q: What breaks when GitHub Actions workflow files can be changed directly?

A: The review gate breaks, and with it the trust boundary around CI execution. A malicious workflow can run with repository secrets, cloud federation permissions, and outbound internet access, which lets an attacker turn delivery infrastructure into a credential theft path. The practical failure is not code compromise alone, but unaudited privilege at build time.

Q: Why do CI workflows create such high secret-exfiltration risk?

A: They combine secret injection, token minting, and network access in the same execution context. If a workflow can read environment variables and also obtain OIDC or cloud credentials, a single run can expose multiple identity domains at once. That is why pipeline permissions and secret scope matter as much as application code review.

Q: What are the signs that a GitHub Actions workflow has been tampered with or is behaving maliciously?

A: Common warning signs include unexpected network destinations, new or unusual outbound traffic, changes in version tags without a corresponding code review, and workflow logs that suddenly contain sensitive values. In a compromised action, a security monitor may also show the runner downloading scripts or contacting domains that do not match the workflow’s normal behavior.

Q: How should teams respond when workflow credentials are exposed in CI?

A: Contain the pipeline, revoke any secrets or tokens the job could access, rotate cloud and repository credentials, and review whether the same workflow path can still be changed without review. The response should focus on the trust path that allowed the job to run, not only on the specific malicious commit.

Technical breakdown

Why GitHub Actions workflows are high-value execution points

GitHub Actions workflows run shell commands in an environment that often contains repository secrets, service tokens, and cloud credentials. If the workflow has id-token: write, it can also mint short-lived OIDC tokens for cloud authentication, which means the runner can become a credential creation point as well as a credential consumer. In practice, this turns a workflow file into an executable trust boundary. The risk is not only code execution, but secret access at job runtime, when defenders may have little visibility into what was read, minted, or sent out.

Practical implication: Treat workflow files as security-sensitive assets and restrict who can change them.

Direct poisoned pipeline execution vs review-gated changes

Direct poisoned pipeline execution, or d-PPE, happens when an attacker can push a malicious workflow straight to the default branch and have it run on the next pipeline execution. That differs from indirect PPE, where the attacker must first persuade a maintainer to merge a pull request. The difference matters because branch protection is the control that forces an attacker into the harder path. Without mandatory review and merge protection, CI/CD becomes vulnerable to direct workflow injection rather than code review mediated change.

Practical implication: Enforce branch protection that blocks direct workflow changes to protected branches.

Why CI runners are effective exfiltration platforms

CI runners usually have outbound internet access, access to secrets injected at runtime, and ephemeral execution that leaves limited local evidence after the job ends. That combination lets attackers harvest environment variables, files such as .ssh and .kube configs, and cloud tokens, then send the archive out over HTTPS with little operational noise. Because the job can exit cleanly after exfiltration, the compromise may look like a normal build unless logging, egress controls, and workflow review are strong enough to catch the abuse.

Practical implication: Add egress controls and secret-scanning telemetry to CI so exfiltration attempts are visible.

Threat narrative

Attacker objective: Steal secrets and tokens from CI environments at scale so they can be reused for cloud access, package compromise, and further supply chain intrusion.

1. Entry occurred through forged workflow commits that landed in repositories with weak branch protection, giving the attacker a direct path to the default branch.
2. Credential harvesting happened when the malicious workflow dumped environment variables, cloud tokens, SSH keys, registry configs, and GitHub Actions OIDC tokens during pipeline execution.
3. Exfiltration followed as the payload compressed the collected material and sent it over HTTPS to the attacker-controlled server before the runner finished.
4. Impact was mass secret theft across thousands of repositories, with downstream risk to cloud accounts, package ecosystems, and other connected systems.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI pipelines are now identity infrastructure: when workflows can read secrets and mint OIDC tokens, the pipeline itself becomes a non-human identity with privileged runtime authority. That changes the governance question from build security to credential governance, because the abuse path is access at execution time rather than compromise of application code. Practitioners should govern workflows as privileged identities with explicit issuance and change controls.

Branch protection is the control that separates review from direct abuse: this campaign shows that the real failure was not merely malicious code, but the absence of a gate that forced workflow changes through human review. When a workflow file can be merged directly, the attacker inherits the trust normally reserved for approved delivery. Security teams should treat mandatory review on workflow paths as a first-class control.

Standing workflow privilege is the named failure mode here: CI jobs that always receive broad secrets, cloud tokens, and outbound network access create a persistent exfiltration surface. The concept is broader than a leaked secret, because the runner can repeatedly mint or retrieve access material every time the pipeline runs. Practitioners should reduce the amount of standing privilege that any one workflow can exercise.

Ephemeral execution does not eliminate risk when egress is open: the attacker benefited from the fact that short-lived runners can still complete a clean, automated theft-and-send cycle before defenders inspect the job. Ephemerality helps containment after the fact, but it does not stop collection if secrets are already present and outbound traffic is unrestricted. The governance lesson is to control what can be reached during the run, not just what remains afterward.

Secret sprawl in build systems is an identity governance problem, not only a DevOps issue: the payload harvested cloud credentials, SSH keys, package tokens, and OIDC material from one execution context. That means the same repository can expose multiple trust domains at once. Practitioners should inventory CI secrets as part of the broader NHI and access governance programme, not as an isolated pipeline concern.

From our research library:

• 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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Workflow trust is becoming a governance boundary: security teams should stop treating CI pipelines as disposable automation and start treating them as privileged non-human identities. Once a workflow can mint tokens and read secrets, the control point shifts to issuance, branch protection, and change approval rather than post-run detection.

Secret sprawl in build systems now reaches identity programmes: the same runner can touch cloud access, SSH material, package credentials, and federated tokens in one session. That convergence means IAM, PAM, and NHI teams need a shared view of what CI can access, not separate policies for each credential class.

For practitioners

• Lock down workflow changes on protected branches Require mandatory review for changes under .github/workflows and block direct pushes to default branches so malicious workflow files cannot land without oversight.
• Reduce secrets exposure inside CI jobs Minimise which credentials are injected into runners, split secrets by repository and job, and remove anything that is not strictly needed for the build step.
• Constrain OIDC token minting Limit id-token: write to the few workflows that truly need cloud federation and tie those permissions to tightly scoped trust policies.
• Monitor for outbound exfiltration from runners Alert on unusual HTTPS POST traffic, unexpected archive creation, and reads of .ssh, .kube, .npmrc, and similar credential locations during workflow execution.
• Audit repository forks and bot-like commits Review repositories that accept high-velocity automation commits or public fork merges for weak merge controls and workflow path exposure.

Key takeaways

• The campaign shows that a workflow file can become an active exfiltration path when CI runners inherit secrets and cloud federation rights.
• Mass repository compromise becomes easier when branch protection is weak and workflow changes bypass human review.
• Reducing runner privilege, tightening workflow approvals, and limiting token minting are the controls that shrink the blast radius.

Key terms

• Direct Poisoned Pipeline Execution: A supply chain attack in which an adversary injects malicious commands directly into pipeline definition files so the next build runs attacker-controlled code. The compromise works because the CI system trusts workflow configuration as execution authority, turning repository change control into runtime access control.
• GitHub Actions OIDC Token: A short-lived federated credential issued to a workflow so it can authenticate without storing long-lived secrets. In security programmes, the token is only as safe as the workflow permissions, repository trust, and downstream services that accept it.
• Branch Protection: Branch protection is a change-control mechanism that limits who can alter a protected branch and under what conditions. In pipeline governance, it acts as a gate on when privileged automation can run, making source control part of the access decision rather than a passive repository.
• CI runner: A CI runner is the execution environment that processes build, test, and deployment jobs. In NHI terms, it often holds privileged automation access, temporary credentials, and environment context that can be harvested if a malicious dependency or script executes during the pipeline.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners align access control with how machine identities actually operate.