GhostAction shows how GitHub workflows can turn into secret theft

At a glance

What this is: This is an analysis of the GhostAction supply chain campaign, where malicious GitHub workflows were used to steal 3,325 secrets from 817 repositories.

Why it matters: It matters because CI/CD workflows can become a credential exfiltration path, turning developer access and repository trust into a route to broader cloud and production compromise.

By the numbers:

• GhostAction compromised 327 GitHub users across 817 repositories.
• The campaign exfiltrated 3,325 secrets including PyPI, npm, and DockerHub tokens.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read StepSecurity's analysis of the GhostAction GitHub workflow supply chain attack

Context

GitHub Actions supply chain attacks exploit a basic governance gap: organisations trust repository automation more than they should, and they often treat workflow changes as routine development activity rather than security-relevant code. In practice, a malicious workflow can inherit the same access as legitimate build automation, which makes secrets exposure a control problem as much as a developer hygiene problem.

GhostAction matters to IAM, PAM, and NHI programmes because CI/CD tokens, API keys, and publishing credentials are non-human identities with real blast radius. Once those secrets are available to an unreviewed workflow, standing privilege and weak change control can turn a single compromised developer account into multi-repository and multi-environment access.

The starting position described in this article is not atypical. It reflects a common enterprise pattern where build systems are trusted to run code, read secrets, and publish artefacts with too little isolation between those privileges.

Key questions

Q: How should security teams prevent secrets from reaching shared Git repositories?

A: Use a two-layer approach. Stop secrets locally with pre-commit detection, then enforce server-side rejection with pre-receive hooks so bypassed local checks do not matter. The goal is to prevent credential material from entering Git history at all, because cleanup after publication is unreliable and incomplete.

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 do organisations get wrong about machine secrets in CI/CD pipelines?

A: The most common mistake is treating secrets as deployment convenience rather than identity risk. When keys, tokens, and service accounts are embedded in pipelines, ownership becomes blurred and revocation becomes slower than development. That creates hidden trust paths that are hard to audit and easy to reuse across systems.

Q: Who is accountable when a workload secret is exposed in CI/CD?

A: Accountability usually sits across platform, application, and security teams, because the leak often comes from deployment design rather than a single mistake. The practical answer is to assign ownership to the system that creates, injects, or stores the credential, then require lifecycle controls for every environment it touches.

Technical breakdown

How malicious GitHub workflows exfiltrate secrets

GitHub Actions workflows are event-driven automation definitions that run on repository activity such as pushes or manual triggers. If an attacker can modify a workflow file, they can execute code inside the CI/CD context and read secrets made available to that job. In GhostAction, the malicious workflow disguised itself as a security improvement and used standard Actions syntax to pull secret values into an outbound request. The key architectural weakness is that workflow execution is often granted more trust than code review deserves.

Practical implication: treat workflow files as privileged infrastructure and require security review before any secret-bearing job can run.

Why developer account compromise becomes secret harvest at scale

The campaign shows the compounding effect of developer account compromise. An attacker does not need to break every repository individually if one trusted account can introduce malicious automation across many projects. Once workflow files are modified, the attacker can enumerate secret names, tailor exfiltration logic per repository, and trigger repeated collection on each push. That pattern turns one identity compromise into a repeatable secret harvesting mechanism across package ecosystems and publishing pipelines.

Practical implication: protect developer identities with strong authentication, change-review controls, and alerts for unusual workflow editing behaviour.

How CI/CD secret exposure becomes broader identity risk

The secrets stolen in GhostAction included npm, PyPI, DockerHub, cloud, and database credentials. That matters because these are not isolated development artefacts. They often authorise package publication, deployment, environment access, or downstream automation. In identity terms, they are workload and service credentials with lifecycle, scoping, and revocation requirements. If they are not tied to short-lived usage, they persist beyond the trust boundary that created them.

Practical implication: inventory CI/CD secrets as identities, not just configuration values, and bind each one to a revocation owner and expiry.

Threat narrative

Attacker objective: The attacker’s objective was to harvest reusable credentials from trusted build pipelines and use them to extend access across software supply chains.

1. Entry occurred through compromised GitHub developer accounts that could modify repository workflows.
2. Escalation followed when the malicious workflow inherited CI/CD trust and read secrets available to the job context.
3. Impact came from exfiltration of 3,325 secrets, creating ongoing risk to package publishing, cloud access, and downstream deployments.

Breaches seen in the wild

• GitHub Action tj-actions Supply Chain Attack — Compromised tj-actions/changed-files GitHub Action leaks thousands of CI/CD secrets from 23,000 repositories.
• 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

GitHub workflow trust is now an identity boundary. Organisations still tend to separate source control governance from identity governance, but GhostAction shows that the boundary no longer holds. A workflow file can request and exfiltrate secrets with the authority of the repository, which makes workflow approval a privileged access decision. Practitioners should treat CI/CD automation as part of the NHI estate.

