GhostAction shows how GitHub workflows can turn into secret theft

At a glance

What this is: GhostAction was a GitHub Actions supply chain campaign that used malicious workflows to steal 3,325 secrets from 817 repositories across 327 GitHub users.

Why it matters: It matters because workflow changes can become a secret theft path, so IAM, PAM, and NHI teams must treat CI/CD permissions, review gates, and runner trust as governance controls.

By the numbers:

• GhostAction compromised 327 GitHub users across 817 repositories.
• The campaign exfiltrated 3,325 secrets including PyPI, npm, and DockerHub tokens.

Context

GitHub Actions becomes a security boundary when workflow files can read secrets, trigger on push, and reach external endpoints. In GhostAction, attackers used compromised developer accounts to add workflows that looked like hardening but actually exfiltrated credentials.

The identity angle is direct: repository access, workflow approval, runner selection, and secret scope all determine whether a malicious change can act like a trusted automation step. That makes CI/CD governance a machine-identity and privilege problem, not just a developer hygiene issue.

Key questions

Q: What fails first when a malicious GitHub Actions workflow is merged?

A: The first failure is trust, because the workflow itself becomes executable code with access to secrets before reviewers recognise it as hostile. Once a malicious job is merged, it can read repository credentials, run on push, and exfiltrate data without needing deeper platform compromise. The governing control is change approval for workflows, not just secret storage.

Q: Why do compromised developer accounts create outsized risk in software delivery pipelines?

A: Compromised developer accounts are dangerous because pipeline trust often exceeds the visible permissions of the account itself. If a repository can invoke a CI/CD workflow that uses a privileged token, an attacker can alter code to capture that token and move into higher-value systems. The real risk is indirect privilege inheritance across interconnected tooling.

Q: What are the signs that a GitHub Actions workflow has been exposed to secret theft?

A: Look for unexpected outbound network requests, secret values appearing in build logs, and workflow runs that reference unfamiliar commit hashes or altered Action tags. Repositories using a compromised Action during the exposure window should be treated as high risk. Private repositories are not exempt, because secrets may still have been dumped during execution even if outsiders cannot see the logs.

Q: How should teams contain malicious workflow abuse after discovery?

A: Immediately disable the affected workflow, rotate every secret reachable from the repository, review recent runner activity, and check whether the same account modified other repositories. Containment should focus on stopping further secret access and removing the attacker’s ability to reuse the same automation path elsewhere.

Technical breakdown

How malicious GitHub Actions workflows steal secrets

A GitHub Actions workflow runs in response to events such as push or manual dispatch, and it can read repository secrets if the permissions and job design allow it. In a supply chain attack, the malicious file does not need custom malware or unusual tooling. It only needs to look legitimate, execute quickly, and send secret values to an attacker-controlled endpoint. That makes workflow review, event triggers, and secret exposure the actual control surface. If a workflow can access secrets before human review, the compromise window is created by design rather than by exploitation.

Practical implication: Treat workflow changes as privileged code changes and require review before any workflow can access production secrets.

Why compromised developer accounts are enough for CI/CD abuse

The attacker does not need to break GitHub itself when a developer account can modify workflow logic inside trusted repositories. Once the account is compromised, the attacker can enumerate secret names from existing automation, tailor the malicious job to those names, and trigger execution on push. That turns ordinary repository access into secret harvesting and later into broader cloud or package-ecosystem access. In practice, the weak point is not the password alone but the delegated authority attached to the account, the repository, and the automation path.

Practical implication: Reduce repository write access, tighten branching rules, and treat developer compromise as a direct path to CI/CD secret exposure.

Why runner selection and branch protection matter in workflow attacks

GitHub-hosted and self-hosted runners create different trust boundaries, but both can be abused if workflows can select them without restrictions. Branch protection helps because it inserts a review checkpoint before workflow changes merge, while runner policy helps prevent attackers from routing jobs through approved execution paths they should not be able to use. The architectural lesson is that runtime controls alone do not solve workflow trust. Control has to start at change approval and extend through runner choice, secret availability, and outbound network paths.

Practical implication: Use branch protection and runner allowlisting together so unreviewed workflow changes cannot reach secret-bearing jobs.

Threat narrative

Attacker objective: The attackers aimed to harvest reusable CI/CD and ecosystem credentials for downstream access, publishing abuse, and broader supply chain compromise.

