githubtoplanguages: Command Injection via Issue Title in Discord Notification WorkflowGHSA-c3xh-98xp-6qhf
Fix: gouef/githubtoplanguages@1578404GHSA-c3xh-98xp-6qhf is a OS Command Injection vulnerability in gouef/githubtoplanguages. A fix is available for gouef/githubtoplanguages — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-c3xh-98xp-6qhf.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
gouef/githubtoplanguagesReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects GitHub Actions packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A GitHub Actions workflow is vulnerable to command injection through the issue title.
The workflow is triggered when an issue is opened or closed, and it directly inserts github.event.issue.title into a Bash variable assignment. If an issue title contains command substitution syntax, Bash evaluates it during the workflow run.
Details
The vulnerable workflow is:
.github/workflows/discord-issue.yml
The issue title is directly interpolated into a Bash script:
ISSUE_TITLE="${{ github.event.issue.title || github.event.pull_request.title }}"
Because GitHub Actions expressions are expanded before Bash executes the script, an attacker-controlled issue title containing command substitution syntax can be evaluated by the shell.
In the original workflow, the resulting value is then included in a Discord notification payload:
curl -H "Content-Type: application/json" \
-X POST \
-d "{\"username\": \"GitHub Bot\", \"content\": \"${STATUS} created by **${AUTHOR}**: **${ISSUE_TITLE}**\n🔗 ${ISSUE_URL}\"}" \
"$DISCORD_WEBHOOK"
PoC
For safety, I reproduced this only in my fork. I did not trigger the original repository’s Discord webhook.
I kept the vulnerable Bash assignment unchanged and replaced the Discord webhook request with echo statements to observe the result safely.
Test issue title:
title: $(whoami)
Observed workflow log:
ISSUE_TITLE=title: runner
This confirms that $(whoami) was executed on the GitHub Actions runner before the value would be sent to Discord.
Impact
Any user who can open an issue may be able to execute shell commands on the GitHub Actions runner.
In practice, this means an attacker could create an issue with a crafted title, cause the workflow to execute a shell command, and have the command output included in the Discord notification content. This can be used to manipulate Discord notifications, spoof trusted GitHub bot messages, or repeatedly trigger unwanted notifications.
More importantly, the command runs in a workflow environment where a Discord webhook secret is configured. Depending on repository settings and workflow permissions, this may put workflow secrets or other environment data at risk.
Suggested Fix
Do not insert issue titles directly into Bash scripts.
Pass the title through an environment variable instead:
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
issue_title="$ISSUE_TITLE"
Also avoid eval, unquoted variable expansion, or shell execution patterns involving user-controlled issue content.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦GitHub Actions | gouef/githubtoplanguages | all versions | 1.1.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gouef/githubtoplanguages, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update gouef/githubtoplanguages to 1.1.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c3xh-98xp-6qhf is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is GHSA-c3xh-98xp-6qhf in your dependencies?
Find it across GitHub Actions, including transitive dependencies.