Megalodon exposes how GitHub Actions become secret exfiltration paths

At a glance

What this is: This is a supply chain attack analysis showing how malicious GitHub Actions workflows turned CI pipelines into secret-harvesting channels across thousands of repositories.

Why it matters: It matters to IAM, PAM, and NHI teams because CI runners routinely hold high-value credentials, short-lived tokens, and cloud access that need identity-grade governance.

By the numbers:

• The campaign touched 5,561 repositories across GitHub in a single six-hour window.

👉 Read StepSecurity's analysis of Megalodon and GitHub Actions secret exfiltration

Context

GitHub Actions has become part of the identity plane, not just the build plane. When workflow files can run arbitrary commands and inherit secrets, OIDC tokens, cloud keys, SSH material, and registry credentials, a compromised pipeline can become an access broker for everything downstream. In this article, the primary weakness is not application code but governance over who can change workflow definitions and what those workflows are allowed to mint or export.

For identity programmes, the relevant boundary is between repository governance and runtime authority. Branch protection, pull request review, and workflow permission scoping are access controls with direct security impact, especially where repositories issue short-lived cloud credentials through GitHub Actions OIDC. The attack pattern described here is not unusual for modern software supply chains; it is what happens when pipeline identity is treated as operational convenience rather than a protected control surface.

Key questions

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. Once an attacker can alter the job definition, the build system can execute hidden logic with access to secrets and deployment context. That turns CI/CD into an identity-bearing execution layer and makes repository integrity a credential security issue as well.

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. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

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. In reality, a malicious workflow can mint fresh tokens during runtime if the trust policy is too broad. The protection comes from narrow claims binding, careful role scoping, and strong control over which workflow files can execute at all.

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.

Technical breakdown

How poisoned GitHub Actions workflows steal pipeline secrets

Direct poisoned pipeline execution works by modifying workflow definition files so the runner executes attacker-controlled commands on the next build. Because GitHub Actions injects repository secrets into the job context, a malicious step can read environment variables, files, process state, and token material before sending it out over normal outbound network paths. The runner usually exits cleanly, which makes the theft look like a successful build rather than an incident. Practical implication: treat workflow YAML as privileged code and require strict change control on every file under .github/workflows/.

Practical implication: Protect workflow definitions with mandatory review and change control, not just application source code.

Why OIDC tokens expand the blast radius of a compromised workflow

When a workflow has id-token: write permission, GitHub Actions can mint short-lived OIDC tokens that cloud providers trust for federation. That removes the need for static cloud keys, but it also means an attacker who controls the workflow can obtain fresh cloud-authentication material during runtime. In practice, the workflow becomes an identity issuer with access to cloud roles, not merely a script runner. Practical implication: narrow OIDC trust policies, bind them to repo, branch, and environment claims, and review every federated role assumption path.

Practical implication: Restrict federated trust conditions so a stolen workflow cannot mint broadly reusable cloud access.

Why branch protection is the real control point in CI/CD identity governance

The difference between direct and indirect poisoned pipeline execution is governance over who can land workflow changes on the default branch. Mandatory pull request review converts a direct push opportunity into a harder social or process attack, while weak merge controls leave CI trusted by default. That makes branch protection an identity control because it decides whose code gets execution authority inside the pipeline. Practical implication: enforce branch protection as a security requirement, not a repository preference.

Practical implication: Use branch protection and review gates to stop workflow tampering before it reaches the runner.

Threat narrative

Attacker objective: The attacker aimed to steal reusable access material from CI pipelines and convert repository trust into cloud and supply chain compromise.

