Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

Local directory executable lookup in sops (Windows-only)GHSA-x5c7-x7m2-rhmf

GHSA-x5c7-x7m2-rhmf is a security vulnerability in go.mozilla.org/sops/v3. A fix is available for go.mozilla.org/sops/v3 — see the affected versions and patch details below.

Also known asGO-2022-0410
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 21, 2024 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐹go.mozilla.org/sops/v3

Real-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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogo.mozilla.org/sops/v3all versions3.7.1go get go.mozilla.org/sops/v3@v3.7.1

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.mozilla.org/sops/v3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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.

  3. 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.

Frequently Asked Questions

### 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](https://docs.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-searchpatha). This is a result of these Windows tools including `.` within their `PATH` by default. **If you
O3 Security · Impact-Aware SCA

Is GHSA-x5c7-x7m2-rhmf in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
Local directory executable lookup in sops (Windows-only)