GitHub CI/CD malware campaigns expose secrets governance gaps

At a glance

What this is: This is an analysis of a GitHub CI/CD malware campaign that uses fake automated commits to infiltrate repositories and harvest credentials from build pipelines.

Why it matters: It matters because CI/CD pipelines, repository automation, and secret handling are identity systems in practice, and practitioners need controls that can detect malicious commits before they execute.

By the numbers:

• Over 5,000 GitHub repositories have allegedly been infected with CI/CD credential-stealing malware.
• Our analysis confirms 3,500+ repositories already carrying an infected YAML file.
• 17 minutes.

👉 Read OXSecurity's analysis of the Megalodon GitHub CI/CD malware campaign

Context

GitHub CI/CD security is no longer just a software supply chain issue. When malicious code can enter through fake automated commits and execute inside a pipeline, the repository, the workflow file, and the credentials behind it all become part of the identity attack surface.

For NHI governance teams, this is a classic secret-sprawl and trust-provenance problem. A pipeline can look automated, but if commit identity, merge review, and secret scope are weak, the attacker gets a reliable path from code submission to credential theft.

The article describes a campaign that is actively spreading through repositories, which makes the starting conditions unfortunately typical: too many environments still trust workflow inputs, bot-like identities, and YAML changes more than they should.

Key questions

Q: How should security teams stop malicious CI/CD workflow commits from executing?

A: Protect workflow files with mandatory review, branch protection, and commit provenance checks before they can run in production pipelines. The key is to stop treating YAML as ordinary configuration. If a change can alter execution or credential access, it needs the same governance as a privileged identity change.

Q: Why do CI/CD pipelines make secret theft easier for attackers?

A: Pipelines often concentrate cloud keys, package tokens, environment variables, and deployment credentials in one execution path. That concentration gives attackers a single place to harvest multiple NHI types at once. When the pipeline is trusted to run automatically, any malicious workflow update can turn that trust into credential exposure.

Q: How should security teams reduce risk from compromised GitHub Actions workflows?

A: Security teams should treat workflows as privileged non-human identities. The practical fix is to inventory every secret and role a workflow can reach, shorten credential lifetimes, pin external actions to commit hashes, and monitor runtime behaviour for anomalies. If the workflow can deploy, read secrets, or call cloud APIs, it needs identity-level controls, not just code review.

Q: Which controls matter most when protecting CI/CD credentials?

A: The most effective controls are least privilege by pipeline stage, pre-commit and CI scanning, immutable pinning of third-party actions, and short-lived credentials issued at runtime. Together they reduce exposure, limit lateral use, and make stolen pipeline secrets far less useful.

Technical breakdown

Fake automated commits as a delivery mechanism

The campaign uses commits that appear to come from automation, which lowers suspicion and increases the chance of merge approval. Once the malicious change is accepted, the workflow file becomes the execution trigger, so the repository owner effectively activates the payload inside trusted CI/CD infrastructure. That is why commit provenance matters as much as code content: if the approval path is weak, an attacker can turn routine automation into a delivery channel for identity theft.

Practical implication: require stronger commit provenance checks before workflow changes can reach execution.

YAML workflow files as the control point

CI/CD systems commonly treat YAML as configuration, but in practice those files define execution, credentials access, and tool permissions. If an attacker can alter the workflow, they can direct the pipeline to collect environment variables, query cloud profiles, and invoke local tooling that reveals secrets. The real failure is not YAML itself, but the fact that pipeline definitions often have more privilege than the people reviewing them realise.

Practical implication: treat workflow file changes as privileged changes and restrict who can approve them.

Secret harvesting from build environments

The malware targets AWS credentials, GitHub and Bitbucket tokens, npm and PyPI secrets, environment variables, Docker artifacts, Terraform files, and shell history. That spread is important because build environments routinely aggregate high-value NHI material in one place. Once the pipeline runs, the attacker does not need to break cryptography; they only need the process to disclose credentials that already exist in memory, configuration, or logs.

Practical implication: reduce the amount of long-lived secret material exposed to CI/CD jobs and limit where it can surface.

Threat narrative

Attacker objective: The attacker wants to steal secrets from CI/CD environments and use them to expand access across repositories, cloud services, and developer tooling.

