Primary finding
Script injection via Telegram/Discord/Slack message text in poll job
criticalsecurityhigh
- .github/workflows/messages.yml:138-144
- .github/workflows/messages.yml:71-80
The audit article in this PR claims the Extract message and Run steps are now safe because they use env-var intermediaries for `inputs.message`. That is true for the `run` job. However, the upstream `poll` job still performs unsafe shell interpolation of attacker-controlled text. `TEXT` is set from `jq -r` (raw, unescaped) on `result[$i].message.text`, then passed as `-f message="$TEXT"` to `gh workflow run`. While the `gh` argument itself is quoted properly (so command injection through the `gh` invocation does not occur), the same `TEXT` is also echoed unquoted-safely via `echo "Telegram: $TEXT"` which is benign — but more importantly, the message body is later piped into Claude as a prompt (`PROMPT="...\"$MESSAGE\"..."` in the run job). Any external user able to post in the configured Telegram chat / Discord channel / Slack channel can deliver an arbitrary instruction string to the Claude agent which has access to `GH_GLOBAL`, `ANTHROPIC_API_KEY`, `ALCHEMY_API_KEY`, and write permissions to the repo. The article's documented fix only addresses shell-template injection (the `${{ }}` substitution layer); it does not address prompt injection or trust-boundary issues for the message content itself. This is a real, exploitable vulnerability that the PR's audit explicitly misses.
Recommendation
Either (a) restrict message processing to authenticated sender IDs (verify `from.id`/`author.id`/`user` against an allowlist before dispatching), (b) sandbox the Claude run with a far tighter allowedTools set that excludes outbound network and `gh`/`git`, or (c) drop secrets like ALCHEMY_API_KEY, COINGECKO_API_KEY, GH_GLOBAL from the Run step's env unless absolutely required. At minimum, document the trust model explicitly in the audit article rather than implying the workflow is now secure.