Zombie workflows in GitHub Actions expose hidden CI/CD risk

At a glance

What this is: This analysis shows how so-called zombie workflows in GitHub Actions can still run after deletion or deactivation, turning stale CI/CD definitions into an exploitable execution path.

Why it matters: It matters because CI/CD pipelines often hold secrets, write permissions, and deploy authority, so stale workflow governance can become a repository-level compromise path for both human and non-human identities.

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.

👉 Read Sonar's analysis of zombie workflows in GitHub Actions

Context

Zombie workflows are a CI/CD governance problem, not just a GitHub Actions quirk. A workflow can appear fixed or deleted while older branch versions, pull request routing, or historical trigger resolution still leave an execution path open to attackers who can modify repository content or influence base-branch selection. In identity terms, this is a lifecycle failure for privileged automation, where repository-bound NHI-like credentials and write-scoped tokens outlive the control state meant to constrain them.

The practical risk is amplified in repositories that use pull_request_target, reuse secrets in build jobs, or allow workflow changes without strong branch protection. Sonar’s findings show why teams cannot treat workflow remediation as complete when only the default branch is updated. That is typical of fast-moving engineering environments, but atypical from a secure governance perspective because the control boundary is assumed, not enforced.

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. That leaves privileged automation exposed even though the default branch looks safe. Teams need branch-wide remediation, not a single-file patch, because workflow execution can follow branch resolution rules that preserve old attack paths.

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. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

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. If secrets still appear in runner logs, environment variables, or ungoverned third-party actions, the control is not working as intended.

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.

Technical breakdown

How pull_request_target can re-open old workflow versions

GitHub Actions resolves workflow execution from the base branch for pull request events, which is intended to prevent untrusted changes from redefining the workflow itself. The problem is that if a vulnerable workflow exists in another branch, or if the default-branch fix was not propagated everywhere, the runner can still execute a historical version that contains unsafe logic. This is especially dangerous when the workflow checks out the pull request head and then runs build steps that interpret attacker-controlled code. The result is arbitrary code execution in a privileged automation context.

Practical implication: audit every branch that can serve as a workflow source, not just main.

Why secrets and write tokens make CI/CD compromise worse

A workflow becomes high impact when it combines code execution with secrets or repository write permissions. In GitHub Actions, that can include deployment credentials, signing keys, or a GITHUB_TOKEN with write scope. Once a malicious pull request reaches a vulnerable runner, the attacker can read environment values, modify repository content, or chain access into downstream systems that trust the pipeline. This is an identity problem as much as a code problem, because the workflow itself functions like a privileged non-human identity with a lifecycle and authorization boundary that must be governed.

Practical implication: separate untrusted build steps from secret-bearing release steps and reduce token scope to read-only wherever possible.

Why deleted workflows can still behave like zombie workflows

A deleted or disabled workflow is not automatically equal to a removed attack path if the platform still resolves execution against historical branch state or unreviewed branch variants. That creates what Sonar calls a zombie workflow pattern, where a fix exists in one branch but a vulnerable copy remains triggerable elsewhere. In practice, the attack surface persists whenever branch topology, event selection, and permissions are treated as independent decisions rather than a single governed control set. Secure workflow management therefore depends on branch-level consistency, not just file deletion.

Practical implication: enforce branch protection, require review on workflow changes, and verify that fixes are backported across active branches.

Threat narrative

Attacker objective: The attacker wants privileged code execution inside the CI/CD runner so they can steal secrets, hijack repository trust, or pivot into supply chain compromise.

1. Entry occurs when an attacker gains a path to influence a repository branch or open a pull request that targets a vulnerable workflow.
2. Credential access follows when the workflow executes with secrets, write-scoped tokens, or other privileged environment data available to the runner.
3. Escalation and impact occur when the attacker uses that execution context to run arbitrary code, exfiltrate sensitive values, or alter repository and release outcomes.

