Runner Memory Scraping

Expanded Definition

Runner memory scraping is a post-exploitation technique that targets the execution environment of a build or ci runner rather than the repository, vault, or disk. In practice, an attacker with code execution, job injection, or privileged access to the runner can inspect live process memory and recover credentials, session tokens, API keys, or certificates that were temporarily loaded for the job.

Definitions vary across vendors on whether this is treated as a secrets exposure issue, a pipeline compromise, or an NHI abuse pattern. NHI Management Group treats it as a distinct control problem because the secret may never be written to disk, never appear in logs, and still be extractable from the process boundary. That makes it different from conventional secret theft from config files or artifact stores. For implementation context, the EU Cyber Resilience Act reinforces the broader expectation that software systems should resist avoidable compromise in their operational environment, including build-time exposure paths.

The most common misapplication is assuming secret masking or encrypted storage alone prevents runner memory scraping, which occurs when a pipeline injects plaintext credentials into a live process and an attacker can inspect that process before teardown.

Examples and Use Cases

Implementing runner hardening rigorously often introduces friction for developers and platform teams, requiring organisations to weigh faster builds and easier debugging against reduced exposure of ephemeral credentials.

• A CI job uses cloud tokens to fetch private dependencies, and a malicious step reads them from the runner process before the job completes.
• An AI agent build pipeline loads service account credentials into memory to sign outbound requests, creating a window for memory inspection by a compromised runner.
• A self-hosted runner is reused across jobs, allowing one build to scrape another job’s residual memory state if isolation is weak.
• A secret injection plugin masks console output but leaves plaintext values in runtime memory, which an attacker extracts after gaining code execution in the job context.
• After a real-world exposure pattern like the McDonald's McHire AI Chatbot Default Credentials case, teams often reassess whether pipeline-authenticated automation is protected by design or merely obscured from view.

Operational guidance from NHI Management Group aligns with the broader lesson in the Ultimate Guide to NHIs: secrets that exist only briefly are still high-value if the surrounding execution environment is not trusted.

Why It Matters in NHI Security

Runner memory scraping matters because it turns short-lived automation into a secrets harvest point. Once a token, certificate, or API key is in memory, a compromised runner can bypass the protections that teams associate with vaulting, masking, or repository hygiene. That shifts the security question from “where is the secret stored?” to “who can observe the process that uses it?”

This is especially important in NHI security because runner workloads often hold privileges far beyond their visible footprint. NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which helps explain why runtime exposure is so consequential. Memory scraping also intersects with broader supply chain and software robustness expectations under the EU Cyber Resilience Act when build systems become a place where compromise can propagate outward.

Organisations typically encounter the full impact only after a runner is compromised and downstream systems show suspicious API activity, at which point runner memory scraping becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who should own response when browser memory scraping exposes identity data?
• Runner Memory Exposure
• Browser memory scraping
• What is the difference between screen scraping and API-based banking access?