Megalodon malware shows how GitHub Actions can leak credentials

At a glance

What this is: This is a threat-intelligence analysis of the Megalodon campaign, which hid malicious logic inside GitHub Actions workflows to harvest credentials from build environments and related repository assets.

Why it matters: It matters because CI/CD workflow trust assumptions can turn automation into a high-value credential collection path unless repository controls, secret handling, and outbound monitoring are aligned.

By the numbers:

• Gurucul says the campaign spread to roughly 2,800 files with similar malicious payload patterns across GitHub repositories.

Context

GitHub Actions is a CI/CD automation system that runs workflows during builds, tests, and deployments. In this campaign, attackers abused that trusted execution path to run obfuscated code inside repositories and harvest credentials from the environment.

The governance problem is not just malware hiding in code. It is the assumption that workflow approval, repository trust, and build-time execution are sufficient to protect secrets that live inside automation contexts. For NHI programmes, that makes CI/CD a governed identity surface, not only a software delivery tool.

Key questions

Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?

A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool. A malicious workflow can dump secrets, upload them as an artifact, and remove traces before anyone notices. At that point, detection becomes reactive only, and organisations are left rotating credentials after exposure instead of preventing the theft in the first place.

Q: Why do malicious CI/CD workflows create such a large blast radius?

A: Because build pipelines often sit at the intersection of source code, package publishing, and cloud access. If one trusted workflow can read multiple credentials, the attacker can reuse those secrets across registries, environments, and downstream automation. The blast radius is large because the identities are already pre-authorised.

Q: What are the signs that a CodeBuild-hosted GitHub Actions job is being abused at runtime?

A: Warning signs include unexpected outbound connections, unusual file writes, and process executions that do not match the workflow step being run. Memory-reading activity is especially important because attackers have used it to steal tokens from build environments. If those actions appear in a job log without runtime telemetry, the compromise can remain invisible until credentials or internal systems are already exposed.

Q: How should teams govern GitHub Actions after a workflow compromise?

A: Treat workflow definitions as sensitive identity assets, not just automation code. Separate approval for workflow changes, narrow secret scope, and review any repository where build steps can read credentials that would be dangerous if copied outside the pipeline.

Technical breakdown

How malicious GitHub Actions workflows become a credential collection layer

GitHub Actions workflows can execute with access to repository secrets, environment variables, deployment tokens, and cloud authentication material. When an attacker modifies a workflow file, the malicious logic runs inside the same trusted pipeline context as legitimate automation. That makes the build runner a credential-rich execution environment, especially when secrets are exposed to jobs by default or when workflow changes are not tightly restricted. In this campaign, the workflow modification itself was the delivery mechanism, and the build process became the place where collection occurred.

Practical implication: Treat workflow file changes as identity-sensitive events and restrict who can alter pipeline execution paths.

Why Base64 obfuscation matters in CI/CD compromise

Base64 is not encryption, but it is a common way to hide malicious commands inside scripts and workflow definitions so they are less obvious in review and harder for simple detections to flag. In a CI/CD compromise, obfuscation helps attackers blend credential harvesting, environment enumeration, and callback logic into otherwise routine build steps. That matters because many pipelines validate syntax and execution success more reliably than they inspect intent. The operational problem is not only malicious code, but malicious code that still looks structurally normal to the pipeline.

Practical implication: Inspect encoded commands and inline script blocks as part of workflow approval and security review.

What external C2 traffic from build environments reveals

When a build runner reaches out to attacker infrastructure, the pipeline is no longer just executing code, it is also participating in command-and-control communications. That outbound traffic can carry repository identifiers, harvested secrets, or session context that helps the attacker track which environments are compromised. For defenders, this is important because CI/CD environments often have weak network baselining compared with endpoints or production hosts. A build system that should only contact approved package registries or internal services is a clear anomaly when it talks to unknown external servers.

Practical implication: Baseline allowed egress for runners and alert on outbound connections from build environments that do not match expected dependencies.

Threat narrative

Attacker objective: The attacker’s objective was to collect reusable credentials at scale and use them for repository compromise, cloud access, and broader supply-chain exploitation.

