Security issue: possible command injection in GitHub Actions workflow

[cicd-security]

Hello maintainers,

I would like to report a potential command-injection vulnerability in your GitHub Actions workflow.

The affected workflow file(s) invoke an LLM to process and summarize issues, and then directly concatenate the LLM output into a shell command argument for gh issue comment --body. Because untrusted model output is inserted into a shell command context, an attacker may craft a malicious issue so that the LLM response contains an injection payload.

Impact:

• Possible command injection during workflow execution.
• Possible leakage of sensitive environment variables (for example GITHUB_TOKEN or GH_TOKEN).
• Although these tokens are typically short-lived and scoped to workflow job/step execution, an attacker may attempt to prolong execution time (for example via sleep-based techniques) and abuse the token during that window.

Recommended remediation:

• Do not place ${{ steps.inference.outputs.response }} directly in a shell command argument.
• Pass it through a step environment variable first (for example RESPONSE).
• In shell, reference it only as a double-quoted variable (for example "$RESPONSE").

Affected workflow file(s) observed:

• https://github.com/RicardoRyn/plotfig/blob/fe17109225bff535e8825c4f36cc10acefa5632f/.github/workflows/summary_new_issues.yml

Thank you for your time and for maintaining this project.

[github-actions]

The issue reports a potential security vulnerability in a GitHub Actions workflow due to possible command injection. The workflow processes GitHub issues using a language model (LLM) and then concatenates the LLM's output directly into a shell command for . Since the LLM output is uncontrolled by default, an attacker could exploit this to include malicious payloads, leading to command injection. This could result in the exposure of sensitive environment variables such as or , which might be abused during the workflow's execution. To mitigate this issue, the reporter recommends avoiding direct insertion of the LLM response into shell commands, instead passing it through an environment variable and referencing it as a double-quoted variable in the shell. An affected workflow file is identified in the repository, and the reporter provides details to assist in resolving the issue.