An action can set environment variables and add folders to the PATH for every later step in the same job, by writing to the GITHUB_ENV and GITHUB_PATH files. So a third-party action's reach does not end with its own step. Keep untrusted actions in their own job, away from the steps that hold credentials.
What the files do
GitHub's workflow command reference describes both.
- Variables written to GITHUB_ENV become available to all subsequent steps in the job. The step that sets one cannot read the new value itself.
- GITHUB_PATH adds a directory to the system PATH for later actions in the job. The currently running action cannot see the updated path.
- GITHUB_OUTPUT sets a step output, which needs a step id to retrieve.
There are guardrails. You cannot overwrite default variables named with a GITHUB or RUNNER prefix, and for security reasons GITHUB_ENV cannot be used to set NODE_OPTIONS.
Why this matters for third-party actions
Writing to these files is normal. Setup actions do it to put a tool on the PATH or to set a home directory. The same mechanism lets any action influence what later steps do.
Consider a step later in the job that runs a command by name. If an earlier action added a directory to the front of PATH, the command that runs is whichever matching program is found first. If an earlier action set a variable that a later tool reads, such as a registry address or a proxy, that tool follows it.
None of this means setup actions are malicious. It means the order of steps is a trust boundary, which is easy to forget when a workflow looks like a flat list.
Practical ways to limit it
- Split by sensitivity. Put steps that use third-party actions in one job with minimal permissions, and steps that hold deploy credentials in another job, linked by explicit artifacts or outputs.
- Order matters inside a job. Run sensitive steps before an unfamiliar action, not after.
- Print and inspect. For a new action, add a temporary step that prints the environment names and the PATH, and compare before and after.
- Prefer calling tools by full path in release and signing steps, so a changed PATH has no effect.
- Treat outputs as untrusted input. If a later script interpolates an output into a shell command, an unexpected value can alter the command. Pass values through an environment variable and quote them, as GitHub's guidance on script injection recommends.
- Review the action's source for writes to GITHUB_ENV and GITHUB_PATH. A search for those names is a quick first pass when you vet an action.
A rule of thumb for job design
| Job type | What it holds | Third-party actions |
|---|---|---|
| Build and test | Read-only token | Allowed, pinned |
| Release or deploy | Environment secrets or cloud role | Minimal, reviewed, or none |
| Scan and report | Read token, maybe write to pull requests | Pinned, narrow permissions |
Pair this with limits on the token. See GitHub Actions token permissions and least privilege, and for how an input value turns into a shell command, the intermediate environment variable fix.
What to check in a review
When someone proposes a new action in a pull request, ask four questions. Does it write to the environment or PATH files? Does the job it joins hold secrets? Could the step be moved to a separate job? Is the reference pinned to a full commit SHA? Four yes or no answers take a couple of minutes and catch most of the risk that this mechanism creates.
Quick check
Can a step change the PATH for a later step?
Yes. Writing a directory to GITHUB_PATH adds it for later steps in the same job, but not for the step doing the writing.
Does the change carry to other jobs?
Not through these files. Environment and PATH changes apply within one job. On GitHub-hosted runners each job starts clean. On persistent self-hosted runners, do not assume that.
Sources
Last reviewed: 19 October 2026.
