GHSA-jmp2-wc4p-wfh2
LOWMutagen list and monitor operations do not neutralize control characters in text controlled by remote endpoints
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/mutagen-io/mutagen🐹github.com/mutagen-io/mutagen-compose🐹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 command line operations, as well as the log output from mutagen daemon run, are susceptible to control characters that could be provided by remote endpoints. This can cause terminal corruption, either intentional or unintentional, if these characters are present in error messages, file paths/names, and/or log output. This could be used as an attack vector if synchronizing with an untrusted remote endpoint, synchronizing files not under control of the user, or forwarding to/from an untrusted remote endpoint. On very old systems with terminals susceptible to issues such as CVE-2003-0069, the issue could theoretically cause code execution.
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.
One caveat is that the templating functionality of Mutagen's list and monitor commands has been only partially patched. In particular, the json template function already provided escaping and no patching was necessary. However, raw template output has been left unescaped because this raw output may be necessary for commands which embed Mutagen. To aid these commands, a new shellSanitize template function has been added which provides control character neutralization in strings.
Workarounds
Avoiding synchronization of untrusted files or interaction with untrusted remote endpoints should mitigate any risk.
References
A similar issue can be seen in kubernetes/kubernetes#101695.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/mutagen-io/mutagen | all versions | 0.16.6 |
| 🐹Go | github.com/mutagen-io/mutagen-compose | all versions | 0.17.1 |
| 🐹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-jmp2-wc4p-wfh2 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-jmp2-wc4p-wfh2 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-jmp2-wc4p-wfh2. 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-jmp2-wc4p-wfh2 in your dependencies?
O3 detects GHSA-jmp2-wc4p-wfh2 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.