1. Entry occurred when attackers inserted malicious changes into GitHub Actions workflow files within affected repositories, turning trusted automation into the initial execution path.
2. Credential access followed when the payload enumerated environment variables and extracted GitHub tokens, cloud credentials, API keys, database secrets, and private keys from the build context.
3. Command-and-control was established when the decoded payload communicated with attacker infrastructure at 216.126.225.129 to identify compromised repositories and manage harvested data.
4. Impact emerged as stolen credentials created risk of repository takeover, cloud account access, and downstream supply-chain abuse across multiple environments.

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).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

Workflow trust is now an identity boundary, not just a delivery concern. Megalodon shows that CI/CD pipelines can function as credential-rich execution environments when workflow files are writable by the wrong people or insufficiently reviewed. The security problem is not isolated to code integrity; it is the governance of which identities may alter runtime automation. Practitioners should treat workflow change control as part of identity control, not a separate DevOps concern.

Secret exposure in pipelines is a lifecycle failure, not a visibility problem. The campaign succeeded because credentials were available to the workflow at execution time and could be collected before any human review or offboarding event could intervene. That makes secret issuance, scope, and revocation the real control plane. For NHI governance, the decisive question is not whether a secret exists, but whether the pipeline should ever be able to see it.

GitHub Actions compromise maps directly to the NHI problem of reusable credentials in ephemeral contexts. Build runners are transient, but the credentials they touch are often long-lived and broadly scoped. That mismatch creates an identity blast radius: one workflow compromise can expose tokens that outlive the job that stole them. Teams need to understand that ephemeral execution does not equal ephemeral privilege.

Obfuscated workflow payloads turn ordinary automation into a detection gap. Base64-encoded commands, outbound C2 traffic, and secret-harvesting logic are all indicators that pipeline telemetry must be correlated across source control, build logs, and network events. Without that correlation, the compromise looks like routine CI activity until stolen credentials begin to move laterally. The practical conclusion is that pipeline security has to be governed as a cross-control problem, not a single product problem.

Credential harvesting in CI/CD is an attack on trust assumptions about automation. GitHub Actions assumes workflows execute approved steps, but Megalodon exploited the fact that approved steps can themselves be altered. That means governance based only on repository access is incomplete. Practitioners should re-evaluate every control that assumes the build system is a benign intermediary rather than an identity-active environment.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Identity blast radius in CI/CD is the key governance concept here: a build runner is transient, but the secrets it can reach are often reusable and durable. That mismatch means one workflow compromise can outlive the job that triggered it, so NHI teams have to govern secret reachability at execution time, not only at provisioning time.

GitHub Actions compromise should be assessed alongside pipeline identity guidance because the control problem sits in the execution path itself. If workflow files can change what a trusted runner can read, the organisation has effectively delegated credential handling to code that may be modified by an attacker.

For practitioners

• Lock down workflow file changes Require code-owner approval and separate administrative review for GitHub Actions workflow files, because those files define runtime execution paths and secret access.
• Reduce secret exposure to runners Scope repository and environment secrets to the smallest feasible job context, and remove any credential that is not strictly needed during pipeline execution.
• Monitor encoded scripts and inline payloads Flag Base64-encoded command blocks, shell scripts, and unusual step content in workflow diffs before they reach trusted runners.
• Baseline build-environment egress Alert on outbound connections from build environments to unapproved IPs, domains, or ports, especially when they coincide with secret access events.
• Review credential blast radius after workflow changes Reassess which GitHub, cloud, and database secrets are reachable from each repository whenever a workflow is modified.

Key takeaways

• Megalodon shows that CI/CD pipelines can become credential collectors when workflow integrity and secret exposure are not governed together.
• The campaign reached roughly 2,800 files with similar malicious payload patterns, which suggests a distributed supply-chain pattern rather than a single isolated compromise.
• The most direct limiting control is to tighten who can change workflows and to shrink the secrets those workflows can reach.

Key terms

• GitHub Actions Workflow Orchestration: GitHub Actions workflow orchestration is the controlled process of applying approved workflow patterns across multiple repositories. In practice, it helps teams standardise CI/CD behaviour, reduce drift, and enforce consistent security and operational controls through automated pull requests rather than ad hoc manual copying.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.

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 programme, it is worth exploring.