Secret sprawl becomes exploitable the moment workflow access is too broad. The problem is not only secret presence, but secret availability to jobs that do not need them. When build automation can reach publishing, cloud, and registry credentials by default, the organisation has created a standing credential exposure window. That window is exactly what attackers look for when they chain developer compromise into supply chain abuse.

Workflow exfiltration is a named governance gap, not just malware. GhostAction illustrates a specific failure mode: unreviewed workflow changes had enough trust to read secrets and send them off-platform. That is a control failure in change management, privileged workflow execution, and secrets lifecycle governance. The practitioner conclusion is simple: if workflow mutation can touch secrets, the workflow itself needs least-privilege controls.

CI/CD credentials should be governed as non-human identities with lifecycle controls. The stolen PyPI, npm, DockerHub, cloud, and database tokens were operational identities, not incidental data. They need ownership, scoping, rotation, and revocation paths that match their blast radius. Enterprises that still treat them as static configuration will continue to miss the identity risk hidden inside delivery pipelines.

Supply chain attacks now routinely combine human identity compromise with NHI abuse. This campaign started with compromised developer accounts and ended with secret theft from automation. That blend matters because it collapses the old separation between user authentication, workload access, and release authority. Security programmes need one governance model that covers all three, or attackers will keep moving between them.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
• The 64% of valid secrets leaked in 2022 that are still valid today shows why detection alone is insufficient without automated revocation, according to The State of Secrets Sprawl 2026.

What this signals

GhostAction is a reminder that pipeline security is now identity security. As organisations expand automation across build, release, and package publishing, the governance model has to follow the credential, not just the repository. The operational question is whether secrets are still being issued as long-lived shared access, or managed as scoped non-human identities with a clear revocation path.

Workflow trust boundary drift: when repositories can modify the automation that reads their secrets, the trust boundary has moved away from the code review process. That is where teams should focus monitoring, change approval, and secrets governance. The most useful control signal is not only whether a secret exists, but whether any job can reach it without a deliberate, reviewed business need.

For identity programmes, the practical shift is to align CI/CD access with least privilege, short-lived credentials, and owner-based accountability. For security leaders, that means linking platform engineering, IAM, and secrets management into one operating model instead of treating them as separate hygiene workstreams.

For practitioners

• Lock down workflow mutation rights Require security review and branch protection for any change that can create, edit, or trigger a secret-bearing GitHub Actions workflow.
• Separate secrets from routine build jobs Remove unnecessary registry, cloud, and publishing secrets from workflows that do not strictly need them, and split privileged jobs from standard CI tasks.
• Treat CI/CD tokens as managed non-human identities Assign an owner, expiry, scope, and revocation path to every token used in pipelines, then rotate credentials that were reachable from compromised workflows.
• Monitor for outbound secret exfiltration patterns Alert on new workflow files that contain curl, webhook posts, unfamiliar domains, or secret interpolation patterns inside repository automation.

Key takeaways

• GhostAction shows that malicious workflow changes can convert developer trust into large-scale secret theft.
• The campaign’s scale, 327 users, 817 repositories, and 3,325 secrets, shows that CI/CD pipelines can become a broad credential exposure surface.
• Branch protection, workflow review, and lifecycle-managed pipeline secrets are the controls most likely to reduce this attack path.

Key terms

• GitHub Actions Workflow Identity: The automation identity a workflow uses to authenticate and act inside a repository or connected service. It is a non-human identity because it can create, modify, or delete resources without a person directly operating each action. Governance depends on scope, trigger design, and secret handling.
• CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
• Pipeline non-human identity: A pipeline non-human identity is a credential or token used by automation to authenticate to systems during build, test, deploy, or publish activities. It needs lifecycle management, ownership, scoped privilege, and revocation just like a human account, because abuse can have enterprise-wide impact.
• Deployment Workflow Trust Boundary: The point at which a CI or release workflow stops operating on verified internal inputs and starts accepting context that can be influenced by users, forks, or external integrations. In practice, this boundary determines whether deployment metadata and environment values can be treated as safe.

What's in the full analysis

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

• Exact GitHub search logic used to find the malicious workflow pattern across affected repositories
• Repository-level indicators of compromise, including the exfiltration domain and workflow file structure
• Step-by-step response actions for impacted teams, including cleanup and secret rotation sequencing
• StepSecurity Enterprise policy settings for blocking secret exfiltration workflows and runner misuse

👉 StepSecurity's full post covers the malicious workflow pattern, affected repositories, and response steps in detail.

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 and identity teams build the controls needed to manage credentials, privilege, and lifecycle risk across modern delivery pipelines.