GitHub is adding a human checkpoint before certain suspicious Actions workflows can run in public repositories.
The company announced on July 28, 2026, that workflow runs it identifies as potentially malicious will be held before execution. A repository collaborator with write access must review and approve the run through an authenticated GitHub web session before it can proceed.
The safeguard requires no configuration and currently applies only to public repositories on GitHub.com. GitHub Enterprise Server does not receive the protection.
Repository owners still need to decide who should review held runs and what evidence should be required before approval. That responsibility falls primarily on open-source maintainers, organization administrators, DevOps teams and security leaders overseeing CI/CD permissions and software supply chain risks.
How GitHub’s workflow hold works
When GitHub flags a run, the workflow remains paused until an authorized collaborator approves it. Once approved, it continues normally.
GitHub has not disclosed the detection signals, thresholds or expected false-positive rate behind the safeguard. The hold therefore adds a review checkpoint but does not guarantee that every malicious workflow will be detected.
The company linked the change to attacks in which compromised GitHub credentials were used to push malicious workflow files. That risk was demonstrated in May when an npm supply chain attack targeted developer credentials, including GitHub tokens, API keys and internal secrets.
Attacker-controlled workflow execution may expose cloud credentials, package registry tokens or a repository’s GITHUB_TOKEN, according to security guidance from OWASP. The potential reach of stolen credentials became clearer after a GitHub flaw exposed developer OAuth tokens, which could have provided access to private repositories and organizational code.
The automatic hold is separate from a June 18 update to actions/checkout. Version 7 and updated supported versions reject common configurations that retrieve unreviewed fork code during privileged pull_request_target or certain workflow_run executions.
That attack pattern is commonly called a “pwn request.” The actions/checkout change blocks specified fork head and merge checkouts, but it does not prevent every method of retrieving and executing untrusted code.
What repository owners should check
Define approval criteria. Review who initiated the run, what changed under .github/workflows/, which permissions it requests and whether it downloads or executes unfamiliar code. Escalate unclear cases instead of approving them simply to clear the queue.
Audit unsafe overrides. Workflows can bypass the safer actions/checkout behavior with the allow-unsafe-pr-checkout input. GitHub describes opting out as a deliberate security decision, so each use should have a documented purpose, owner and risk review.
Check pinned versions. Workflows using a supported floating major tag, such as actions/checkout@v4, received the backported protection automatically. References pinned to a commit SHA, minor version or patch version require an update. Version 1 does not receive the change.
Test execution policies. GitHub’s separate workflow execution protections allow administrators to control which actors can trigger workflows and which events are permitted. Similar access-policy gaps recently left Azure accounts exposed when Conditional Access rules failed to cover a command-line authentication path.
GitHub’s policies remain in public preview, and users with repository write access can trigger workflows by default. Evaluate mode allows administrators to identify what a proposed rule would block before enforcing it.
GitHub Enterprise Server administrators should review the protections available in their installed version rather than assume the GitHub.com safeguard applies to them. Public repository owners should assign authorized reviewers, document the evidence required for approval and establish an escalation path before the first suspicious run is held.
Read more: A separate incident shows what compromised repository access can enable after a stolen GitHub token exposed Grafana’s codebase.
