Self-Hosted GitHub Actions Runners: The Security Checklist to Run Before You Get Compromised

GitHub-hosted runners are ephemeral by design: a fresh VM is provisioned per job and torn down afterward, so anything an attacker plants dies with the job. Self-hosted runners break that assumption in three specific ways.

First, runner reuse across workflow runs. A self-hosted runner that isn't explicitly configured as ephemeral picks up the next job after finishing the current one, on the same filesystem, with the same installed tooling. Anything an attacker drops during one compromised run, a cron entry, a modified shell profile, a background process, can survive to influence or observe later runs, including runs from workflows and repositories that never intended to trust that code. Sysdig has documented attackers deliberately exploiting this: setting the environment variable RUNNER_TRACKING_ID to 0 or an empty string prevents GitHub's own cleanup job from terminating processes the attacker spawned, letting a planted process outlive the workflow that launched it. Attackers have also been observed registering the runner as a system service so it survives a reboot.

Second, network access to internal resources. The entire reason many teams run self-hosted infrastructure is to reach things GitHub-hosted runners can't: internal package registries, staging databases, VPC-only services, on-prem hardware. That access doesn't distinguish between your CI job and an attacker's payload running inside it. A compromised workflow step on a self-hosted runner can pivot to whatever that runner can reach, which is often a meaningfully larger blast radius than a GitHub-hosted VM that can only exfiltrate whatever secrets were explicitly injected into the job.

Third, credential exposure. Long-lived runners accumulate cached credentials, SSH keys, cloud provider tokens, Docker registry logins, that a fresh GitHub-hosted VM would never have. Attackers who gain code execution on a self-hosted runner have been observed harvesting far more than the current job's secrets: querying cloud instance metadata services, dumping runner process memory, and reading credential files left behind by prior jobs or by the humans who set up the machine.

GitHub's own documentation is direct about this: self-hosted runners should generally not be used for public repositories, because anyone can open a pull request or fork and, depending on workflow triggers, get code running on your infrastructure.

In late February and March 2026, attackers compromised aquasecurity/trivy-action, the official GitHub Action wrapping the widely used Trivy vulnerability scanner, and force-pushed 75 of its 76 version tags to point at malicious commits. A related repository, aquasecurity/setup-trivy, had 7 tags similarly poisoned. Because Git tags are mutable, workflows that pinned trivy-action to a tag like @v0.33.0 rather than a commit SHA silently started pulling attacker-controlled code the next time that job ran, with no visible change to the workflow file itself.

The root cause traced back further: attackers exploited a pull_request_target misconfiguration in the project's own workflows, a pattern where a workflow checks out and runs code from an incoming pull request while still carrying the privileged permissions and secrets of the target repository. That let an attacker's PR code execute with access to repository secrets, which is how a privileged personal access token was exfiltrated and used to force-push the malicious tags.

The payload itself was a credential harvester. It searched for SSH keys, cloud provider credentials, database credentials, Git and Docker configuration files, and Kubernetes tokens, and specifically went after Solana validator key pairs and cryptocurrency wallets. It also queried the AWS Instance Metadata Service and dumped runner process memory looking for anything else usable. Stolen data was exfiltrated to a typosquatted domain, and when that exfiltration path failed, the malware fell back to staging stolen data inside the victim's own GitHub account by pushing it to a public repository, using the victim's infrastructure to launder the theft. Reporting put the blast radius at more than 10,000 affected CI/CD workflows and over 1,000 downstream SaaS environments before the compromised tags were identified.

The reason this incident belongs in a self-hosted runner hardening guide rather than only a general supply chain one: on an ephemeral GitHub-hosted runner, this payload runs, harvests whatever secrets were injected into that one job, and dies when the VM is torn down. On a long-lived self-hosted runner with cached credentials, an installed cloud CLI already authenticated from a prior deployment job, and a route to internal systems, the same payload has a much larger set of things to steal and a much longer window in which to steal them. Remediation was to upgrade to safe versions (trivy 0.69.3, trivy-action 0.35.0 or later, setup-trivy 0.2.6 or later) and pin the action to a full commit SHA rather than a tag going forward.

Before working through the checklist, get an accurate inventory. You cannot harden what you don't know exists.

List every self-hosted runner registered to your organization, including runners registered at the repository level that may not show up in an org-wide view. For each one, record what repositories and workflows can dispatch jobs to it, what network segments it can reach, what long-lived credentials are installed or cached on it, and whether it is currently configured as ephemeral (destroyed and re-provisioned per job) or persistent (stays alive across jobs indefinitely).

