Review GitHub Actions for Exploitable Vulnerabilities

Reviews GitHub Actions workflows for exploitable vulnerabilities, requiring every finding to include a concrete exploitation scenario built from a traced attack path, not theoretical CI/CD concerns. It reviews .github/workflows/*.yml, action.yml/action.yaml composite actions, .github/actions/*/action.yml local reusable actions, and config files workflows load (CLAUDE.md, AGENTS.md, Makefile, shell scripts under .github/). Workflows in other repositories are only noted as a dependency, and GitHub App installation permissions are noted only if relevant, both out of scope.

The threat model is a fixed constraint: only vulnerabilities exploitable by an external attacker without repository write access count, someone who can open fork PRs, create issues, and post comments but cannot push branches or trigger workflow_dispatch or manual workflows. It explicitly excludes workflow_dispatch input injection, expression injection in push-only workflows on protected branches, workflow_call input injection where all callers are internal, and secrets in workflow_dispatch/schedule-only workflows, since all require write access to exploit.

Findings are graded HIGH (full attack path traced and confirmed), MEDIUM (attack path partially confirmed, needs verification) or LOW (theoretical or already mitigated, not reported). Every HIGH finding must supply five elements: the entry point (fork PR, issue comment, branch name), the payload (actual code/YAML/input sent), the execution mechanism (expression expansion, checkout plus script), the impact (token theft, code execution, repo write access), and a concrete PoC sketch; if all five can't be constructed, the finding drops to MEDIUM.

Step 1 classifies each workflow's triggers and loads the matching reference: pull_request_target loads references/pwn-request.md, issue_comment command parsing loads references/comment-triggered-commands.md, ${{ }} in run: blocks loads references/expression-injection.md, PATs/deploy keys load references/credential-escalation.md, checkout of PR code plus config loading loads references/ai-prompt-injection-via-ci.md, third-party actions load references/supply-chain.md, a permissions: block or secrets usage loads references/permissions-and-secrets.md, and self-hosted runners or cache/artifact usage load references/runner-infrastructure.md, loaded selectively based on what's actually present.

Step 2 checks eight vulnerability classes: pwn requests (pull_request_target combined with fork-code checkout), expression injection (attacker-controlled ${{ }} values, PR title, branch name, comment body, specifically inside run: blocks rather than if:/with:/job-level env:), unauthorized command execution in issue_comment-triggered workflows lacking an author_association check, credential escalation (blast radius of exposed PATs or deploy keys), config-file poisoning via PR-supplied CLAUDE.md/AGENTS.md/.cursorrules/Makefile, supply-chain risk from unpinned third-party actions, overly broad permissions or secret scoping, and insecure self-hosted runner/cache/artifact usage.

A safe-patterns table filters out non-issues before reporting: pull_request_target without fork-code checkout, numeric-only expressions like github.event.pull_request.number, github.repository/github.repository_owner (owner-controlled), ${{ secrets.* }}, ${{ }} in if: conditions or with: inputs (runtime-evaluated, not shell-evaluated), actions pinned to a full SHA, the plain pull_request trigger (fork context, read-only token), and any expression gated behind workflow_dispatch/schedule/protected-branch push. Step 3 requires reading the full workflow YAML rather than trusting grep output, tracing the trigger and its if: gating, confirming the expression or checkout is genuinely attacker-reachable, and checking for existing mitigations, env-var wrapping, author_association checks, restricted permissions, SHA pinning, before any finding is finalized; a broken link in the chain downgrades the finding to MEDIUM or drops it, and zero findings is a valid, expected outcome rather than something to pad out.

Step 4 reports findings in a fixed Markdown structure: a numbered [GHA-001] finding with workflow file and line, trigger, confidence level with justification, a step-by-step exploitation scenario, impact, and a code fix, followed by a Needs Verification section for MEDIUM items and a Reviewed and Cleared section for confirmed-safe workflows.

Use it when reviewing GitHub Actions workflows for exploitable security issues, tracing a concrete attack path from an external attacker to workflow execution or secret exposure, or auditing workflow files, composite actions, or workflow-related scripts for evidence-based findings. Skip it for vulnerabilities that require write access to exploit, workflows in other repositories beyond noting the dependency, or purely theoretical issues with no traceable attack path.

Input is the workflow files, diffs, or repository to review. Output is a structured Markdown report of HIGH/MEDIUM findings with exploitation scenarios and fixes, a needs-verification list, and a reviewed-and-cleared list, or a clean-bill statement when no exploitable vulnerabilities are found.

Draws its attack patterns from real-world GitHub Actions exploitation research, cited as the HackerBot Claw campaign analysis by StepSecurity (2025); loads its own bundled reference files (references/pwn-request.md, references/expression-injection.md, references/credential-escalation.md, references/ai-prompt-injection-via-ci.md, references/supply-chain.md, references/permissions-and-secrets.md, references/runner-infrastructure.md, references/real-world-attacks.md) selectively based on the triggers found.

Security reviewers and engineers auditing GitHub Actions workflows, composite actions, or CI configuration for externally-exploitable attack paths, who need evidence-based findings rather than generic CI/CD security theory.