Triaging Runner.Worker Memory Read

You received a Runner.Worker Memory Read detection. Another process on the runner read the memory of the GitHub Actions Runner.Worker process. Because GitHub Actions secrets are decrypted into that process at job runtime, anything that can read its memory can lift GITHUB_TOKEN, OIDC tokens, registry credentials, and any other secrets the job uses. The detection has a very low false-positive rate. Use this runbook to decide whether the reader was malicious or a legitimate diagnostic tool.

How it's detected

The Harden-Runner agent watches for any process opening and reading the memory of the Runner.Worker process, typically via /proc/<pid>/mem or ptrace on Linux. When the read occurs, the agent reports the reader's executable and command line.

Triage

Likely a compromise (true positive)

A step or dependency attaches to Runner.Worker and scrapes its address space to lift in-memory secrets: GITHUB_TOKEN, OIDC tokens, registry credentials, or other secrets the runner has decrypted for the job. Nothing in a normal CI job has a reason to read another process's memory, which is what makes this signal high-fidelity. Both the aquasecurity/trivy-action compromise and the tj-actions/changed-files compromise used this technique: the malicious payload read Runner.Worker memory to exfiltrate the job's secrets and tokens.

Treat the detection as a confirmed compromise unless you can clearly identify the reader as a legitimate tool. Take the following actions:

• Identify the reader from the detection (executable path and command line).

• Trace the reader back to a workflow step, dependency, or action.

• Rotate every secret the affected workflows had access to, including GITHUB_TOKEN. Revoke any artifacts, branches, or releases created during the affected runs.

• Audit downstream activity (commits, releases, package publishes) made during the affected runs.

• Block the offending action or dependency, and check the Threat Center for related advisories.

Consider enabling Lockdown Mode for Runner.Worker Memory Read so future occurrences terminate the job automatically.

Likely benign (false positive)

Legitimate diagnostics or profiling tools (debuggers, core-dump collectors, memory profilers) may perform the same /proc/<pid>/mem or ptrace reads against the worker. The behavior is identical to credential theft, so the detection fires even when the reader was intentionally installed by the workflow author.

Before treating the detection as benign, verify all of the following:

• The reader is a known, named tool (e.g., gdb, delve, a core-dump utility, a memory profiler).

• The tool was added to the workflow deliberately by an author you trust.

• The tool is being used for its stated purpose in that job (debugging a failing test, profiling a specific binary), not running against Runner.Worker specifically.

• The reader did not make outbound network calls that look like exfiltration during the same run.

If all checks pass, suppress the detection with the reason "Legitimate diagnostic tool."

Next steps

• If confirmed compromise: rotate secrets immediately and follow your incident response process. Resolve the detection once remediation is complete.

• If false positive: suppress per How to Suppress a Detection.

• If uncertain: rotate secrets defensively and escalate. The cost of unnecessary rotation is much lower than the cost of missing a real compromise on this detection.