What breaks when attackers can run code on a self-hosted runner with access to secrets?

Why Self-Hosted Runner Compromise Breaks the CI/CD Trust Model

A self-hosted runner is not just an execution host. It is a privileged part of the delivery system, often placed inside the same trust zone as source, build tooling, package publishing, and deployment credentials. Once an attacker can run code there, the platform can no longer assume that job isolation, environment variables, or action boundaries are trustworthy. That is why this issue is not only about malware on one machine; it is about losing confidence in the integrity of the build and release path.

For practitioners, the key failure is that secrets on a runner are usually present at the exact moment they are most useful, and that makes them attractive for theft, replay, or misuse. The same access can also be used to alter artifacts before they are signed, tested, or published, which turns a compromise of one runner into a supply chain event. MITRE ATT&CK is useful here because the abuse pattern often spans credential access, defense evasion, and persistence in a delivery environment; see the MITRE ATT&CK Enterprise Matrix for the broader adversary technique landscape. In practice, many security teams discover the impact only after a trusted build has already been used to distribute untrusted output.

How Runner Access Turns Secrets into Build and Release Exposure

When code runs on a self-hosted runner, it typically inherits the job context, the workspace, and any secrets injected for that pipeline step. That can include source-control tokens, package registry credentials, cloud access keys, signing material, or deployment tokens. The immediate danger is not simply that a secret might be read. The larger issue is that the runner gives the attacker an execution foothold inside the same process environment that the CI/CD platform relies on to prove integrity.

From there, several things can break at once. First, the attacker may exfiltrate secrets from environment variables, mounted files, caches, logs, or process memory. Second, they may modify the repository checkout, intermediate build output, dependency resolution, or artifact packaging before the pipeline completes. Third, they may use the runner as a launch point into internal services that were never intended to be reachable from the public internet. If the runner has broad network access or persistent credentials, the compromise can extend beyond the pipeline itself.

• Secrets become readable if the job context exposes them in memory, files, logs, or artifacts.
• Artifact integrity breaks if the attacker can alter outputs before signing or publishing.
• Infrastructure trust breaks if the runner can reach internal APIs, registries, or deployment targets.
• Detection becomes harder if the attacker blends activity into normal pipeline execution.

The important control question is whether the runner can affect anything that other systems will later trust as legitimate. That is where the compromise becomes materially worse than ordinary host compromise. A good reference point for defensive framing is CISA’s published threat and advisory material, which helps teams reason about the operational consequences of credential theft and trusted-system abuse; the CISA cyber threat advisories are useful for that broader context. This guidance breaks down when runners are long-lived, broadly networked, or allowed to handle high-value secrets without strong job-level isolation.

Where the Usual CI/CD Controls Stop Being Enough

Tighter runner control often increases operational overhead, so teams have to balance isolation against build speed, maintenance, and developer convenience. That tradeoff becomes visible when organisations treat self-hosted runners like generic build servers rather than short-lived trust-sensitive execution points.

Not every self-hosted runner compromise has the same consequence. A runner that builds low-risk internal code with no secrets is less dangerous than one that can sign releases, deploy to production, or access cloud control planes. Likewise, ephemeral runners reduce persistence risk, but they do not eliminate the possibility of secret theft during the job window. The most common misconception is to assume that masking secret values in logs is enough. It is not. If code execution is already compromised, the attacker can often use the secret directly, not merely read it.

Another edge case is that the blast radius depends on what the runner can reach after compromise. A runner with tightly scoped, per-job credentials and no lateral network path behaves very differently from one holding reusable tokens or shared service credentials. This is where guidance varies by environment, and the industry does not fully agree on a single safe baseline for all pipelines. The practical test is whether compromise of one job can be contained to one job. If it cannot, the organisation has a trust-boundary problem, not just a hardening problem.

For teams that need a specialist identity lens on machine access and secret exposure, the OWASP Non-Human Identity Top 10 is a useful companion view because it frames the governance failure around machine-held credentials rather than around the build tool alone.

Risk and Threat Considerations

The main risk is trusted execution abuse. A compromised self-hosted runner can expose secrets, alter build outputs, and create an internal pivot path that bypasses normal perimeter controls. That makes the impact wider than a single-host compromise because the attacker is operating inside a workflow that other systems are designed to trust.

Failure mechanism: The attacker uses code execution in the runner context to read injected credentials, tamper with the workspace or artifacts, and then reuse the trusted automation identity to reach downstream systems. If the runner is persistent or overprivileged, the compromise can persist across jobs or spread into adjacent services.

Impact: Credentials may be stolen, release artifacts may be poisoned, deployment trust may be lost, and internal systems may be accessed through a path that defenders did not intend to expose to code execution on the runner.

Practitioner Guidance

What to prioritise: Treat runner privilege, secret scope, and network reach as one control problem. The first question is not whether the runner is patched, but whether a single job can read secrets or influence anything that downstream systems trust.

What to verify: Confirm that secrets are issued only for the exact job that needs them, that they expire quickly, and that runner logs, caches, and artifact paths do not become secondary secret stores. Also verify that the runner cannot reach internal targets that are unrelated to the current pipeline step.

Common mistake: Assuming ephemeral runners alone solve the problem. They reduce persistence, but they do not stop secret theft, output tampering, or abuse of whatever trust is still granted during execution.

Practitioner takeaway: If a runner can execute attacker-controlled code while holding secrets, the control objective is containment, not just detection. The safest design is the one that limits what that code can see, change, and reach before the job ever starts.

Related resources from NHI Mgmt Group

• What breaks when attackers can turn a GitHub Discussion into a command channel on a self-hosted runner?
• What breaks when a self-hosted AI assistant runs with user-level filesystem access?
• What breaks when CI runners are allowed to execute forked code with access to repository secrets?
• What breaks when a self-hosted secrets platform is deployed without matching the architecture to the team’s operational maturity?