Notifications
Clear all
Topic starter
20/08/2026 5:53 pm
TL;DR: Deleted or disabled GitHub Actions workflows can still be triggered through certain pull request paths, according to Sonar’s analysis, creating a hidden attack surface that can execute arbitrary code in runner environments and expose repository secrets. The risk is not just a workflow bug but a CI/CD governance gap that leaves privileged automation, and the identities behind it, outside lifecycle control.
NHIMG editorial — based on content published by Sonar: Zombie workflows in GitHub Actions and the hidden CI/CD attack surface
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a GitHub Actions workflow is fixed in only one branch?
A: The fix is incomplete because attackers may still trigger a vulnerable workflow version from another branch or historical state.
Q: Why do CI/CD pipelines create non-human identity risk?
A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically.
Q: How do security teams know if workflow secret handling is actually working?
A: Look for three signals: fewer long-lived secrets in workflows, strong inventory of which jobs can access which credentials, and successful use of short-lived federated auth for cloud access.
Practitioner guidance
- Audit every pull_request_target workflow Identify workflows that run on pull_request_target, check which branch version they resolve from, and confirm whether any stale branch still contains vulnerable logic.
- Backport workflow fixes across active branches Apply security fixes to all active release, hotfix, and feature branches, then verify that deleted or disabled workflows cannot still be triggered from older branch states.
- Split build execution from secret-bearing steps Move untrusted build and test logic into jobs that do not receive secrets or write-scoped tokens, and reserve privileged steps for tightly controlled workflows.
What's in the full article
Sonar's full analysis covers the operational detail this post intentionally leaves for the source:
- A step-by-step explanation of how pull_request_target resolves workflow files across branches and why that matters for attack surface.
- Concrete examples of vulnerable workflow patterns, including unsafe checkout choices and secret-bearing jobs in pull request contexts.
- The large-scale repo scanning method used to identify vulnerable branches and the thresholds that separated likely from confirmed exposures.
- The platform change GitHub made to alter default behaviour and how that shifts branch remediation requirements for maintainers.
👉 Read Sonar's analysis of zombie workflows in GitHub Actions →
Zombie workflows in GitHub Actions: what governance gap teams miss?
Explore further
20/08/2026 6:32 pm
Zombie workflows are a lifecycle failure in NHI governance, not a niche GitHub bug. A workflow file that remains triggerable after it has been fixed or deleted is a privileged automation identity that has outlived its intended control state. That matters because CI/CD systems routinely carry secrets, signing rights, and deployment authority. Practitioners should treat workflow lifecycle management as part of identity governance, not just repository hygiene.
A question worth separating out:
Q: Who is accountable when a workflow flaw exposes session secrets and code execution?
A: Accountability sits with the team that owns the workflow platform as part of the identity and execution surface, not just the application developer who wrote the form. If the platform can store authentication secrets and launch actions, it falls under privileged access governance and security review.
👉 Read our full editorial: Zombie workflows in GitHub Actions expose hidden CI/CD risk
