RUSTSEC-2021-0071: `grep-cli` may run arbitrary executables on Windows

What to do

1. See which version you have: cargo tree -i grep-cli (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p grep-cli. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example grep-cli = "0.1.6") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

On Windows in versions of grep-cli prior to 0.1.6, it's possible for some of the routines to execute arbitrary executables. In particular, a quirk of the Windows process execution API is that it will automatically consider the current directory before other directories when resolving relative binary names. Therefore, if you use grep-cli to read decompressed files in an untrusted directory with that directory as the CWD, a malicious actor to could put, e.g., a gz.exe binary in that directory and grep-cli will use the malicious actor's version of gz.exe instead of the system's.

This is also technically possible on Unix as well, but only if the PATH variable contains .. Conventionally, they do not.

A DecompressionReader has been fixed to automatically resolve binary names using PATH, instead of relying on the Windows API to do it.

If you use grep-cli's CommandReader with a std::process::Command value on Windows, then it is recommended to either construct the Command with an absolute binary name, or use grep-cli's new resolve_binary helper function.

To be clear, grep-cli 0.1.6 mitigates this issue in two ways:

paths automatically using the PATH environment variable, instead of relying on Windows APIs to do it (which would result in the undesirable behavior of checking the CWD for a program first).

• A DecompressionReader will resolve decompression programs to absolute

mitigate this behavior when they need to create their own std::process::Command. For example, ripgrep uses grep_cli::resolve_binary on the argument given to its --pre flag.

• A new function, resolve_binary, was added to help users of this crate

While the first mitigation fixes this issue for sensible values of PATH when doing decompression search, the second mitigation is imperfect. The more fundamental issue is that std::process::Command is itself vulnerable to this.

References

• Package: crates.io/crates/grep-cli
• Advisory: rustsec.org/advisories/RUSTSEC-2021-0071.html
• Report: github.com/BurntSushi/ripgrep/issues/1773

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.