A credential-theft campaign tracked as GhostAction has been planting malicious GitHub Actions workflows into open-source repositories at scale. Early reporting described a malicious workflow pushed into over 340 repositories via two compromised maintainer accounts; subsequent analysis showed the campaign ramping up to target more than 30,000 repositories across roughly 3,000 users and organizations, with a related wave hijacking 790 repositories to steal cloud credentials, software-publishing tokens, and AI API keys.
Strip away the scary numbers and the mechanism is almost mundane, which is exactly why it works: a workflow file — a piece of CI/CD configuration that most reviewers skim past — was modified to read the secrets your pipeline already has and ship them to an attacker. No malware on a laptop, no zero-day in a runtime. Just a .github/workflows/*.yml file doing what workflow files are allowed to do, pointed at the wrong destination.
This post is about why your CI/CD pipeline is one of the most privileged and least-watched identities in your environment, how GhostAction abused that, and the concrete steps that stop a poisoned workflow from draining your cloud. The reassuring part: this is defensible with controls you can put in place this sprint.
What Happened
GitHub Actions runs workflows defined in YAML files inside each repository, under .github/workflows/. Those workflows execute automatically on events — a push, a pull request, a release, a schedule — and they run with access to the repository’s secrets: the tokens, cloud credentials, and publishing keys that CI/CD needs to build, test, and deploy. That access is the whole point of CI/CD. It is also the whole prize for an attacker.
GhostAction chained a few simple moves:
1. Compromise a maintainer or contributor account. The campaign got into open-source maintainer accounts (through phishing and stolen credentials) and, in related waves, hijacked a contributor’s account to tamper with an official tool’s releases. Once you control an account with write access, you control what gets committed — including workflow files.
2. Plant a malicious workflow. The attacker added or modified a workflow so that on the next trigger, it would collect the repository’s configured secrets — cloud credentials, package-publishing tokens, AI service API keys — and exfiltrate them to an attacker-controlled endpoint. Because this is just another workflow change, it blends into normal commit traffic, especially in busy repositories.
3. Let CI/CD do the work. The next time the workflow ran, the pipeline — trusted, automated, and holding real secrets — handed those secrets to the attacker. No human had to click anything. The automation that makes CI/CD valuable is exactly what made the theft silent and scalable.
4. Scale across the ecosystem. By repeating this across thousands of repositories, the campaign turned individual account compromises into a mass harvest of cloud credentials and publishing tokens — some of which can then be used for further supply-chain attacks (publishing poisoned packages, tampering with more releases), compounding the damage outward.
The targets tell the story: cloud credentials, publishing tokens, and AI API keys. These are precisely the high-value, broadly-scoped, long-lived secrets that pipelines tend to hold — and that most teams never rotate because “the pipeline needs them.”
Why Your CI/CD Pipeline Is a Privileged Identity Nobody Watches
Here is the uncomfortable reframing: your CI/CD pipeline is one of the most powerful identities in your organization, and it is almost certainly one of the least governed.
Think about what a deploy pipeline can do. It can push code to production. It can publish packages that your customers install. It can assume cloud roles to provision infrastructure, write to buckets, and touch databases. To do all that, it holds secrets — and those secrets are typically:
- Long-lived. A pipeline’s cloud key or publishing token is set once and left in place, often for years, because rotating it means touching every workflow that uses it.
- Broadly scoped. It is easier to give the pipeline a powerful role that covers every job than to scope each job narrowly. So the deploy credential can usually do far more than any single workflow needs.
- Widely readable within the repo context. Every workflow that runs in the repository can read the repository’s secrets. A malicious workflow is just another workflow — it inherits the same access.
- Unattended. No human is watching when a workflow runs at 3 a.m. on a push. There is no one to notice that this particular run also made an outbound request to an unfamiliar host.
Put those together and you get a non-human identity with production-level power, durable credentials, broad scope, and no one watching it in real time. That is the governance gap GhostAction drove straight through. Securing CI/CD is, at its core, an identity problem — the same standing-credential problem that causes so many breaches, just wearing a YAML hat.
The Immediate Checklist
These are the steps that directly address the GhostAction pattern. Work through them in order; most take an afternoon, not a project.
1. Rotate pipeline secrets, assuming exposure
If any repository you touch was in scope — or if you simply cannot prove it was not — rotate the secrets your pipelines hold: cloud access keys, package-publishing tokens, AI API keys, signing keys. Rotate first, investigate second. A long-lived pipeline credential that might have leaked is one you should treat as burned.
2. Audit your workflow files for unexpected changes
Review .github/workflows/ across your repositories for recent modifications, especially ones that add network calls, encode or base64 secrets, or send data to unfamiliar endpoints. Diff against known-good history. Pay special attention to changes from accounts that do not normally touch CI configuration.
3. Require review for workflow changes specifically
Workflow files should be among the most carefully reviewed files in the repo, not the least. Protect .github/workflows/ with branch protection and require review from someone who understands CI security for any change to it. A workflow-file edit deserves the same scrutiny as a change to authentication code. This is a core reason repository-level RBAC matters in multi-team orgs — not everyone who can commit should be able to silently rewrite the pipeline.
4. Scope pipeline credentials to the minimum each job needs
Stop giving the whole pipeline one powerful credential. Scope each job’s access to exactly what it needs: the build job does not need deploy permissions; the deploy job does not need publishing tokens. Least privilege in CI/CD means a poisoned workflow in one job steals a small, narrow credential instead of the keys to everything.
5. Prefer short-lived, federated credentials over stored secrets
Where your platform supports it, use OIDC federation so the pipeline exchanges a short-lived, workload-identity token for cloud access at run time instead of reading a stored long-lived key. A token that is minted per-run and expires in minutes is far less valuable to exfiltrate than a static key that lives in repository secrets indefinitely. This is the CI/CD version of governing pipeline credentials without standing secrets.
6. Pin and verify third-party actions
Reference third-party actions by full commit SHA, not a mutable tag like @v3 that can be silently re-pointed at malicious code. Maintain an allowlist of permitted actions. This closes the related vector where a trusted action is swapped out from under you. For the broader framing, see what is software supply-chain security.
The Structural Fix: Treat the Pipeline Like the Identity It Is
The checklist hardens the pipeline you have. The structural work is to stop treating CI/CD secrets as set-and-forget configuration and start treating the pipeline as a first-class non-human identity that is governed, scoped, and short-lived by default.
Two things make the GhostAction class of attack pay off: standing secrets (long-lived credentials sitting in repository configuration, waiting to be read) and broad scope (a single credential that can touch far more than any one job needs). Remove both and a poisoned workflow steals something that is either already expired or too narrow to matter.
That is where correlated code-to-cloud security changes the picture. A finding in your pipeline configuration is only as meaningful as what it can reach — and seeing that connection is the difference between “someone changed a YAML file” and “someone changed a YAML file that can read a credential which can assume an admin role in production.”
Cloudanix Code Security brings secret detection, static analysis, and CI/CD posture into your development workflow, so a credential-exfiltration pattern or a dangerous workflow change is caught in the pull request rather than after a run has already shipped your secrets out. Pairing that with secret-aware PR quality gates that fail the pull request on any leaked secret means a workflow that tries to introduce or expose a credential does not merge in the first place.
The part that makes this more than another scanner is correlation. Because Cloudanix maps findings across code and cloud on one asset graph — the basis of code-to-cloud security and the correlation that connects GitLab or GitHub code findings with cloud posture — you can see the full path: this workflow → reads this secret → which grants this role → which reaches this data. That path is the blast radius, and knowing it tells you both how urgent a given pipeline risk is and exactly which credential to scope down first.
For the credentials themselves, the same short-lived model that protects human and cloud access applies to pipelines: rather than embedding a durable key in repository secrets, governing non-human identities with JIT issues scoped, short-lived credentials to the service accounts and pipelines that need them, so there is far less standing secret for a poisoned workflow to steal. It all reports into the broader CNAPP+ platform, so pipeline identity, cloud posture, and the data behind them live in one correlated view instead of three disconnected tools.
Being Honest About What This Covers
We would rather you deploy this understanding the boundary.
What correlated code security and scoped, short-lived credentials genuinely change: the value and reach of what a poisoned workflow can steal. Catch the dangerous change in review, scope each job narrowly, and mint credentials short-lived, and a GhostAction-style workflow exfiltrates something expired or trivial instead of a durable admin key. You also get the blast-radius picture, so you fix the credential that actually leads somewhere first.
What still needs the fundamentals: account security remains your first line. GhostAction started with compromised maintainer and contributor accounts, so phishing-resistant MFA, strong authentication, and careful management of who has write access are non-negotiable. No amount of credential hygiene helps if an attacker can push an approved-looking workflow change through a hijacked account with weak review. Think of account security as controlling who can change the pipeline, and scoped short-lived credentials as controlling what the pipeline can lose when a change slips through.
Being precise about this is deliberate. We are not promising that no account will ever be compromised. We are describing how to make a compromised pipeline leak as little as possible.
Key Takeaways
- A workflow file is privileged code. GhostAction abused the simplest fact about CI/CD: workflows run automatically and can read the repository’s secrets. Review them like authentication code.
- Your pipeline is an under-governed identity. It holds long-lived, broadly-scoped secrets with production-level power and no one watching at run time. That is the gap.
- Rotate, audit, and scope now. Rotate pipeline secrets on suspicion, audit workflow diffs, and scope each job to the minimum it needs.
- Short-lived federated credentials beat stored keys. A per-run token that expires in minutes is a far smaller prize than a static key sitting in repository secrets.
- Correlation tells you the real blast radius. Seeing which secret a workflow can read, and what that credential can reach, is what turns “a YAML changed” into a prioritized, actionable fix.
Want to see which of your pipeline credentials can reach production — and catch a dangerous workflow change before it merges? Book a demo to see Cloudanix code-to-cloud correlation and code security on your own repositories.
People Also Read
- Governing CI/CD Pipeline Credentials Without Standing Secrets
- Governing Non-Human Identities with JIT: Service Accounts, Pipelines, and Internal Products
- Code-to-Cloud Security Explained: Following a Vulnerability from GitLab to a Running ECS Task
- Why Repository-Level RBAC Matters in Code Security for Multi-Team Orgs
- What is Software Supply-Chain Security?
- What is Code Security?
- Cloudanix: Code Security