1. Entry occurred when the attacker injected forged GitHub Actions workflows into repositories with weak branch protection and direct merge paths.
2. Credential harvesting followed as the malicious runner read environment variables, cloud keys, SSH material, registry tokens, and OIDC tokens from the CI job context.
3. Impact came when harvested secrets were compressed and exfiltrated to an external command server without alerting repository owners, enabling downstream abuse of cloud and software supply chain access.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Branch protection failure created the real compromise window: this attack worked because workflow changes could reach execution without strong review gates. That is a governance failure, not a tooling quirk, because workflow definition files are the code that grants access to secrets and cloud roles. Practitioners should reframe branch protection as a control over runtime authority, not just source code hygiene.

OIDC federation reduces static secret exposure but increases trust dependency: short-lived tokens are only safer when federated trust policies are tightly scoped to repository, branch, and environment claims. If those trust conditions are broad, a malicious workflow can mint fresh cloud access on demand, which turns federation into a fast path for abuse. Practitioners should validate every federation path as though it were a privileged credential issuer.

Direct poisoned pipeline execution is the named concept practitioners need to watch: it describes attacker-controlled workflow changes that execute on the next pipeline run without waiting for a forked pull request or human review. That concept is useful because it separates the social engineering of merge approval from the structural problem of unguarded workflow authority. Practitioners should build detection and prevention around workflow mutation, not only around code commits.

CI/CD secrets need NHI-grade governance, not ad hoc DevOps handling: cloud credentials, SSH keys, API tokens, and GitHub Actions OIDC tokens are all non-human identities in practice because they authorise software to act. The governance model must include inventory, least privilege, scoped trust, and rapid invalidation when workflows change. Practitioners should align pipeline controls with NHI lifecycle expectations.

From our research:

• 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.
• This pattern connects directly to Guide to the Secret Sprawl Challenge, which shows how secret sprawl and inconsistent lifecycle controls create the conditions attackers exploit.

What this signals

Pipeline governance is now identity governance: teams that still separate DevOps controls from IAM controls will miss the real failure mode in attacks like this. The practical shift is to treat workflow definitions, OIDC trust paths, and repository review gates as privileged access controls that belong in the same governance conversation as service accounts and secrets rotation.

Direct workflow tampering creates a fresh detection problem: the signal is not always malware or a noisy exploit, but a legitimate build that should never have been allowed to execute in the first place. That means security teams need monitoring for workflow file changes, forged bot identities, and unusual runner egress alongside their normal CI integrity checks.

The broader programme implication is that federated cloud access must be bounded by least privilege and lifecycle discipline. If a pipeline can mint cloud tokens, it must also be governed like any other high-risk identity issuer, with explicit ownership, scope limits, and revocation paths.

For practitioners

• Lock down workflow file changes Require mandatory review for every modification under .github/workflows/, and separate workflow approval from normal application code approval. That closes the direct push path that enables poisoned pipeline execution.
• 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.
• Detect workflow tampering as a first-class signal Alert on newly added or modified workflow files, forged bot authorship, suspicious build-bot commit messages, and unusual outbound connections from runners.
• Reduce runner blast radius Use isolated runners, minimal outbound access, and secret scoping so a single job cannot enumerate the full credential estate or exfiltrate it in one pass.

Key takeaways

• Megalodon shows that GitHub Actions workflows can be used as a secret-exfiltration layer when branch protection and workflow review are weak.
• The campaign affected 5,561 repositories in six hours, which shows how quickly pipeline trust can be turned into credential theft at scale.
• The control that matters most is governance over workflow changes and OIDC trust scope, because that is where pipeline authority becomes attacker authority.

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.
• Workflow Definition File: The configuration file that tells a CI system what to run, when to run it, and what permissions the job receives. In GitHub Actions, this file is effectively privileged code because changes to it can alter access to secrets, network reach, and cloud federation paths.
• Pipeline Secret Scope: The set of credentials, tokens, and environment values a CI job can reach during execution. Tight secret scope limits blast radius when a runner is compromised, while broad scope allows a single malicious step to harvest far more than the build actually needs.

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

👉 StepSecurity's full post covers decoded payloads, affected repositories, and indicators of compromise.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the control model that modern automation and pipelines now require.