GitHub Actions Security Review

Find exploitable vulnerabilities in GitHub Actions workflows. Every finding MUST include a concrete exploitation scenario — if you can't build the attack, don't report it.

This skill encodes attack patterns from real GitHub Actions exploits — not generic CI/CD theory.

Scope

Review the workflows provided (file, diff, or repo). Research the codebase as needed to trace complete attack paths before reporting.

Files to Review

• .github/workflows/*.yml

  — all workflow definitions

• action.yml

  /

  action.yaml

  — composite actions in the repo

• .github/actions/*/action.yml

  — local reusable actions
• Config files loaded by workflows:

  CLAUDE.md

  ,

  AGENTS.md

  ,

  Makefile

  , shell scripts under

  .github/

Out of Scope

• Workflows in other repositories (only note the dependency)
• GitHub App installation permissions (note if relevant)

Threat Model

Only report vulnerabilities exploitable by an external attacker — someone without write access to the repository. The attacker can open PRs from forks, create issues, and post comments. They cannot push to branches, trigger

workflow_dispatch

Do not flag vulnerabilities that require write access to exploit:

• workflow_dispatch

  input injection — requires write access to trigger
• Expression injection in

  push

  -only workflows on protected branches

• workflow_call

  input injection where all callers are internal
• Secrets in

  workflow_dispatch

  /

  schedule

  -only workflows

Confidence

Report only HIGH and MEDIUM confidence findings. Do not report theoretical issues.

For each HIGH finding, provide all five elements:

1. Entry point — How does the attacker get in? (fork PR, issue comment, branch name, etc.)
2. Payload — What does the attacker send? (actual code/YAML/input)
3. Execution mechanism — How does the payload run? (expression expansion, checkout + script, etc.)
4. Impact — What does the attacker gain? (token theft, code execution, repo write access)
5. PoC sketch — Concrete steps an attacker would follow

If you cannot construct all five, report as MEDIUM (needs verification).

Step 1: Classify Triggers and Load References

For each workflow, identify triggers and load the appropriate reference:

pull_request_target

references/pwn-request.md

issue_comment

references/comment-triggered-commands.md

${{ }}

run:

references/expression-injection.md

references/credential-escalation.md

references/ai-prompt-injection-via-ci.md

references/supply-chain.md

permissions:

references/permissions-and-secrets.md

references/runner-infrastructure.md

references/real-world-attacks.md

Load references selectively — only what's relevant to the triggers found.

Step 2: Check for Vulnerability Classes

Check 1: Pwn Request

Does the workflow use

pull_request_target

• Look for

  actions/checkout

  with

  ref:

  pointing to PR head
• Look for local actions (

  ./.github/actions/

  ) that would come from the fork
• Check if any

  run:

  step executes code from the checked-out PR

Check 2: Expression Injection

Are

${{ }}

run:

• Map every

  ${{ }}

  expression in every

  run:

  step
• Confirm the value is attacker-controlled (PR title, branch name, comment body — not numeric IDs, SHAs, or repository names)
• Confirm the expression is in a

  run:

  block, not

  if:

  ,

  with:

  , or job-level

  env:

Check 3: Unauthorized Command Execution

Does an

issue_comment

• Is there an

  author_association

  check?
• Can any GitHub user trigger the command?
• Does the command handler also use injectable expressions?

Check 4: Credential Escalation

Are elevated credentials (PATs, deploy keys) accessible to untrusted code?

• What's the blast radius of each secret?
• Could a compromised workflow steal long-lived tokens?

Check 5: Config File Poisoning

Does the workflow load configuration from PR-supplied files?

• AI agent instructions:

  CLAUDE.md

  ,

  AGENTS.md

  ,

  .cursorrules

• Build configuration:

  Makefile

  , shell scripts

Check 6: Supply Chain

Are third-party actions securely pinned?

Check 7: Permissions and Secrets

Are workflow permissions minimal? Are secrets properly scoped?

Check 8: Runner Infrastructure

Are self-hosted runners, caches, or artifacts used securely?

Safe Patterns (Do Not Flag)

Before reporting, check if the pattern is actually safe:

pull_request_target

${{ github.event.pull_request.number }}

run:

${{ github.repository }}

github.repository_owner

${{ secrets.* }}

${{ }}

if:

${{ }}

with:

pull_request

_target

workflow_dispatch

schedule

push

Key distinction:

${{ }}

run:

if:

with:

env:

Step 3: Validate Before Reporting

Before including any finding, read the actual workflow YAML and trace the complete attack path:

1. Read the full workflow — don't rely on grep output alone
2. Trace the trigger — confirm the event and check

   if:

   conditions that gate execution
3. Trace the expression/checkout — confirm it's in a

   run:

   block or actually references fork code
4. Confirm attacker control — verify the value maps to something an external attacker sets
5. Check existing mitigations — env var wrapping, author_association checks, restricted permissions, SHA pinning

If any link is broken, mark MEDIUM (needs verification) or drop the finding.

If no checks produced a finding, report zero findings. Do not invent issues.

Step 4: Report Findings

## GitHub Actions Security Review

### Findings

#### [GHA-001] [Title] (Severity: Critical/High/Medium)
- **Workflow**: `.github/workflows/release.yml:15`
- **Trigger**: `pull_request_target`
- **Confidence**: HIGH — confirmed through attack path tracing
- **Exploitation Scenario**:
  1. [Step-by-step attack]
- **Impact**: [What attacker gains]
- **Fix**: [Code that fixes the issue]

### Needs Verification
[MEDIUM confidence items with explanation of what to verify]

### Reviewed and Cleared
[Workflows reviewed and confirmed safe]

If no findings: "No exploitable vulnerabilities identified. All workflows reviewed and cleared."