NHI Mgmt Group analysis

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.

Standing write access in CI/CD remains the control weakness that attackers look for first. Sonar’s analysis reinforces that the dangerous combination is not only code execution, but code execution inside a pipeline that still holds elevated permissions. In governance terms, this is the same class of problem as unmanaged service accounts or over-privileged tokens: the credential is valid longer than the risk window is acceptable. Teams should map workflow permissions to least privilege and revocation discipline.

Branch consistency is the named concept teams need to operationalise. Fixing one branch while leaving older or unreviewed branches untouched creates branch consistency debt, a condition where security posture varies by branch history instead of policy. That makes remediation incomplete by design. Security and platform teams should require that workflow controls, permissions, and trigger rules are synchronised across every active branch before a fix is considered closed.

Platform-level changes can reduce exposure faster than per-repo remediation, but they do not replace governance. GitHub’s default-branch behaviour change reduces the chance that historical branch variants remain exploitable, which helps close a broad class of workflow abuse. Even so, teams still need branch protection, secret scoping, and review controls because the same pipeline patterns can fail in other ways. The lesson is to align platform defaults with enterprise policy, then verify the residual risk at repo level.

What this signals

Branch-level workflow drift is now a governance signal that platform teams should track. If one branch can still execute a privileged workflow while another is fixed, then pipeline security is being decided by repository history rather than policy. The practical response is to measure workflow parity across branches, especially where secrets, signing keys, or release permissions are involved.

Secret-bearing automation should be treated as an identity inventory problem, not only a DevOps concern. Workflow tokens and deployment credentials need ownership, expiry, and revocation discipline just like any other privileged identity. Teams that already struggle with secrets sprawl should expect CI/CD to surface the same pattern in a higher-impact form.

Persistent trigger paths in GitHub Actions make least privilege a moving target. The more a workflow depends on pull request context, the more carefully teams need to separate untrusted execution from trusted release steps. That is why platform defaults, branch protection, and secret scoping must be reviewed together instead of as isolated controls.

For practitioners

• 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.
• Tighten branch protection for workflow files Require review on workflow changes, restrict who can modify .github/workflows files, and enforce checks that block direct merges of unreviewed pipeline changes.
• Review pipeline tokens as NHI assets Inventory GitHub Actions tokens, deployment keys, and signing credentials as non-human identities with owners, scopes, and expiry expectations, then revoke anything that no longer has a valid use case.

Key takeaways

• Zombie workflows show that a fixed pipeline can still remain exploitable if branch-level remediation is incomplete.
• The impact comes from privileged automation holding secrets and write access, which turns CI/CD into a high-value identity target.
• Teams need branch-wide workflow governance, tight token scope, and strong modification controls to close the gap.

Key terms

• Zombie Workflow: A zombie workflow is a pipeline definition that appears fixed, deleted, or disabled but can still be triggered through a branch, event, or historical resolution path. The term describes a governance failure where the old privileged behavior remains available even though the team believes the workflow is no longer active.
• Pwn Request: A pull request or related contribution flow that can execute attacker-controlled content in a privileged build context. The risk appears when workflow design lets untrusted input reach shell commands, secrets, or release tooling without a clean trust boundary.
• Branch Consistency Debt: Branch consistency debt is the gap that appears when security fixes, trigger rules, or permission changes are applied in one branch but not across the rest of the repository. It creates inconsistent enforcement, so a vulnerable workflow can remain reachable from an older or unreviewed branch.
• Secret-Bearing Automation: Secret-bearing automation is any pipeline, job, or workflow that can access deployment keys, signing material, tokens, or other sensitive credentials during execution. In identity terms, it should be governed like a privileged non-human identity with explicit ownership, scope, and revocation requirements.

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.

👉 The full Sonar article breaks down the branch-resolution behavior, vulnerable workflow patterns, and remediation logic.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security practitioners connect privileged automation controls to wider identity and access management programmes.