Notifications
Clear all
Topic starter
20/08/2026 5:27 pm
TL;DR: GhostAction compromised 327 GitHub users across 817 repositories and exfiltrated 3,325 secrets through malicious workflows that looked like security hardening, according to StepSecurity’s analysis. The incident shows that CI/CD pipelines now need workflow-level trust controls, not just secret storage and developer hygiene.
NHIMG editorial — based on content published by StepSecurity: GhostAction Campaign, over 3,000 secrets stolen through malicious GitHub workflows
By the numbers:
- GhostAction compromised 327 GitHub users across 817 repositories.
- The campaign exfiltrated 3,325 secrets including PyPI, npm, and DockerHub tokens.
Questions worth separating out
Q: How should security teams prevent secrets from reaching shared Git repositories?
A: Use a two-layer approach.
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.
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.
Practitioner guidance
- 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.
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
👉 Read StepSecurity's analysis of the GhostAction GitHub workflow supply chain attack →
GitHub Actions secret theft: what security teams need to change?
Explore further
20/08/2026 6:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GhostAction shows how GitHub workflows can turn into secret theft
