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.
Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “Zombie Workflows: A GitHub Actions horror story”.
By the numbers:
- Sonar found 188 vulnerable workflows during its large-scale triage, before narrowing them to 67 true Zombie Workflows.
Key questions
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 pull_request_target workflows create more risk than standard pull request workflows?
A: pull_request_target runs in the base repository context, which can expose secrets and write-enabled tokens to code that came from a fork.
Q: How can teams tell whether zombie workflow risk is still present?
A: Look for any workflow that can still be triggered from branches other than the default branch, especially if it uses pull_request_target, checks out PR code, or accesses secrets.
Practitioner guidance
- Audit every executable branch for stale workflows Map all branches that can still trigger GitHub Actions, not just default branch content, and flag any workflow file that remains runnable after a fix.
- Reduce privileged pull request automation Replace broad pull_request_target usage with the least privileged trigger that still supports the workflow, and separate untrusted PR code from any step that can read secrets or write to the repository.
- Treat workflow retirement as revocation When a workflow is fixed or removed, verify that the change is not stranded in older branches and that historical versions cannot still be selected by a pull request path.
Bottom line: Zombie workflows show that CI/CD privilege can persist in branch history even after teams believe a workflow has been removed or fixed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:32 pm
Zombie workflows are a lifecycle revocation failure, not a simple misconfiguration. The real issue is that teams can fix one branch while leaving other executable branch states alive. That creates a privilege residue problem in CI/CD, where retired automation still carries access. Practitioners should treat workflow retirement as revocation across every branch that can still execute code.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should security teams do when a privileged workflow is discovered in branch history?
A: Treat it as a lingering access path and verify whether it can still be selected by a pull request against any live branch. If it can, revoke the automation path by updating every branch that can execute the workflow and removing unnecessary secrets or write permissions. Containment starts with cutting off reachability, not just editing the current file.
👉 Read our full editorial: Zombie workflows in GitHub Actions expose hidden CI/CD risk