> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/github-actions/harden-runner/runbooks/triaging-runner.worker-memory-read.md).

# 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.

{% hint style="info" %}
Consider enabling [Lockdown Mode](/github-actions/harden-runner/policy-store.md#lockdown-mode) for Runner.Worker Memory Read so future occurrences terminate the job automatically.
{% endhint %}

#### **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](/github-actions/harden-runner/detections.md#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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stepsecurity.io/github-actions/harden-runner/runbooks/triaging-runner.worker-memory-read.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.