Runner on Runner is an attack pattern in which an adversary installs or attaches an additional runner on a compromised or accessible build host. The goal is to persist, blend in with legitimate automation, and expand control over CI/CD infrastructure. It is particularly dangerous when monitoring focuses only on source code changes.
Expanded Definition
Runner on Runner describes a CI/CD compromise pattern where an attacker adds a second runner, agent, or execution hook to infrastructure that already trusts build jobs. The key boundary is that the technique is about abusing the build platform’s execution layer, not altering application source, so source-code review alone will miss it.
In practice, the added runner may be registered through exposed credentials, stolen tokens, weak host controls, or an already compromised build machine. Once attached, it can inherit the trust of the pipeline and observe jobs, intercept artifacts, or run alongside legitimate automation. That makes the technique a platform-control problem first, and a code-integrity problem only secondarily.
Industry guidance is fairly consistent that CI/CD runners should be treated as high-value execution assets, but organisations differ on how tightly they isolate ephemeral runners from persistent hosts. That distinction matters because persistence is much easier when the runner can survive beyond a single job.
Examples and Use Cases
Runner on Runner is usually discussed in contexts where build infrastructure is already reachable and the attacker wants to stay close to the pipeline rather than detonate quickly. A few common appearances are:
- An attacker registers a new self-hosted runner on a compromised build server so future jobs execute under attacker control.
- A malicious runner is attached to a CI platform and quietly listens for secrets, artifacts, or deployment tokens during normal builds.
- An intruder with limited access to a shared automation host installs a second execution service to preserve persistence after the first foothold is discovered.
- A compromised pipeline worker is used to blend malicious execution into routine CI logs, making activity appear like ordinary build activity.
The main tradeoff is operational convenience versus containment. Self-hosted runners can improve speed, custom tooling, and isolation from vendor platforms, but they also enlarge the attack surface if registration, host hardening, and runtime monitoring are weak. The article collection on runner abuse discussed by MITRE ATLAS adversarial AI threat matrix is useful for readers who want to compare execution-layer abuse patterns across automation-heavy environments.
Security Implications
When Runner on Runner is missed, defenders may continue to trust the pipeline while an attacker has already inserted a parallel execution path. That creates a blind spot where build jobs, secrets handling, artifact signing, and deployment steps can be observed or manipulated without obvious source changes.
The practical consequence is not limited to one compromised job. A rogue runner can be used for persistence, credential capture, build tampering, package injection, or lateral movement into surrounding systems that support the CI/CD estate. Because runners are often treated as disposable or operationally routine, their compromise can persist longer than teams expect, especially when monitoring is focused on repository activity rather than runtime registration events and host-level changes.
Failure mechanism: the attacker abuses the trust relationship between the CI platform and its execution workers, then hides inside normal automation workflows. If runner enrollment, host integrity, or execution provenance is not verified, malicious automation can look legitimate enough to evade basic change controls.
Impact: build integrity weakens, secrets exposure risk rises, and the pipeline can become an attacker-controlled delivery mechanism rather than a controlled release process.
Domain and Governance Relevance
In the broader cybersecurity domain, Runner on Runner matters because it shifts attention from code review to execution trust. The control question is whether the organisation can prove that each runner or build worker is expected, authorised, and monitored as part of the delivery system.
For identity and access governance, the term becomes more serious when runners are registered with long-lived tokens, shared credentials, or permissions broad enough to access repositories, artifacts, or deployment systems. In that case, the runner itself behaves like a privileged non-human actor whose lifecycle needs ownership, revocation, and traceability. That is not an abstract identity concern; it is a direct control issue because the malicious attachment point is the trusted machine identity behind the automation.
Where teams rely on self-hosted or persistent runners, governance must account for host integrity, enrollment provenance, and separation between job execution and platform administration. NHI Management Group treats this as a machine-trust problem that bridges CI/CD security and identity governance only when the runner’s authority materially changes the threat model.
Risk and Threat Considerations
Runner on Runner creates material exposure because it allows an attacker to persist inside the delivery layer while appearing to be legitimate automation. The risk is strongest when monitoring is centred on source changes and ignores runner registration, host state, and execution provenance.
Failure mechanism: the attacker compromises or reuses access to a trusted build host, then adds a second runner or execution service that inherits pipeline trust. If registration secrets, host controls, or attestation are weak, the malicious runner can continue to process jobs, collect credentials, or alter build outputs without immediate detection.
Impact: the pipeline can leak secrets, produce untrusted artifacts, or deliver tampered software while defenders still believe automation is functioning normally. In larger environments, the result can be systemic release integrity loss across multiple projects that share the same CI/CD control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1053 — Scheduled Task/Job | Runner abuse uses trusted automation to persist and execute on a host. |
| T1078 — Valid Accounts | Runner attachment often relies on legitimate tokens or registered access. | |
| T1552 — Unsecured Credentials | CI/CD runners frequently expose tokens, keys, or other secrets during abuse. | |
| Recommendation — Map suspicious runner registration to T1053-style persistence and inspect host automation paths. Hunt for valid-account abuse when runner enrollment succeeds without expected ownership. Review build secrets handling and revoke exposed credentials after runner compromise. | ||
| CIS Controls v8 | 5 — Account Management | Runner trust depends on tightly governed accounts, tokens, and registration access. |
| 8 — Audit Log Management | Runner-on-runner activity is often visible first in registration and execution logs. | |
| 12 — Network Infrastructure Management | Self-hosted runners require network and host segmentation to limit persistence and spread. | |
| Recommendation — Restrict and regularly review accounts that can register or administer build runners. Collect and review runner enrollment and execution logs for unexpected automation changes. Segment build hosts so a rogue runner cannot freely reach adjacent systems. | ||
Practitioner Guidance
What to watch for: treat unexpected runner enrollment, duplicate execution services, and unplanned host-side automation as high-signal events. A runner that appears without a clear ownership record or change approval should be investigated as a potential persistence mechanism, not dismissed as routine infrastructure drift.
Governance implication: ownership for build runner should sit with the team that controls CI/CD trust, not only with platform operations. If the organisation cannot answer who can register a runner, how long it lives, and how it is revoked, the environment is already too permissive for reliable automation assurance.
Practitioner takeaway: build trust should be verified at the runner layer, because a safe repository does not guarantee a safe execution path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
