fix(security): pipe action inputs through env vars (HIGH; shell injection)

[mikemolinet]

Summary

Closes the HIGH shell-injection finding from cueapi-secondary's cross-agent review on PR #2. Pre-existing on main; filing as a standalone follow-up so the fix can ship independently of PR #2's review cadence.

The vulnerability

The current `action.yml` interpolates inputs directly into the bash script:

```yaml
[ -n "${{ inputs.payload }}" ] && cmd+=(--payload "${{ inputs.payload }}")
[ -n "${{ inputs.cue-id }}" ] && cmd+=("${{ inputs.cue-id }}")
```

GitHub Actions documents this as a classic injection vector. A workflow caller passing `payload: '"; rm -rf /; #'` (or any number of variations) gets arbitrary shell execution at the runner.

The worst case is the `command` interpolation in the case-statement value at line 90 — a malicious value like `create) ; rm -rf / ; #` could escape the case construct entirely and execute attacker-controlled commands before the case dispatcher even sees the input.

14 inputs were vulnerable: `command`, `name`, `cron`, `at`, `url`, `method`, `timezone`, `payload`, `description`, `worker`, `cue-id`, `status`, `limit`, `cli-version`. Every caller of `cueapi/cueapi-action@v1` is affected today.

The fix

Pipe every caller-supplied input through env vars in the step's `env:` block, then reference each as `$VAR_NAME` in the script. Bash quotes env-var expansion automatically, so `"$NAME"` is safe regardless of caller input.

This is the documented standard pattern.

```yaml
env:
COMMAND: ${{ inputs.command }}
NAME: ${{ inputs.name }}

...

run: |
set -euo pipefail
cmd=(cueapi "$COMMAND")
case "$COMMAND" in
create)
[ -n "$NAME" ] && cmd+=(--name "$NAME")
# ...
```

A comment block above the `env:` section flags the pattern for future contributors so the vulnerability isn't silently re-introduced when adding new inputs.

Coordination with PR #2

PR #2 (`feat: expose cueapi 0.2.0 fire + executions subgroup commands`) adds 16 new input references on the same vulnerable pattern. When this PR lands first, PR #2 will need a small rebase to follow the env-var pattern for its new inputs — straightforward mechanical change. Filing standalone keeps this fix on its own review track, so the hosted users on `@v1` get the fix even if PR #2 stays in Govind's review queue for a while.

Test plan

• `python3 -c "import yaml; yaml.safe_load(open('action.yml'))"` — YAML valid
• No behavior change for legitimate callers — same env-var expansion semantics, same `cmd=(...)` array assembly, same `cueapi` invocation
• No new dependencies, no new runtime cost (env vars are already standard YAML composite-action plumbing)

Cross-references

• Original review surfacing this: feat: expose cueapi 0.2.0 fire + executions subgroup commands #2 (cueapi-secondary, 2026-05-04)
• CTO directive to scope-confirm and ship: token `CTO-SEC-630-REVIEW-PICK-ACK` follow-up via PM (2026-05-05)

🤖 Generated with Claude Code