GHSA-vh25-5764-9wcr @conventional-changelog/git-client has Argument Injection vulnerability

• npm @conventional-changelog/git-client: < 2.0.0 → fixed in 2.0.0

Background on exploitation This vulnerability manifests with the library's `getTags()` API, which allows specifying extra parameters passed to the `git log` command. In another API by this library - `getRawCommits()` there are secure practices taken to ensure that the extra parameter `path` is unable to inject an argument by ending the `git log` command with the special shell syntax `--`. However, the library does not follow the same practice for `getTags()` not attempts to sanitize for user input, validate the given params, or restrcit them to an allow list. Nor does it properly pass command-line flags to the `git` binary using the double-dash POSIX characters (`--`) to communicate the end of options. Thus, allowing users to exploit an argument injection vulnerability in Git due to the `--output=` command-line option that results with overwriting arbitrary files. Exploit 1. Install `@conventional-changelog/[email protected]` or earlier 2. Prepare a Git directory to be used as source 3. Create the following script for the proof-of-concept: ```js import { GitClient, } from "@conventional-changelog/git-client"; async function main() { const gitDirectory = "/tmp/some-git-directory"; const client = new GitClient(gitDirectory); const params = ["--output=/tmp/r2d2"]; for await (const tag of client.getTags(params)) { console.log(tag); } } main(); ``` 3. Observe new file created on disk at `/tmp/r2d2` Impact While the scope is only limited to writing a file with input from the git log result, it still allows to specify and overwrite any arbitrary files on disk, such as `.env` or as far as critical system configuration at `/etc` if the application is running as privileged `root` user. It may be the library's design choice to expose a generic `params` object to allow any consuming users to specify random Git command line arguments, however it could be abused by attackers when developers aren't aware of the security risks which aren't communicated. As such, I recommend not ignoring, and either patching this insecure design gap with hardened secure coding practices (like in other APIs mentioned previously) or adding a security disclaimer to this library's documentation. Author / Credit Liran Tal