GHSA-fwj4-72fm-c93g
Under-validated ComSpec and cmd.exe resolution in Mutagen projects
Blast Radius
github.com/mutagen-io/mutagen🐹github.com/mutagen-io/mutagenReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Mutagen projects offer shell-based execution functionality. On Windows, the shell is resolved using the standard %ComSpec% mechanism, with a fallback to a %PATH%-based search for cmd.exe. While this is the standard practice on Windows systems, it presents somewhat risky behavior.
Firstly, %ComSpec% could, in theory, be set maliciously. Unfortunately, there's not much that can be done to prevent this attack surface, because %ComSpec% is the official mechanism for shell specification on Windows. We can, however, validate that it points to an absolute path, which one would expect for a properly set value.
Secondly, a fallback to a relative cmd.exe path, resolved via %PATH%, could be risky. The risk is largely mitigated by changes in Go 1.19 and later, but prior to that a malicious cmd.exe could been resolved in the current working directory. To mitigate this issue, Mutagen now uses the %SystemRoot% environment variable (also validated to be an absolute path) to resolve cmd.exe in the event that %ComSpec% is not set correctly.
Patches
The problem has been patched in Mutagen v0.16.6 and v0.17.1. Earlier versions of Mutagen are no longer supported and will not be patched. Versions of Mutagen after v0.18.0 will also have the patch merged.
Workarounds
Maintain control of the environment variable settings on your system, in particular the ComSpec environment variable.
References
More information on %ComSpec% can be found online.
More information on Go's PATH-based lookup changes can be found here, here, and here.
A similar issue that was addressed within the Python subprocess module also provides additional discussion.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/mutagen-io/mutagen | all versions | 0.16.6 |
| 🐹Go | github.com/mutagen-io/mutagen | ≥ 0.17.0&&< 0.17.1 | 0.17.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/mutagen-io/mutagen. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/mutagen-io/mutagen to 0.16.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fwj4-72fm-c93g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fwj4-72fm-c93g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fwj4-72fm-c93g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fwj4-72fm-c93g in your dependencies?
O3 detects GHSA-fwj4-72fm-c93g across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.