Why Did GitHub Actions Hold Your Workflow for Approval? The New Security Gate Explained

If a GitHub Actions run suddenly says it needs approval, do not assume something is broken—and do not assume the run is safe just because GitHub offers an Approve button.

GitHub added a new automatic protection on July 28, 2026 that can hold certain workflow runs in public repositories on github.com when they are identified as potentially malicious. A held workflow does not execute until a repository collaborator with write access reviews and approves it through an authenticated web session.

The protection requires no repository configuration. GitHub applies it automatically. As of August 17, 2026, GitHub says this particular protection does not apply to GitHub Enterprise Server.

The confusing part is that GitHub already had other approval flows for Actions. A fork pull request, a bot-created pull request, an environment deployment, and this new security hold can all produce some version of “approval required,” but they are not the same mechanism.

The quick answer

When a workflow is unexpectedly held, first identify why GitHub is asking for approval.

The new July 28 gate is important because it can appear even when a repository owner did not configure a new rule.

Why GitHub added the new hold

GitHub says recent software supply-chain attacks have used compromised GitHub credentials to push malicious workflow changes. Once a malicious Actions workflow runs, it can try to steal CI/CD credentials and use those credentials for additional attacks.

That attack path is particularly dangerous because CI is often trusted with things ordinary source code is not: package-publishing credentials, cloud identities, deployment tokens, repository write access, signing material, and access to internal systems.

The new protection inserts a human interruption before some suspicious runs start.

That is useful, but the wording matters: “potentially malicious” is a review signal, not a verdict. A legitimate workflow can require review, and a workflow that is not held should not be treated as proven safe.

What to inspect before clicking Approve

A useful review should answer one question:

What code will this workflow execute, with which privileges, because of which change?

Use this six-step check before approving an unexpected hold.

1. Inspect the triggering commit and the workflow diff

Start with the commit, pull request, or event that triggered the run. Look specifically for changes under:

.github/workflows/

Do not review only the application code. A one-line workflow change can matter more than a hundred-line feature diff if it changes permissions, secrets, checkout behavior, or where commands come from.

Watch for additions such as:

• new run: shell commands;
• curl, wget, npm, pip, bash, or PowerShell downloading and executing remote content;
• changed action references;
• new environment variables populated from secrets;
• artifact or cache manipulation;
• changed cloud-login or package-publishing steps;
• new workflow_dispatch, issue_comment, workflow_run, or pull_request_target triggers.

A workflow change can be legitimate. The point is to understand it before granting execution.

2. Check who triggered the run and whether that was expected

Ask whether the actor, event, and timing make sense.

A maintainer pushing an expected release change is different from an unfamiliar account modifying deployment automation. A compromised trusted account can still have write access, so “the actor is a collaborator” is not enough by itself.

If the change is surprising, verify it through a second channel before approval—especially when it touches publishing or deployment credentials.

3. Check the workflow's effective privileges

Review the workflow's permissions: block and the capabilities of any secrets or identities it receives.

GitHub recommends giving GITHUB_TOKEN the least privileges necessary. Also look beyond GITHUB_TOKEN: a workflow may obtain cloud credentials through OIDC, access package registries, receive environment secrets, or call a GitHub App with broader permissions.

A useful mental model is:

The more authority the job has, the more evidence should be required before approval.

4. Treat pull_request_target as a special warning sign

GitHub calls pull_request_target one of the most commonly misused Actions triggers.

The reason is subtle: the event runs in the context of the base repository, with its GITHUB_TOKEN, secrets, and default-branch cache access. If that privileged workflow then checks out and executes unreviewed code from a fork, an attacker can turn a normal pull request into code execution with elevated privileges—a pattern often called a pwn request.

GitHub hardened actions/checkout in 2026 so supported versions refuse several common unsafe fork-checkout patterns by default. But GitHub explicitly notes that this does not cover every way untrusted code can be fetched and executed. A workflow can still use git, the gh CLI, another action, or a custom script to reproduce the same dangerous pattern.

So if a held run uses pull_request_target, verify that it does not execute untrusted pull-request code with privileged credentials.

5. Check what changed in third-party actions and dependencies

A workflow can execute code without containing much shell script itself. Every referenced action is part of the execution chain.

Review newly introduced or changed actions, reusable workflows, package installers, and downloaded binaries. Prefer pinned and maintained dependencies appropriate to the project's security model, and keep security-sensitive actions such as actions/checkout current enough to receive GitHub's hardening changes.

GitHub has also expanded Dependabot's malicious-package alerts using data from the OpenSSF malicious-packages project. That is useful for dependency detection, but it is a separate control from reviewing what a workflow is about to execute.

6. If the hold is unexplained, do not approve it just to “unstick CI”

A blocked CI run is inconvenient. A compromised publishing or deployment credential is worse.

If nobody can explain a suspicious workflow change, leave it held and investigate the account, commit, referenced actions, and credentials involved. If related suspicious automation has already executed elsewhere, credential rotation and incident response may be appropriate depending on what the workflows could access.

