What are the signs that a GitHub Actions workflow may be vulnerable to command injection?

What command injection usually looks like in a GitHub Actions workflow

GitHub Actions becomes suspicious when untrusted input is allowed to cross the boundary from event data into a shell context. The risk is highest when a workflow takes values from branch names, pull request fields, labels, commit messages, or job outputs and uses them directly in run steps without quoting, validation, or an intermediate safe representation. That pattern can turn ordinary CI logic into code execution.

Another sign is when the workflow is built around shell interpolation rather than fixed commands. If the workflow author is assembling command lines from variables, especially across multiple steps, the review should focus on whether any part of that data can be influenced by an external contributor or an upstream job. The more dynamic the command construction, the easier it is for a malicious payload to alter execution.

Workflows that use privileged triggers deserve extra scrutiny. A pull_request_target workflow can be legitimate, but it becomes dangerous when it runs secret-bearing or repository-changing steps before proving that every referenced value is trusted. In practice, the warning sign is not the trigger alone, but the combination of elevated permissions, repository secrets, and data that originated outside the protected branch or trusted actor set.

Where the dangerous data flow begins

The core question is whether the workflow treats user-controlled data as command text. If a value is only displayed, logged safely, or passed through a quoted argument boundary, the risk is much lower. If that same value is inserted into a shell fragment, redirected into an inline script, or passed to a tool through eval-like behaviour, the workflow should be treated as injection-prone until proven otherwise.

Patterns that are easy to miss include composite actions that hide shell steps, reusable workflows that accept inputs without strict contracts, and job outputs that are trusted simply because they came from a previous step in the same pipeline. A workflow can look harmless at the top level while still being vulnerable deeper in the execution chain. That is why reviewers should trace the full data path, not just inspect the final command line.

When the workflow uses secrets, tokens, or deployment credentials, the impact of command injection rises sharply because the injected command executes with the same authority as the job. NHIMG’s CI/CD Pipeline Identity Security Guide is useful here because it frames GitHub Actions as an identity and privilege problem as much as a scripting problem.

What to look for during review and triage

A practical review starts with the workflow files that contain shell execution, then checks whether any variable in those commands can be influenced by the event payload, repository content, or another job. Look closely at inline scripts, unquoted expansions, string concatenation in shell commands, and any step that downloads or executes content based on event data. Those are the most common places where a workflow stops being declarative and starts behaving like an interpreter for attacker-controlled input.

It is also worth checking whether third-party actions are pinned and whether the workflow trusts outputs from those actions without validation. A command injection warning is stronger when the workflow combines external input, unpinned dependencies, and broad permissions in the same execution path. The review question is simple: could a contributor influence what the runner executes, not just what it processes?

For incident-oriented examples of how GitHub Actions abuse can expose secrets at scale, the GitHub Action tj-actions Supply Chain Attack and Reviewdog GitHub Action supply chain attack are directly relevant navigation points. They show why command execution paths in CI deserve the same scrutiny as application-facing input handlers.

Risk and Threat Considerations

Command injection in GitHub Actions matters because the runner often has direct access to repository contents, cloud credentials, signing material, and deployment permissions. Once an attacker can influence shell execution, the boundary between a workflow bug and a full pipeline compromise becomes very thin. The highest-risk cases are the ones where untrusted data reaches a privileged step before any validation or containment.

Failure mechanism: A malicious branch name, pull request field, or upstream output is expanded into a shell command, allowing the attacker to append, replace, or chain commands that inherit the job’s permissions.

Impact: The workflow may leak secrets, alter build artefacts, tamper with releases, or execute follow-on actions inside the repository or connected infrastructure.

Practitioner Guidance

What to verify: Confirm that every shell step treats external input as data, not code. If a value can come from a pull request, event payload, job output, or repository-controlled file, require explicit quoting, allowlisting, or a safer API-based alternative before the workflow is trusted.

Common mistake: Teams often secure the trigger but not the command boundary. A workflow may look safe because it only runs on “trusted” events, yet still becomes injectable when it interpolates event fields into a shell command or lets a secret-bearing job consume untrusted text.

Practitioner takeaway: The decisive question is not whether the workflow uses GitHub Actions, but whether any attacker-influenced value can reach a shell in a privileged step without a hard trust boundary.

Related resources from NHI Mgmt Group

• What are the signs that a GitHub Actions workflow is misconfigured and vulnerable to a pwn request attack?
• What are the signs that a GitHub Actions workflow has been tampered with or is behaving maliciously?
• What are the signs that a GitHub Actions workflow has been affected by a supply chain compromise?
• What are the signs that a GitHub release workflow may be exposed to tag injection?