The affected MCP add operation translated a caller-provided workflow name into a filesystem path. Components such as ../ could make the resolved destination leave .github/workflows/, even though the user-facing operation was presented as workflow import. The distinction is between accepting a string shaped like a name and authorizing the final file the…
Case · DiggingBeagle record
gh-aw imported workflow names could escape their intended directory
A user-influenced workflow name could escape .github/workflows during gh-aw MCP import because the resulting path was not contained after resolution.
Scope
Affected gh-aw MCP add tool before 0.91.12, with write access on the target repository filesystem; constrained by the generated file path and suffix, not arbitrary host command execution.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Impact
- Band 2 of 4
- Evidence
- Grade B
- Remediation
- fixed reported
- AI role
- AGAINST AI
Basis and provenance
GHSA-62c8-mmw9-rq5w documents traversal through filepath.Join and shows the malicious .md destination, with separate .yml circumstances. The merged fix is reported in v0.91.12. This is not equivalent to the higher-impact flag-injection issue sharing the advisory.
Impact basis: Untrusted workflow name values could write workflow-related files outside the intended .github/workflows directory. The constrained extension and path traversal are demonstrated; shell execution or subsequent CI compromise requires an additional step.
Assessed Oct 19, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-GHAW-MCP-NAME-TRAVERSAL · GHSA-62c8-mmw9-rq5w: gh-aw workflow path traversal
At a glance
A tool-name or parameter schema does not restrict filesystem effects when its implementation resolves a path outside the authorized root.
Read the implicationsThe advisory describes constrained write conditions, not unconstrained root filesystem execution. The implementation issue was fixed in v0.91.12 alongside the separate option-injection flaw.
Limits and uncertaintyFull account
The affected MCP add operation translated a caller-provided workflow name into a filesystem path. Components such as ../ could make the resolved destination leave .github/workflows/, even though the user-facing operation was presented as workflow import. The distinction is between accepting a string shaped like a name and authorizing the final file the server actually creates.
The demonstration requires the gh-aw server and its filesystem permissions. It does not amount to general access to every host file, and the imported workflow format and suffix constrain what can be written. It nevertheless gives a coding agent or other MCP caller a path to modifying objects outside the advertised workflow directory. A policy that allows workflow creation alone cannot be assumed to allow those writes.
The fix reported for 0.91.12 adds path containment. Reproduction should compare normalized paths on Linux and Windows and confirm that intended nested workflow names still work while traversal is refused before any file is created.
Claims & evidence
CLM-GHAW-MCP-NAME-TRAVERSALIn the affected gh-aw MCP add flow, the supplied workflow name was used as a path component without enforcing that the resulting file remained inside .github/workflows/.supported
Basis: reported finding
- supportsGHSA-62c8-mmw9-rq5w: gh-aw workflow path traversalprimary disclosure
Summary; Issue 2: path traversal; patched versions
Implications
A tool-name or parameter schema does not restrict filesystem effects when its implementation resolves a path outside the authorized root.
Controls and mitigations
- Validate normalized, resolved destination paths against an authorized directory before every write, including after symlink and platform-specific path processing.
Unknowns and contradictions
- The advisory describes constrained write conditions, not unconstrained root filesystem execution. The implementation issue was fixed in v0.91.12 alongside the separate option-injection flaw.
Sources and citation
Material revision history
- Oct 19, 2026 · Published version · first publication · revision 174
- Oct 19, 2026 · Canonical change recorded · material revision · revision 175Public fields changed: assessment_profile