Summary
External input from github.event.issue.title is used unsafely in a shell command in .github/workflows/release-candidate.yaml, allowing command injection during workflow execution.
Details
In .github/workflows/release-candidate.yaml, the issue title is interpolated directly into a shell command:
export VERSION=$(echo ${{ github.event.issue.title }} | sed -E 's/Release v?([0-9\.]*)/\1/g')
Because the issue title is attacker-controlled and is embedded directly into a shell command, shell metacharacters such as command substitution ($()) and command separators (;) can be interpreted by the shell.
Although the workflow checks that the title starts with Release , this condition can still be satisfied by a maliciously crafted input.
PoC
Create or edit an issue with the following title:
Release v1.2.3 $(whoami)Trigger the workflow that processes the issue.
Observe that the injected command is executed on the runner.
The workflow logs show that $(whoami) is evaluated and its output (runner) appears in the command result, confirming that attacker-controlled input is executed within the shell.
Impact
This vulnerability allows command injection in the GitHub Actions runner through attacker-controlled issue titles. An attacker may be able to execute arbitrary commands within the context of the affected workflow job.
Depending on the workflow configuration (such as permissions and available secrets), successful exploitation could lead to:
- Unauthorized command execution in the CI environment
- Misuse of the
GITHUB_TOKEN - Modification of repository state, release artifacts, or other workflow outputs
If the repository is public and allows untrusted users to create or reopen issues that trigger the workflow, this may be exploitable by external users.
This issue is limited to the repository's internal workflow configuration and does not directly affect downstream users of the published actions-mkdocs GitHub Action.
Untrusted input is inserted into a command that is later executed by the application, allowing the attacker to alter the intent of that command. Typical impact: arbitrary command execution in the application's environment.
GHSA-6P2J-742G-835F has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.25.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-6P2J-742G-835F? GHSA-6P2J-742G-835F is a medium-severity command injection vulnerability in Tiryoh/actions-mkdocs (actions), affecting versions <= 0.24.0. It is fixed in 0.25.0. Untrusted input is inserted into a command that is later executed by the application, allowing the attacker to alter the intent of that command.
- How severe is GHSA-6P2J-742G-835F? GHSA-6P2J-742G-835F has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of Tiryoh/actions-mkdocs are affected by GHSA-6P2J-742G-835F? Tiryoh/actions-mkdocs (actions) versions <= 0.24.0 is affected.
- Is there a fix for GHSA-6P2J-742G-835F? Yes. GHSA-6P2J-742G-835F is fixed in 0.25.0. Upgrade to this version or later.
- Is GHSA-6P2J-742G-835F exploitable, and should I be worried? Whether GHSA-6P2J-742G-835F is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-6P2J-742G-835F is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-6P2J-742G-835F? Upgrade
Tiryoh/actions-mkdocsto 0.25.0 or later.