self-hosted-runner-poisoning

Self-Hosted Runner Poisoning

What Is Broken and Why

GitHub-hosted runners are ephemeral and isolated. Self-hosted runners are not — they persist between runs, share state, and often carry long-lived credentials baked into the environment. When a repository allows fork pull requests to run on self-hosted runners (especially with the default "Require approval for first-time contributors" setting), an attacker who has made even one accepted contribution can submit a PR that modifies the workflow's runs-on field to target a privileged self-hosted runner and execute arbitrary code on it. Non-ephemeral runners retain their working directory, installed tooling, and cached credentials across runs — making them ideal for persistence and lateral movement into the broader infrastructure.

Key Signals

• runs-on: self-hosted or named runner labels (azure-builds, macos-vmware, [self-hosted, linux]) in workflow files
• Repository setting: "Require approval for first-time contributors" (default) rather than "Require approval for all outside collaborators"
• Fork PR workflows that use a matrix.os or matrix.runner whose values the PR author can influence
• Non-ephemeral runner: runner directory persists, processes survive between runs
• Workflow checks out code without persist-credentials: false → .git/config contains embedded GITHUB_TOKEN
• runs-on field uses an expression: runs-on: ${{ matrix.os }} or runs-on: ${{ inputs.runner }}
• Secrets or cloud credentials (AWS_*, AZURE_*, vCenter creds) available in runner environment
• Repository contains build infrastructure workflows (Packer, Terraform, image builds)

Methodology

1. Identify repositories using self-hosted runners:

   gato enumerate --target ORG --type org
   # or manually:
   grep -rn 'self-hosted\|runs-on:' .github/workflows/ | grep -v 'ubuntu-latest\|windows-latest\|macos-latest'
   

2. Check the fork PR approval policy: Settings → Actions → Fork pull request workflows. "Require approval for first-time contributors" = vulnerable after one merged PR.
3. Check if runs-on uses a matrix or expression that a PR author can modify.
4. Submit one legitimate PR (typo fix, docs update) to gain "not first-time contributor" status.
5. In a second PR, modify the workflow to:
   • Change runs-on to target a self-hosted runner label
   • Replace or append a malicious step to the workflow
6. Confirm code execution via OOB callback.
7. From runner context: extract .git/config for GITHUB_TOKEN, enumerate environment variables, access credential stores.
8. Optionally install persistent runner agent for long-term access.
9. Cover tracks: delete workflow run logs via API using stolen token.