ripgrep before 13 on Windows allows attackers to trigger execution of arbitrary programs from the current working directory via the -z/--search-zip or --pre flag.

Affected: crates.io: grep-cli

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`](https://docs.rs/grep-cli/0.1.6/grep_cli/fn.resolve_binary.html) helper function.

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

* A `DecompressionReader` will resolve decompression programs to absolute 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…