Megalodon malware shows how GitHub Actions can leak credentials

At a glance

What this is: This is a supply chain threat analysis showing how malicious GitHub Actions workflows were used to steal credentials at scale from repository environments.

Why it matters: It matters because CI/CD pipelines frequently hold NHI secrets and privileged tokens, so workflow tampering can turn build systems into high-value credential harvesters.

By the numbers:

• The campaign was linked to approximately 2,800 files containing similar malicious payload patterns across multiple repositories.

👉 Read Gurucul's analysis of the Megalodon GitHub Actions credential theft campaign

Context

GitHub Actions becomes a governance problem when trusted workflow files can be modified to execute attacker-controlled code during normal build and deployment runs. In that model, the primary risk is not the repository itself but the privileged CI/CD environment that can see secrets, tokens, and cloud credentials.

This article is about non-human identity exposure through software supply chain compromise. The malicious workflow logic targeted repository secrets and environment variables, which means security teams need to treat pipeline identities, not just human access, as a first-class control surface.

The pattern is familiar in modern engineering environments: automation is granted access because it is needed for delivery, then that same access becomes a collection point for credentials when workflow integrity is weak. That is typical of CI/CD-focused NHI abuse.

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 such a large NHI risk?

A: CI/CD pipelines often hold tokens and secrets that can reach source code, cloud platforms, and downstream services. If those credentials are exposed in jobs that run automatically, the attacker does not need a human login. They only need the pipeline's trusted execution path and the privileges already attached to it.

Q: What do security teams get wrong about secrets in build automation?

A: They often treat secrets as temporary because the job is temporary, but the credential itself may remain valid and reusable after the run ends. That mismatch creates reuse risk across repositories and cloud accounts. Pipeline design should assume that any credential touched during automation can be harvested and replayed elsewhere.

Q: How should teams respond when they find suspicious GitHub Actions activity?

A: Contain the workflow first by freezing the affected branch, revoking exposed tokens, and reviewing recent job executions for encoded commands or unusual outbound connections. Then trace where the credentials could have been used, because the true risk is not just the modified workflow but the access it may have unlocked.

Technical breakdown

Malicious GitHub Actions workflow modification

GitHub Actions workflows run with repository context and often inherit access to secrets, environment variables, and deployment tokens. When an attacker modifies a workflow file, the change can execute during routine build activity without needing interactive login. That makes the workflow file itself part of the trust boundary. In this case, the malicious logic was embedded in automated build processes, which is why supply chain compromise and identity abuse intersect so sharply in CI/CD environments.

Practical implication: protect workflow files with the same change control you apply to production deployment code.

Obfuscated payloads and credential harvesting in CI/CD

Base64 encoding and script chaining are common ways to conceal malicious behaviour inside pipeline jobs. Once decoded, the payload can enumerate files, inspect environment variables, and search for cloud keys, database secrets, API keys, and private keys. The attack succeeds because build runners are designed to access sensitive material temporarily, but often with more privilege than the job actually needs. In NHI terms, the runner identity becomes a high-value credential collection point.

Practical implication: inspect pipeline executions for encoded commands, secret reads, and unusual environment enumeration.

Command-and-control and exfiltration from build infrastructure

The presence of outbound communication to attacker infrastructure shows this was not simple secret exposure, but an active collection and export operation. Once secrets are harvested, the attacker can stage them centrally, correlate victims, and reuse the credentials for cloud access or downstream repository compromise. CI/CD environments are especially dangerous here because egress from trusted build hosts is often treated as normal operational traffic.

Practical implication: correlate secret access events with outbound network traffic from build runners.

Threat narrative

Attacker objective: The attacker aimed to harvest reusable credentials from trusted build environments and use them to expand access across repositories, cloud services, and downstream systems.

1. Entry occurred through malicious modification of GitHub Actions workflow files in affected repositories, giving the attacker code execution inside the build process.
2. Credential access followed when the payload enumerated environment variables and extracted GitHub tokens, cloud credentials, API keys, database secrets, and private keys.
3. Impact came from the ability to reuse stolen credentials for repository takeover, cloud account access, lateral movement, and broader supply chain compromise.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Workflow identity is now a credential-bearing non-human identity. The article shows that a GitHub Actions workflow is not just automation code. It is a privileged execution context that can access secrets, cloud tokens, and deployment material. Once that context is mutable, the workflow itself becomes part of the identity attack surface, and practitioners must treat workflow integrity as an NHI governance issue.