You will also need write access to organization-level and repository-level Actions settings (Settings > Actions > General), branch protection rules, and runner group configuration. If your organization uses a separate identity provider for cloud credentials (OIDC federation, a secrets manager), have those team's contacts ready, several of the steps below involve migrating from static secrets to short-lived, brokered credentials, which is rarely a solo change.

Work through these in order. The first several remove entire classes of risk; the later ones reduce blast radius for whatever gets through anyway.

Configuration changes are not validated until you've tried to break them. Run adversarial tests against your own setup rather than assuming the settings did what you intended.

Open a test pull request from a fork (or a branch simulating an untrusted contributor) and confirm the workflow either doesn't run against a self-hosted runner at all, or requires explicit maintainer approval before it does. If it runs without approval, your fork PR gate isn't actually enforced.

On an ephemeral runner, SSH into the underlying host (in a test environment) mid-job, plant a marker file or background process, and confirm it is gone after the job completes and the next job starts. If the marker survives, the runner isn't tearing down the way you think it is.

Attempt to reach an internal-only resource (a staging database, an internal API) from a job running on a runner that shouldn't have that network path, and confirm it's blocked. Deny-by-default rules that were configured but never tested against an actual attempted connection have a way of turning out to have an unnoticed allow rule left over from before the segmentation project.

Grep every workflow file in the organization for uses: referencing a tag or branch rather than a full commit SHA, and for the pull_request_target trigger combined with a checkout of the PR head. Both are mechanically detectable and don't require waiting for an incident to find.

Check that GITHUB_TOKEN permissions declared in workflow YAML match what the job's steps actually need, a workflow declaring contents: write because an earlier version of the job needed it, when the current version doesn't, is a common drift pattern that manual review catches and automated scanning often misses.

Treating 'self-hosted' as a one-time infrastructure decision rather than an ongoing configuration surface. Runners get set up once, pass an initial review, and then never get revisited as workflows, permissions, and repository access evolve around them.

Configuring ephemeral runners at the infrastructure level but leaving the underlying VM image or container with cached credentials baked in, which defeats the point: the process lifecycle is ephemeral, but the credential exposure isn't.

Assuming pinning to a tag like @v4 is sufficient because it looks like a version number. It is not immutable, and the trivy-action incident is a direct demonstration of what happens when that assumption is wrong at scale.

Granting a single runner group broad network access because it's convenient for the one workflow that needs it, then reusing that same runner group for unrelated, lower-trust workflows because provisioning a second group felt like unnecessary overhead.

Enabling fork PR approval requirements for the organization's flagship repositories while leaving smaller, less-visible internal tools on default settings, exactly the kind of repository an attacker looks for because it's less likely to be reviewed as carefully but often shares the same runner infrastructure or credential scope as the higher-profile projects.

Relying entirely on GitHub's audit log for detection without shipping any host-level telemetry off the runner itself, which leaves you blind to exactly the kind of persistence mechanism (a background process, a modified environment variable) that doesn't necessarily generate a GitHub-side audit event at all.

Ephemeral runners are not free. Provisioning a fresh runner environment per job adds spin-up latency, typically the time to boot a VM or container and re-download tooling and dependencies that a persistent runner would already have cached, which lengthens CI wall-clock time and increases compute cost, since you're paying to rebuild the same environment repeatedly rather than reusing a warm one. For organizations running frequent, short jobs, that overhead compounds across hundreds of daily workflow runs.

Persistent runner pools avoid that cost: warm caches, pre-installed dependencies, and faster job start times. The tradeoff is that persistence is precisely the property that lets a compromise on one job's code carry forward into the next job's execution environment, which is the mechanism behind both the RUNNER_TRACKING_ID persistence technique and the broader argument for treating self-hosted runners as exposed systems rather than disposable build plumbing.

A reasonable middle ground many teams land on: ephemeral runners for anything that executes code from outside a small, trusted set of maintainers (any workflow that can be triggered by a pull request, a fork, or an external contributor), and persistent runner pools reserved for internal, tightly access-controlled workflows where the trigger surface is fully known and the cost of ephemeral spin-up doesn't justify itself. That split concentrates the compute cost of ephemeral runners where the compromise risk is actually elevated, rather than paying it uniformly across every job in the organization.