How Can Self-Hosted GitHub Runners Be Hacked?

TL;DR

Public repositories should avoid non-ephemeral self-hosted runners because a malicious pull request can poison a workflow, compromise the runner, and preserve access for later jobs. That foothold may expose more privileged GitHub tokens or repository secrets, enable build tampering, and create a path to a high-impact software supply chain attack.

Transcript

before we get into the technical details we're going to start off with a story two months ago someone identified a giup actions misconfiguration in a public repository owned by one of the largest domestic chip manufacturers in the United States anyone with a giup account could have exploited it simply by creating a poll request the vulnerability al... Read More

Key Insights

• Non-ephemeral self-hosted runners are particularly dangerous because they execute multiple workflows during their lifetime. If an attacker compromises one through a public pull request, the attacker can retain access and target later jobs that receive stronger permissions, credentials, or access to sensitive build processes.
• GitHub-hosted runners are ephemeral according to the presentation, so each runner is torn down when its workflow concludes. Self-hosted runners are instead managed by end users, run the GitHub Actions runner agent, and leave security configuration and maintenance entirely under the user's responsibility.
• A poisoned pipeline attack can begin when an external contributor modifies a workflow in a fork and creates a pull request. If the public repository executes that untrusted workflow on a self-hosted runner, the contributor's code can compromise the underlying build environment.
• Public GitHub Actions logs are available to anyone with a GitHub account through the API or web interface. These logs can disclose enough contextual information for an attacker to understand a runner's configuration and prepare an attack before performing a malicious action.
• Workflow logs can reveal whether a runner is registered at the repository or organization level. Organization-level placement is significant because runner groups shared between public and private repositories may create privilege escalation or lateral movement paths beyond the original public project.
• GitHub token permissions can differ between consecutive workflows on the same persistent runner. An attacker entering through a fork workflow with a read-only token may persist until a later workflow uses a write-enabled token, creating an opportunity to capture more powerful access.
• The checkout log can help identify a non-ephemeral runner because a message about cleaning the repository indicates that content from a previous checkout is being removed. The researchers describe this as a strong heuristic that the same machine is being reused across workflows.
• Compromised runner secrets can enable attackers to alter application releases and produce a software supply chain attack. The researchers report finding critical CI/CD vulnerabilities affecting organizations and projects including GitHub, PyTorch, Microsoft, TensorFlow, and Web3 companies during their research campaign.

Questions & Answers

Q: How can a public pull request compromise a self-hosted GitHub runner?

A contributor can modify a GitHub Actions workflow within a fork and submit a pull request to a public repository. If the repository permits that workflow to run on its self-hosted infrastructure, the attacker's code executes on the runner. A non-ephemeral runner makes the problem worse because the attacker may preserve access after the initial workflow finishes and target subsequent jobs.

Q: Why are non-ephemeral GitHub Actions runners dangerous?

Non-ephemeral self-hosted runners remain active and execute multiple workflows instead of being destroyed after each job. A person who compromises one through an untrusted workflow can establish persistence on the machine. That persistence may provide access to later workflows with stronger GitHub token permissions, repository secrets, sensitive build operations, or connections that support privilege escalation and lateral movement.

Q: What is the difference between GitHub-hosted and self-hosted runners?

GitHub-hosted runners are built and frequently updated by GitHub, support multiple operating systems and architectures, and are always ephemeral according to the presentation. They are torn down after a workflow concludes. Self-hosted runners are operated by end users, execute workflows through the Actions runner agent, and place responsibility for configuration, isolation, maintenance, and security on the organization using them.

Q: What can attackers discover from public GitHub Actions logs?

Public workflow logs can expose runner labels, runner and machine names, runner-group details, registration scope, GitHub token permissions, and processor architecture. They can also contain evidence that a machine is non-ephemeral. Anyone with a GitHub account can download these logs through the API or web interface, allowing detailed reconnaissance before the attacker performs any overtly malicious action.

Q: How can workflow logs reveal a non-ephemeral runner?

The researchers use output from the actions checkout step as a heuristic. When the log says that it is cleaning the repository, the action is removing material from a previous checkout. That behavior almost always indicates, according to the presentation, that the machine has processed an earlier workflow and is therefore a persistent, non-ephemeral runner that may retain exploitable state.

Q: How can a compromised runner expose a more powerful GitHub token?

A workflow triggered from a fork may initially receive only a read-only GitHub token. On a persistent runner, however, an attacker can maintain access after that job ends. If a later workflow executes on the same runner with a write-enabled token, the attacker may capture that credential and gain permissions that were unavailable during the original pull-request workflow.

Q: Why can organization-level runner groups increase security risk?

Workflow logs can show that a self-hosted runner is attached at the organization level rather than only to one repository. If its runner group is shared between public and private repositories, compromise through a public workflow may create paths toward private workloads. The researchers identify this arrangement as relevant to privilege escalation and lateral movement within an organization's GitHub environment.

Q: How should organizations reduce self-hosted runner risk on public repositories?

Organizations should follow GitHub's recommendation, cited in the presentation, to use self-hosted runners only with private repositories. When self-hosting is necessary, ephemeral runners that start from a fresh container, virtual machine, or equivalent environment for every workflow reduce persistence opportunities. Teams should also review workflow permissions, runner-group sharing, public logs, secret privileges, and whether untrusted pull requests reach internal infrastructure.

Summary & Key Takeaways

• Self-hosted GitHub Actions runners can expose organizations to external compromise when they are attached to public repositories. The researchers found configuration errors across major technology organizations and demonstrated that an attacker may begin with a pull request, execute code through a workflow, and establish a foothold on an insufficiently isolated build machine.

• The greatest risk comes from non-ephemeral runners, which survive after individual workflow jobs and execute multiple workflows during their lifetime. An attacker who gains access through a low-privilege fork workflow can persist on the machine, observe later activity, capture more privileged credentials, steal secrets, move laterally, or interfere with subsequent builds.

• Public workflow logs provide attackers with valuable reconnaissance before any malicious activity occurs. Logs can reveal runner labels, scope, group and machine names, token permissions, processor architecture, and evidence that a runner is non-ephemeral. The recommended defensive direction is to prefer GitHub-hosted runners or carefully isolated ephemeral self-hosted infrastructure for public repositories.