GHSA-x5c7-x7m2-rhmf
GHSA-x5c7-x7m2-rhmf is a security vulnerability in go.mozilla.org/sops/v3. O3 Security confirms whether GHSA-x5c7-x7m2-rhmf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Local directory executable lookup in sops (Windows-only)
Real-World Exposure
go.mozilla.org/sops/v3Real-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
Windows users using the sops direct editor option (sops file.yaml) can have a local executable named either vi, vim, or nano executed if running sops from cmd.exe
This attack is only viable if an attacker is able to place a malicious binary within the directory you are running sops from. As well, this attack will only work when using cmd.exe or the Windows C library SearchPath function. This is a result of these Windows tools including . within their PATH by default.
If you are using sops within untrusted directories on Windows via cmd.exe, please upgrade immediately
As well, if you have . within your default $PATH, please upgrade immediately.
More information can be found on the official Go blog: https://blog.golang.org/path-security
Patches
The problem has been resolved in v3.7.1
Now, if Windows users using cmd.exe run into this issue, a warning message will be printed:
vim resolves to executable in current directory (.\vim.exe)
References
For more information
If you have any questions or comments about this advisory:
- Open a discussion in sops
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | go.mozilla.org/sops/v3 | all versions | 3.7.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.mozilla.org/sops/v3. 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 go.mozilla.org/sops/v3 to 3.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x5c7-x7m2-rhmf 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-x5c7-x7m2-rhmf 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-x5c7-x7m2-rhmf. 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-x5c7-x7m2-rhmf in your dependencies?
O3 detects GHSA-x5c7-x7m2-rhmf across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.