# GitHub Actions begins holding suspicious workflows for approval > GitHub now pauses potentially malicious workflow runs in public repositories until a collaborator with write access reviews them in the web interface. Canonical URL: https://www.devobs.io/news/news-github-actions-malicious-workflow-hold/ By: Ines Costa Published: 2026-09-06T11:58:54.642Z Updated: 2026-09-06T11:58:54.642Z Event date: 2026-07-28 Section: Security GitHub announced on July 28 that Actions can automatically hold a workflow it identifies as potentially malicious in a public repository. The run stays paused until a collaborator with write access reviews and approves it through an authenticated GitHub web session. The [changelog](https://github.blog/changelog/2026-07-28-github-actions-holds-potentially-malicious-workflows-for-approval/) limits the rollout to public repositories on `github.com`; it does not apply to GitHub Enterprise Server. ## A pause creates a review point Public repositories routinely execute contributions from people without repository access. A hold can interrupt suspicious behavior before a runner starts, giving maintainers a chance to inspect workflow changes and the code they invoke. It also adds a new operational state: a job may be neither queued normally nor failed, but waiting for a privileged decision. GitHub does not present the detection as a complete malware verdict. Maintainers should not infer that an unheld workflow is safe, or that every held workflow is hostile. Existing token permissions, fork policies, protected environments, and dependency pinning still determine the available blast radius. ## Define how maintainers investigate Route hold notifications to a maintained queue and document who can approve them. A reviewer should inspect changes to workflow YAML, referenced actions, scripts executed during install or build, downloaded artifacts, and any interpolation of contributor-controlled values. Approval should follow the repository's normal trust model, not urgency to clear a red status. Measure false positives and time-to-review so legitimate contributors are not left indefinitely blocked. If a safe pattern triggers repeated holds, simplify it or raise evidence through GitHub's feedback path rather than teaching reviewers to approve reflexively. Sensitive jobs should remain separated behind environments or workflows that do not execute untrusted code. The feature is a useful additional checkpoint only when approval carries an actual technical review. ## Source references -