[static-analysis] RGS-018: Suspicious Payload Execution Pattern in smoke-test-tools.lock.yml #71350

🚨 Runner-Guard Security Finding

Rule: RGS-018 — Suspicious Payload Execution Pattern
Severity: High
File: .github/workflows/smoke-test-tools.lock.yml
Line: 1100

Description

A workflow run: block contains code patterns associated with obfuscated payload execution or known indicators of compromise (IOCs) from active supply chain attack campaigns. This includes eval+decode chains (e.g., eval(base64.b64decode(...)), base64 --decode | bash), known malware marker variables, persistence file paths, and C2 communication patterns. These patterns are loaded from Runner Guard's threat signature database, which can be updated independently of the scanner binary.

Investigation

This is a new finding (not present in the 2026-10-22 scan; first appearance in this scan). The flagged line (1100:1) anchors to the start of the generated Execute Pi CLI step. That step is gh-aw's standard agent-execution harness, which for the pi engine wraps the prompt dispatch in several nested layers:

bash "${RUNNER_TEMP}/gh-aw/actions/run_awf_with_startup_retries.sh" -- \
  awf --config ... \
  -- /bin/bash -c 'set +o histexpand; ... "$GH_AW_NODE_EXEC" .../shell_harness.cjs pi '\''export PATH=... && ... && cat /tmp/gh-aw/aw-prompts/user.txt | pi --print --mode json ... | tee /tmp/gh-aw/sandbox/agent/logs/pi-streaming.jsonl'\'''

The nested bash -c '...' layers, escaped single-quote re-entry ('\''), nested node ... shell_harness.cjs pi '...' invocation, and the final | tee *.jsonl combination resemble the shape of an obfuscated payload-execution chain to the signature heuristic, even though every piece is gh-aw's own generated, non-attacker-controlled harness code (no eval, no base64 --decode, no external fetch of the executed payload).

This workflow uses engine: pi (.github/workflows/smoke-test-tools.md). Two other workflows compiled in the same run show the identical new finding, all three using engine: pi: super-linter.lock.yml:1002 and video-analyzer.lock.yml:970 (filed as companion issues). This strongly suggests the trigger is specific to the Pi-engine's generated execution wrapper shape, not to anything specific to these 3 workflows' prompts.

Impact

If genuine, this pattern would indicate the workflow executes attacker-controlled, obfuscated code at runtime. In this case the executed content is the fixed gh-aw-generated harness script (shell_harness.cjs + awf sandbox wrapper), not user- or attacker-supplied code, so the practical risk is assessed as a likely false positive triggered by the Pi engine's specific nested-quoting invocation shape. This should still be confirmed by someone familiar with the Runner Guard signature internals, since a systemic false-positive on every engine: pi workflow would recur on every scan until addressed.

Remediation

1. Confirm with the Runner Guard signature maintainers (or by inspecting the matched IOC/pattern locally) which part of the nested bash -c / shell_harness.cjs pi invocation trips the heuristic.

2. If confirmed as a false positive specific to the Pi engine's generated wrapper, either:

   • Add a runner-guard:ignore RGS-018 suppression comment to the generated step (via the compiler template that emits the Execute Pi CLI step, so it survives gh aw compile/make recompile regeneration — do not hand-edit only the .lock.yml), with a comment explaining this is the standard gh-aw Pi-engine harness, or
   • Simplify the Pi-engine wrapper's nested-quoting shape if it can be restructured without the repeated bash -c '...' re-entry.

3. Re-run gh aw compile with runner-guard enabled afterward to confirm the finding no longer appears for any engine: pi workflow.

Detected by runner-guard v2.6.0 — CI/CD source-to-sink vulnerability scanner
Workflow run: https://github.com/github/gh-aw/actions/runs/39902213528

Generated by 📊 Static Analysis Report · claude · agent · ~323 AIC · ⌖ ~1 AIC · ⊞ 7.2K · ◷

• expires on Oct 29, 2026, 9:25 PM UTC-08:00