GitHub Actions injection enables Emissary repo and release poisoning

TL;DR — Shell injection in Emissary’s GitHub Actions workflows can let repo writers run arbitrary commands in CI and potentially poison releases consumed by downstream users.

What happened

Emissary is a P2P, data-driven workflow engine that ships as an open-source project with CI/CD automation via GitHub Actions. A GitHub Security Advisory (GHSA-3g6g-gq4r-xjm9) reports that three GitHub Actions workflow files contained multiple shell injection points where user-controlled workflow_dispatch inputs were interpolated directly into shell commands using ${{ }} expressions.

The advisory describes how ${{ }} expressions inside run: blocks are substituted before the shell parses the command; if untrusted inputs are placed directly into a run: block, an attacker who can trigger the workflow can inject shell syntax and execute arbitrary commands with the workflow’s token permissions.

This is a high-impact CI/CD class issue because workflow runners commonly hold powerful credentials (GITHUB_TOKEN, release keys, package publishing creds). Once CI is a code-execution surface, it becomes a practical path to repository poisoning and supply-chain compromise, not just “CI breakage.”

Who is impacted

• Repositories using Emissary versions listed as affected (5.10.0 - 8.38.0).
• Organizations that run or fork Emissary and keep the affected workflow files in .github/workflows/ (the advisory calls out .github/workflows/maven-version.yml, .github/workflows/cherrypick.yml, and .github/workflows/maven-release.yml).
• Downstream consumers who build or deploy artifacts from a compromised repository (the advisory explicitly frames this as supply-chain impact).
• Any environment where users with repository write access can trigger workflow_dispatch workflows (including automation accounts with write privileges).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "There is no workaround other than upgrading."

• If you forked the project or copied its workflow patterns, apply the same mitigation approach described in the advisory (do not directly interpolate untrusted inputs into run: scripts):

  "Organizations that have forked Emissary should apply the same environment variable indirection and input validation patterns to their workflow files."

• Treat this as a potential CI credential exposure and repository integrity event:
  • audit GitHub Actions runs for suspicious workflow_dispatch executions and unexpected workflow inputs
  • review recent tags/releases/commits for unauthorized changes
  • rotate any secrets that could have been available to the affected workflows (package publishing tokens, signing keys, cloud credentials)
• As a broader hardening step, scan internal workflows for the same anti-pattern: ${{ github.event.inputs.* }} (or other attacker-influenced fields) used directly inside run: blocks without strict validation/quoting.