Motivation
The GCP deploy workflows interpolate workflow_call / workflow_dispatch inputs directly into run: shell blocks:
zfnd-deploy-nodes-gcp.yml: inputs.environment / network / zone / log_filezfnd-deploy-integration-tests-gcp.yml: test_id, network, app_name, state dirs, flags, etc.
This is the pattern GitHub's security hardening guidance for GitHub Actions calls out: an expression interpolated into a run: script is substituted before the shell parses it, so a value containing shell metacharacters breaks out of its quoting context. The recommended fix is to bind the input to an env: variable and reference the shell variable (quoted) instead.
These particular inputs are operator-controlled via workflow_dispatch/workflow_call (so a caller already needs workflow access), which makes this defense-in-depth rather than a remotely triggerable hole, but the env-first pattern also protects against the inputs ever becoming caller-influenced and keeps the workflows consistent with the rest of the hardened CI surface.
Proposed fix
Bind each input through env: before shell use in both workflows; no behavior change for well-formed values.
A ready-made patch is in #11189 (closed pending this issue); happy to reopen it or rebase as preferred.
Motivation
The GCP deploy workflows interpolate
workflow_call/workflow_dispatchinputs directly intorun:shell blocks:zfnd-deploy-nodes-gcp.yml:inputs.environment/network/zone/log_filezfnd-deploy-integration-tests-gcp.yml:test_id,network,app_name, state dirs, flags, etc.This is the pattern GitHub's security hardening guidance for GitHub Actions calls out: an expression interpolated into a
run:script is substituted before the shell parses it, so a value containing shell metacharacters breaks out of its quoting context. The recommended fix is to bind the input to anenv:variable and reference the shell variable (quoted) instead.These particular inputs are operator-controlled via
workflow_dispatch/workflow_call(so a caller already needs workflow access), which makes this defense-in-depth rather than a remotely triggerable hole, but the env-first pattern also protects against the inputs ever becoming caller-influenced and keeps the workflows consistent with the rest of the hardened CI surface.Proposed fix
Bind each input through
env:before shell use in both workflows; no behavior change for well-formed values.A ready-made patch is in #11189 (closed pending this issue); happy to reopen it or rebase as preferred.