1. Entry occurs through fake automated commits that appear legitimate enough to be merged into a repository workflow.
2. Escalation happens when the merged YAML file executes inside the CI/CD pipeline and grants the malware access to build-time credentials and environment data.
3. Impact is credential theft across cloud, developer, and package-manager identities, followed by further propagation through additional infected repositories.

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

Commit provenance is now an identity control, not a developer convenience. When a repository accepts a workflow change from an apparently automated source, it is making an identity decision about what code may execute and who may inherit that trust. The attacker does not need to break the pipeline if the pipeline already trusts the commit path. Practitioners should treat repository provenance as part of identity governance, not as a separate DevOps concern.

Workflow files are privileged identity artifacts. CI/CD YAML determines which credentials are loaded, which tools are called, and which external systems the job can reach. That makes the file itself a high-risk control surface under OWASP NHI and NIST CSF access-control thinking. The governance mistake is assuming workflow files are just configuration when they are actually delegated execution policy.

Secret sprawl creates one breach path, not many. This campaign shows how AWS keys, package tokens, GitHub tokens, Docker secrets, and shell history can all be harvested through a single pipeline compromise. Identity blast radius: when multiple secret types coexist in one build path, one malicious commit can cross trust boundaries that should have been isolated. Practitioners need to see that concentration as an exposure multiplier, not just an inventory problem.

Platform moderation is part of identity defence. The article’s complaint that malicious code still reaches hosting platforms points to a larger governance gap: systems that distribute code at scale need stronger vetting before execution, not just better incident response after the fact. For identity teams, that means the control question is no longer only who can deploy, but what can be trusted to enter the deployment chain at all.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
• For a deeper case-library lens, review 52 NHI Breaches Analysis for recurring secret exposure and lifecycle failure patterns.

What this signals

Identity blast radius is the right lens for this kind of campaign: once pipeline trust is breached, a single workflow can expose credentials across cloud, package, and developer identities. In environments already carrying hardcoded secret exposure, the practical answer is to narrow the number of places where build systems can see reusable credentials.

With 4.6% of public GitHub repositories already containing hardcoded secrets, teams should expect malicious workflow abuse to succeed where secret hygiene is weak. That means repository controls, runner isolation, and credential scope must be managed together, not as separate workstreams.

The next programme question is not whether automation is useful, but whether the organisation can distinguish trusted automation from attacker-supplied automation before execution. That is where GitHub governance, NHI inventory, and continuous secret discovery start to merge into one operational model.

For practitioners

• Enforce provenance checks on workflow changes Require signed commits, protected branches, and explicit review for any change that touches GitHub Actions or other CI/CD workflow files.
• Reduce standing secret exposure in pipelines Move away from long-lived credentials in build jobs and limit AWS keys, GitHub tokens, and other secrets to the smallest possible execution scope.
• Audit repositories for malicious YAML and bot-like commits Search for unexpected workflow edits, repeated hardcoded bot identities, and the infected YAML patterns described in the article across all active repositories.
• Separate build trust from secret access Use distinct identities for repository maintenance, pipeline execution, and cloud access so a compromised workflow cannot automatically inherit broad secret visibility.

Key takeaways

• This campaign turns GitHub CI/CD into an identity compromise path, not just a code delivery problem.
• OXSecurity reports more than 5,000 allegedly affected repositories and confirms over 3,500 infected YAML files, showing how quickly trust can scale into exposure.
• Commit provenance, workflow approval, and secret scope are the controls most likely to limit damage before malicious automation executes.

Key terms

• Commit Provenance: Commit provenance is the ability to prove who changed code, from where, and under what approved identity. In modern pipelines it depends on signed commits, device trust, and auditable approval paths so that repository history can stand up to incident review.
• Workflow file privilege: Workflow file privilege is the effective authority granted to pipeline definitions that can run code, read secrets, and reach external systems. Although stored as configuration, these files often behave like delegated access policies, so changes to them should be treated as privileged identity events.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full analysis

OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact infected YAML patterns and encoded payload markers used to identify compromised repositories.
• The command sequence the malware uses to enumerate AWS profiles and harvest local secret material.
• The named C2 endpoint and immediate containment steps described by the vendor.
• The repository search approach for finding affected projects at scale.

👉 The full OXSecurity post covers the infected YAML patterns, payload behaviour, and containment guidance.

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.