Secret exposure in CI/CD is a standing privilege problem, not only a theft problem. The payload worked because build systems had access to credentials that were useful long enough to steal and reuse. That is a privilege design failure, not simply an endpoint compromise. The implication is that pipeline identities need narrower scope, shorter validity, and stronger release controls than many delivery teams currently assume.

Obfuscated workflow execution is a pipeline trust collapse signal. Base64 payloads and scripted retrieval of environment data indicate that trusted automation can be repurposed into a covert collection layer. NHI governance cannot rely on static repository trust if the runtime can introduce hidden execution paths. The practitioner conclusion is that workflow observability has to match the privilege embedded in the runner.

Identity blast radius in CI/CD is larger than the repository that was touched. The campaign targeted credentials that could open cloud accounts, databases, and third-party services, so the real risk sits in downstream reuse. That means the control boundary is the credential ecosystem attached to the pipeline, not the source repository alone. Security teams should model blast radius from the build identity outward.

Runtime monitoring must join secret governance if supply chain attacks are to be contained. The article's combination of workflow tampering, secret harvesting, and external C2 traffic shows that isolated controls miss the attack chain. NHI governance, repository protection, and network monitoring are all part of the same trust problem. Practitioners should align CI/CD controls across code integrity, secret access, and egress visibility.

From our research:

• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. according to the Ultimate Guide to NHIs.
• Our research also shows that only 5.7% of organisations have full visibility into their service accounts. That visibility gap is why build-time identity abuse often goes undetected until after exfiltration begins.
• For a broader control baseline, see the Top 10 NHI Issues for the recurring governance failures that let secrets escape from trusted automation.

What this signals

Pipeline identities now need the same governance lens as service accounts. When build systems can read secrets, modify deployments, and call external services, their privilege profile becomes operationally meaningful. With the 52 NHI Breaches Report showing repeated abuse of non-human credentials, teams should expect CI/CD to remain a primary abuse path unless access scope is tightened.

Identity blast radius is the concept most teams still under-measure. The important question is no longer whether a workflow was compromised, but what that workflow could touch after compromise. That means mapping repository access to cloud, database, and third-party credential reach, then reducing the number of secrets available at runtime.

For practitioners, the next step is to treat secret access, workflow integrity, and outbound egress as one control plane rather than three separate reviews. If those signals are not correlated, supply chain compromise will continue to look like routine build noise until the damage is already done.

For practitioners

• Lock down workflow file changes Require protected-branch controls, code-owner approval, and review separation for GitHub Actions workflow files so malicious job logic cannot be merged casually.
• Reduce runner secret exposure Limit which secrets are injected into build jobs, scope them to the smallest viable repository or environment, and avoid passing long-lived credentials into automated pipelines.
• Scan for encoded or hidden job logic Detect Base64, script chaining, suspicious downloads, and environment enumeration in pipeline executions because obfuscation is a common marker of credential harvesting.
• Correlate secret access with outbound traffic Join CI/CD audit logs, secret manager events, and egress telemetry so stolen credentials and exfiltration attempts are visible in the same investigation path.

Key takeaways

• Malicious GitHub Actions workflows can turn routine CI/CD execution into a credential harvesting mechanism.
• The scale of the campaign shows why pipeline identities and secrets must be governed as a single risk surface.
• Protecting workflow integrity, limiting runtime secrets, and correlating egress are the controls that reduce blast radius.

Key terms

• GitHub Actions Workflow: An automated job definition that runs inside GitHub to build, test, or deploy code. In security terms, it is also an execution context that may inherit secrets, tokens, and environment access, which makes workflow integrity a governance concern rather than just a developer convenience.
• CI/CD Pipeline Identity: The non-human identity and permissions used by build and deployment automation to perform tasks on behalf of a repository or application. It often has access to secrets and cloud endpoints, so it must be scoped and monitored like any other privileged NHI.
• Credential Harvesting: The collection of reusable secrets, tokens, keys, or certificates from systems that process them. In pipeline attacks, harvesting usually happens by reading files, environment variables, and secret stores during execution, then exporting the results to attacker infrastructure.

What's in the full article

Gurucul's full blog covers the operational detail this post intentionally leaves for the source:

• Workflow file indicators that distinguish benign automation changes from malicious CI/CD tampering
• The decoded payload structure and the exact credential harvesting logic observed in the repository files
• IOC details for the external server and the suspicious callback pattern used during the campaign
• Gurucul SIEM detection ideas for correlating workflow change events with secret access and outbound traffic

👉 Gurucul's full post covers the workflow indicators, payload decoding, and detection coverage in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.