By ByteBot
On July 28, GitHub shipped a new default protection for GitHub Actions security: workflow runs it identifies as potentially malicious are now held before execution. A collaborator with repository write access must review and approve the run through an authenticated web session before it proceeds. No configuration required — the safeguard is live right now for all public repositories on GitHub.com.
This is not a precautionary measure for theoretical risks. Three supply chain attacks exploiting GitHub Actions have already defined 2026, and GitHub’s new hold mechanism is a direct response to them.
How the Workflow Hold Works
When GitHub detects a potentially malicious run, it intercepts execution before any code runs. The held workflow sits in a queue, and a repository collaborator with write access receives a notification to review it. Approval requires an authenticated GitHub web session — not an API call, not a script. Once approved, execution continues normally.
The protection requires zero setup. No workflow changes, no organization settings to toggle, no opt-in process. According to the GitHub Changelog announcement, GitHub applies it automatically across all public repositories. For most teams, the first sign this feature exists will be a held run appearing in their Actions dashboard.
Related: GitHub Actions Gets a Lockfile: Workflow Dependency Locking in Preview
The Attacks That Made This Necessary
Three incidents drove GitHub to act. In March, attackers hijacked 75 of 76 version tags in aquasecurity/trivy-action — a widely used security scanner — affecting over 10,000 downstream workflows. In May, the TanStack supply chain attack was more surgical: attackers chained a pull_request_target misconfiguration, GitHub Actions cache poisoning, and direct OIDC token extraction from runner memory to publish 84 malicious versions across 42 @tanstack packages in under six minutes. According to the TanStack postmortem, by end of day, 170+ packages across npm and PyPI were compromised, including Mistral AI, UiPath, and Guardrails AI. In July, the AsyncAPI repository fell to 37 malicious pull requests, one of which stole a privileged access token and published malicious packages to a namespace with three million weekly downloads.
The pattern across all three is identical: compromise developer credentials, push a malicious workflow file, harvest CI/CD secrets — cloud credentials, registry tokens, GITHUB_TOKEN — and use them to compromise downstream systems. Datadog Security Labs found that 38% of organizations have at least one GitHub Actions workflow currently vulnerable to script injection. The holds feature targets this attack vector at the execution layer.
The Part GitHub Didn’t Tell You
GitHub has not disclosed what triggers a workflow hold. No detection signals, no thresholds, no expected false-positive rate. The announcement says only that it targets “potentially malicious” runs and that the safeguard “does not guarantee that every malicious workflow will be detected.” Teams learn the detection exists — but not how it decides.
That opacity creates a real operational gap. A high-frequency pipeline — monorepo with matrix builds, automated release workflows, dependency update bots — could be interrupted without warning or explanation. There is no feedback mechanism, no way to see why a specific run was flagged. Zero-config is a meaningful advantage when something breaks at 2 AM, but it becomes a liability when a legitimate production deployment gets held and no one can explain why.
Teams should establish clear approval policies before this fires — not after. Identify who holds write access to each repository, determine the expected response time for a held run, and document what evidence is sufficient before approving. The approval accountability now sits entirely with whoever has write access to the repository.
Who Has It Now, and What’s Coming
The workflow holds feature currently applies only to public repositories on GitHub.com. GitHub Enterprise Server is excluded, with no timeline announced for enterprise customers. If your team runs private repositories or self-hosted infrastructure, this protection is not yet available.
However, the holds feature is the second deliverable on GitHub’s 2026 Actions security roadmap. Workflow dependency locking — which pins action versions to commit SHAs — entered preview on August 2. Still on the roadmap: scoped secrets that bind credentials to specific branches, environments, or workflow identities; and a native Layer 7 egress firewall that blocks unauthorized outbound connections from runners even if an attacker gains root access inside. The holds feature closes one gap. The full picture requires the rest of the roadmap.
Key Takeaways
- GitHub Actions now holds potentially malicious workflow runs by default — all public repos on GitHub.com, live as of July 28, no configuration needed
- Approvals require a write-access collaborator using an authenticated web session; establish who that is and how fast they can respond before a hold actually fires
- GitHub has not disclosed detection signals or false-positive rates — teams cannot predict or tune what gets held
- GitHub Enterprise Server is excluded; teams on private infrastructure still need to rely on other controls like action pinning and OIDC federation
- This is one piece of a larger 2026 roadmap — dependency locking in preview now, scoped secrets and egress firewall still ahead
