---
title: Tip: never put ${{ github.event.* }} text inside a run: script. Pass it through env: and quote the variable, which stops the issue-title injection used against 61 repos | ctxsec
url: https://ctxsec.com/items/tip-actions-pass-issue-pr-text-through-env-not-run
description: ""
status: "guidance (GitHub Actions hardening docs; motivated by Radware campaign, Oct 29)"
published: 2026-10-29
---

> 

[← Tips & Guides](/tips) · [markdown](/items/tip-actions-pass-issue-pr-text-through-env-not-run.md)

guidance (GitHub Actions hardening docs; motivated by Radware campaign, Oct 29)

2026-10-29

### Tip: never put ${{ github.event.* }} text inside a run: script. Pass it through env: and quote the variable, which stops the issue-title injection used against 61 repos

Bash runs `$(...)` even inside double quotes, so `echo "${{ github.event.issue.title }}"` executes whatever a stranger puts in a title. Do this instead:

```
env:
  TITLE: ${{ github.event.issue.title }}
run: printf '%s\n' "$TITLE"
```

Then set `permissions:` to the minimum per job (often `contents: read`), keep secrets out of jobs triggered by issues and comments, and do not `eval` the variable later. To find offenders across many repos, grep for `${{ github.event.` inside `run:` blocks or run an Actions linter such as zizmor or actionlint in CI. The same rule applies to AI review bots: treat issue and PR text as untrusted input and keep credentials away from them.

Sources: [GitHub Docs: Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections) · [Radware: Inside a GitHub supply chain attack campaign: command injection, attempts to exfiltrate CI/CD data, and evidence of execution (Oct 29)](https://www.radware.com/blog/inside-a-github-supply-chain-attack-campaign/)