The approval button should be treated as a security decision, not a retry button.

This is different from ordinary fork approval

Public repositories have long been able to require approval for workflows triggered by pull requests from forks. GitHub's documentation describes maintainers with write access reviewing and approving those runs before they execute.

That mechanism is largely about the trust boundary between a repository and outside contributors.

The July 28 protection addresses a different problem: a workflow that GitHub identifies as potentially malicious can be held even though the attack may involve compromised trusted credentials.

That distinction is important because many supply-chain attacks do not begin with an obviously untrusted GitHub account. They begin by taking over an account that already has authority.

GitHub is adding several layers, not one magic detector

The automatic hold is part of a broader set of Actions supply-chain changes GitHub has rolled out in 2026.

Safer pull_request_target checkout behavior

actions/checkout now rejects several common patterns that fetch fork PR code inside privileged pull_request_target and related workflow_run contexts. GitHub backported the protection to supported major versions in July, while workflows pinned to a specific SHA, minor version, or patch may need an explicit upgrade.

Read-only cache tokens for untrusted triggers

GitHub changed cache access so workflow events that can be triggered by people without repository write access receive read-only access to the default branch cache. The goal is to reduce cache-poisoning paths that can bridge an untrusted workflow into a more privileged one.

Configurable workflow execution protections

GitHub also introduced workflow execution protections in public preview. Administrators can define rules controlling which actors and which event types are allowed to trigger Actions.

Examples include restricting workflow_dispatch to maintainers or limiting pull_request_target across an organization.

This is different from the automatic malicious-workflow hold: one is an administrator-defined policy layer; the other is an automatic GitHub security intervention.

A practical hardening checklist

The new hold is useful, but the safer design is to make a compromised workflow less powerful in the first place.

For repositories with meaningful CI/CD credentials, review these controls:

• Set explicit, least-privilege permissions: for workflows and jobs.
• Avoid executing untrusted fork code inside privileged events such as pull_request_target.
• Keep actions/checkout and other security-sensitive actions updated.
• Review which jobs receive secrets, environment access, package-publishing authority, and cloud OIDC permissions.
• Separate build/test workflows from release/deployment workflows where practical.
• Use environment protection rules for high-impact deployments.
• Consider workflow execution protections when the organization needs tighter control over triggering actors or events.
• Enable Dependabot malware alerts when they fit the repository's security setup.
• Treat unexpected workflow-file changes as security-sensitive code review.
• Have a documented way to rotate CI/CD credentials when a workflow compromise is suspected.

The strongest defense is layered: reduce privilege, reduce untrusted execution paths, detect suspicious changes, and require human approval at the most dangerous boundaries.

What the new gate does not guarantee

The feature should not be interpreted as “GitHub will catch every malicious workflow.” GitHub describes it as a protection that holds certain workflow runs identified as potentially malicious.

It also does not remove the need to review trusted contributors' workflow changes. A supply-chain attack can start with compromised credentials, a malicious dependency, unsafe event handling, or an apparently harmless workflow modification.

And approving a held run does not transform the workflow into trusted code. Approval simply allows the run to proceed.

The useful mindset is:

A hold is a reason to investigate. No hold is not a security certificate.

What to watch next

Three developments are worth following.

Coverage expansion. GitHub currently documents the automatic hold for public repositories on github.com. It may broaden or refine the protection as the detection system evolves.

Policy adoption. Workflow execution protections are still in public preview. Organizations that adopt actor and event rules will provide an additional layer beyond automatic detection.

Supply-chain attack adaptation. Attackers change techniques when platforms close common paths. GitHub's 2026 changes to checkout behavior, caches, workflow execution and package malware detection are best understood as a moving defensive stack rather than a finished solution.

Conclusion

GitHub Actions asking for approval is no longer just a fork-contributor workflow issue.

Since July 28, GitHub can automatically hold certain potentially malicious runs in public github.com repositories, requiring a collaborator with write access to review them through the web before execution.

That extra click is valuable only when the review is real. Inspect the workflow diff, trigger, privileges, untrusted-code paths and external dependencies before approving. If the change cannot be explained, leaving CI blocked is the safer outcome until it can.

The practical rule is simple: treat Actions workflow files like deployment infrastructure, because in many repositories that is exactly what they are.

Sources

Checked August 17, 2026:

• GitHub Changelog — GitHub Actions holds potentially malicious workflows for approval
• GitHub Blog — Disrupting supply chain attacks on npm and GitHub Actions
• GitHub Docs — Approving workflow runs from forks
• GitHub Docs — Securely using pull_request_target
• GitHub Changelog — Safer pull_request_target defaults for GitHub Actions checkout
• GitHub Changelog — Control who and what triggers GitHub Actions workflows
• GitHub Changelog — Read-only Actions cache for untrusted triggers
• GitHub Changelog — Dependabot alerts on malicious packages across more ecosystems