# GHSA-6p2j-742g-835f: actions-mkdocs: Command Injection via issue title in internal GitHub Actions workflow > Attackers can execute arbitrary commands on CI runners by injecting shell metacharacters into GitHub issue titles processed by the workflow. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 4 Apr 2026 ## What is GHSA-6p2j-742g-835f? GHSA-6p2j-742g-835f is a command injection vulnerability in Tiryoh/actions-mkdocs, published on 4 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim. ### Official description ### 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 1. Create or edit an issue with the following title: ``` Release v1.2.3 $(whoami) ``` 2. Trigger the workflow that processes the issue. 3. 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. 스크린샷 2026-03-27 오후 8 33 43 ### 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. ## Which versions are affected by GHSA-6p2j-742g-835f? 1 open source package ship an affected version, including Tiryoh/actions-mkdocs. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `Tiryoh/actions-mkdocs` | GitHub Actions | All versions | 0.25.0 | ## How do I fix GHSA-6p2j-742g-835f? Upgrade Tiryoh/actions-mkdocs to 0.25.0 or later. ## Is GHSA-6p2j-742g-835f being exploited? There is no known exploitation of GHSA-6p2j-742g-835f in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-6p2j-742g-835f and fix it if it is affected. What it is: GHSA-6p2j-742g-835f is a command injection vulnerability in Tiryoh/actions-mkdocs, published on 4 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim. Exploitation: There is no known exploitation of GHSA-6p2j-742g-835f in the wild and no public exploit code. Affected packages and fixed versions: - Tiryoh/actions-mkdocs (GitHub Actions): affected all versions; fixed in 0.25.0 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-6p2j-742g-835f/ (Markdown: https://insights.sbomify.com/GHSA-6p2j-742g-835f/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-6p2j-742g-835f --- From sbomify Insights: https://insights.sbomify.com/GHSA-6p2j-742g-835f/ Summaries are generated and may contain mistakes; the official description above is the record.