1. Entry occurred through compromised developer GitHub accounts that could alter repository workflows without immediate suspicion.
2. Credential access came when the injected workflows enumerated secret names and exfiltrated 3,325 secrets from 817 repositories.
3. Impact followed through theft of package, cloud, and publishing credentials that could support further supply chain compromise.

Breaches seen in the wild

• GhostAction campaign 2025: Compromised GitHub accounts planted a fake security workflow in 817 repos, exfiltrating 3,325 CI/CD secrets including npm, PyPI and DockerHub tokens.
• 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).

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, not just secret storage, is the real control plane here: GhostAction shows that a repository can remain structurally vulnerable even when secrets are not publicly exposed. If unreviewed workflow changes can execute with secret access, the control failed before the theft began. Practitioners should treat workflow approval as part of identity governance, because it governs which automation is trusted to act.

GitHub Actions secret theft is a machine-identity problem disguised as developer activity: the breach used repository authority, workflow execution, and secret scope to convert a code change into credential abuse. That means CI/CD pipelines now need the same lifecycle thinking that IAM applies to other non-human identities: issuance, review, scope, and revocation. The practitioner takeaway is that automation trust must be explicitly governed, not assumed.

Malicious workflow camouflage is a distinct governance failure mode: the attack succeeded in part because the workflow presented itself as a security improvement. That is a human-use-of-NHI problem in practice, where a trusted automation object is used as the delivery mechanism for abuse. Security teams should assume that benign naming and familiar syntax are insufficient signals of trust, and require structural approval controls for workflow changes.

Branch review and runner policy are now perimeter controls for software delivery: the campaign demonstrates that CI/CD trust boundaries sit at the intersection of access control and execution control. A compromised account can become a production-secrets event when workflow updates merge without review and runners remain too easy to target. The field implication is clear: delivery pipelines need governance equal to their privilege.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Secrets Management Buyer's Guide

What this signals

Malicious workflow camouflage: the attack worked because a security-themed workflow could still be treated as trusted automation. That is the governance gap practitioners need to close, because naming conventions do not prove intent and event-driven execution can bypass the normal review instincts that teams rely on.

CI/CD access control has to move from repository-level permission checks to workflow-level trust policy. If a job can reach secrets simply because it exists inside a trusted repo, the control plane is too coarse for modern supply chain abuse. Teams should assume workflow files are now part of the identity boundary, not just the build system.

GitHub Actions security now depends on how tightly organisations gate workflow creation, runner choice, and secret scope. The practical signal is simple: if an attacker can convert a code change into credential theft, the pipeline is operating as an overpowered NHI with insufficient lifecycle controls.

For practitioners

• Require pull request review for workflow changes Block direct merges to workflow files and route every automation change through protected branches so a compromised account cannot silently add secret-exfiltration logic.
• Restrict secret access by workflow trust level Allow secrets only to reviewed and approved workflows, and deny unreviewed jobs from reading repository-level credentials or deployment tokens.
• Lock down runner selection paths Prevent workflows from selecting runners outside approved labels and monitor for unexpected GitHub-hosted execution in repositories that should not use it.
• Rotate exposed CI/CD secrets immediately after workflow compromise Treat any malicious workflow as a credential incident and revoke package, cloud, and publishing tokens that were reachable from affected repositories.
• Monitor for suspicious outbound calls from automation jobs Alert on workflow jobs that contact unfamiliar domains, especially when the job name or commit message suggests security hardening rather than feature delivery.

Key takeaways

• GhostAction shows that a trusted-looking workflow can become the delivery mechanism for credential theft inside CI/CD.
• The campaign affected 327 GitHub users, 817 repositories, and 3,325 secrets, which makes the issue one of scale as well as technique.
• Protected branches, workflow review, and narrow secret scope are the specific controls that reduce the blast radius of this attack pattern.

Key terms

• Malicious Workflow: A malicious workflow is an automation file in a CI/CD system that appears routine but is designed to execute attacker-controlled actions. In GitHub Actions, it can read secrets, contact external endpoints, and abuse the trust granted to repository automation.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.
• Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
• Runner Policy: Runner policy is the set of rules that determines which execution environments a CI/CD job may use. Strong policy limits where workflows run, which labels they can request, and whether unreviewed automation can reach sensitive secrets or network paths.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need a stronger control model. It helps security teams connect identity governance to the operational decisions that shape risk.