GitHub Actions Under Active Exploitation: Audit Your Org for High-Risk Workflow Patterns

The pull_request_target event runs in the context of the base repository. Risk increases when a workflow checks out pull request-controlled code and then executes it in that privileged context. The issue is the combination of elevated context with untrusted code execution.

Review any workflow triggered by pull_request_target and confirm whether it checks out the pull request head ref, including from forks, and runs scripts, build steps, or actions sourced from that checkout. Treat any workflow that does so as a high-priority hardening candidate, especially if secrets or elevated token permissions are available in the same job.

Workflows triggered by issue_comment can be useful for maintainers, but they require strong authorization checks to avoid turning public comments into an execution mechanism. Risk arises when a workflow reacts to a comment string and performs meaningful actions without confirming that the commenter is trusted.

Review comment-triggered workflows and ensure privileged behavior is gated to trusted actors through clear, enforceable checks. This is particularly important for workflows that publish artifacts, create releases, modify repository state, access protected environments, or use secrets.

Many GitHub Actions context fields can be influenced by pull request authors, including branch names, pull request titles, commit messages, and file paths. If these values are inserted into shell commands without safe handling, they can alter command behavior and, in some cases, enable command injection.

Review run: steps for direct usage of ${{ github.event.* }} and related context values inside shell commands, especially in scripts that perform parsing, loops, string concatenation, or dynamic command construction. Pay close attention to unquoted variables, ad hoc string manipulation, and any command built from event fields.

Workflows frequently enumerate changed files using diff output, git commands, or filesystem discovery, then process those filenames in shell loops. When filenames originate from pull request content, treat them as untrusted input. Risk increases when filenames are expanded without strict quoting or used to construct commands.

Identify workflows that consume pull request-derived filenames and confirm that variables are consistently quoted, that scripts avoid unsafe word splitting, and that filenames do not influence command execution paths.

As organizations add automation agents, including AI-assisted workflows, a newer class of risk is emerging: instruction or configuration poisoning. If an automated workflow reads instructions, configuration, or directives from pull request-controlled content while running with elevated permissions or secrets access, a contributor can attempt to influence what the automation executes.

Review any workflow that consumes pull request-provided instruction or configuration files and confirm that privileged operations are isolated from untrusted inputs. Ensure pull request content cannot change what privileged steps execute.