Skip to content

CONCEPT Cited by 1 source

Self-hosted runner credential leak

Definition

A class of CI/CD vulnerability where malicious code executing on self-hosted runners gains access to credentials stored on or accessible from the runner environment. Self-hosted runners, unlike ephemeral GitHub-hosted runners, persist across jobs and often have access to long-lived credentials, network resources, and file-system state that outlive any single workflow run.

Attack surface

Self-hosted runners are higher-value targets than GitHub-hosted runners because:

  1. Persistent state — credentials, caches, and environment variables may persist between jobs
  2. Network access — often on internal networks with access to services like Vault, cloud provider metadata endpoints, or internal APIs
  3. Long-lived credentials — GitHub App private keys, cloud API keys, or registry tokens stored on-disk or in environment
  4. Less isolation — workloads from different repos/workflows may share the same runner

Grafana incident (2026)

The TanStack "Mini Shai-Hulud" supply chain campaign executed malicious code on Grafana's self-hosted runners on May 11, 2026. The leaked credentials included a GitHub bot token (grafana-delivery-bot) that provided access to clone all repositories. The key failure: the credential was long-lived and broadly scoped — one token granted access to the entire repository collection (Source: sources/2026-06-24-grafana-post-incident-review-tanstack-npm-supply-chain-ransom).

Mitigation

  • Token broker — issue short-lived, per-operation credentials at job start; no secrets at rest on runners (patterns/token-broker-for-ci-credentials)
  • Ephemeral runners — destroy and recreate runner VMs per-job (eliminates persistent state)
  • Network segmentation — runners in isolated network without access to broad credential stores
  • Actions allow-listing — restrict which Actions can execute on self-hosted runners

Seen in

Last updated · 559 distilled / 1,651 read