Lint-staged version 8.2.0 introduces subtle yet impactful changes compared to its predecessor, 8.1.7. Both versions of this popular npm package are designed to streamline the development workflow by linting files staged in Git, ensuring code quality before commits. A key dependency update in 8.2.0 involves the removal of find-parent-dir and no explicit replacement is specified. Developers relying on the features of find-parent-dir may need to assess the impact of this change on their workflows and consider alternative solutions if the package was being utilized directly or implicitly.
The package size sees a minor increase, with 8.2.0 having a slightly larger unpacked size (49977 bytes) and file count (17) compared to 8.1.7 (49797 bytes and 16 files). This suggests minor additions or adjustments within the package's internal structure that are not highlighted through changed dependencies, possibly updates of internal code. Both versions share a common set of core dependencies crucial for their functionality, including del, yup, pify, chalk, debug, execa, listr, p-map, dedent, lodash, is-glob, g-status, commander, npm-which, is-windows, micromatch, cosmiconfig, log-symbols, string-argv, path-is-inside, staged-git-files, stringify-object, please-upgrade-node, and listr-update-renderer.
Developers should carefully evaluate the absence of find-parent-dir in 8.2.0, alongside the small additional size, to verify compatibility with their projects. Lint-staged continues to offer a robust solution for automated code linting prior to commit, catching common errors and enforcing code style guidelines. The update from 8.1.7 to 8.2.0 seems to mainly impact internal dependency management, therefore requiring only a minor/patch update by users.
All the vulnerabilities related to the version 8.2.0 of the package
Prototype Pollution in property-expr
The package property-expr before 2.0.3 are vulnerable to Prototype Pollution via the setter function.
Command injection in simple-git
The package simple-git before 3.3.0 is vulnerable to Command Injection via argument injection. When calling the .fetch(remote, branch, handlerFn) function, both the remote and branch parameters are passed to the git fetch subcommand. By injecting some git options, it was possible to get arbitrary command execution.
Command injection in simple-git
simple-git
(maintained as git-js named repository on GitHub) is a light weight interface for running git commands in any node.js application.The package simple-git before 3.5.0 are vulnerable to Command Injection due to an incomplete fix of CVE-2022-24433 which only patches against the git fetch attack vector. A similar use of the --upload-pack feature of git is also supported for git clone, which the prior fix didn't cover. A fix was released in simple-git@3.5.0.
simple-git vulnerable to Remote Code Execution when enabling the ext transport protocol
The package simple-git before 3.15.0 is vulnerable to Remote Code Execution (RCE) when enabling the ext
transport protocol, which makes it exploitable via clone()
method. This vulnerability exists due to an incomplete fix of CVE-2022-24066.
Remote code execution in simple-git
Versions of the package simple-git before 3.16.0 are vulnerable to Remote Code Execution (RCE) via the clone(), pull(), push() and listRemote() methods, due to improper input sanitization. This vulnerability exists due to an incomplete fix of CVE-2022-25912.
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch
prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces()
in index.js
because the pattern .*
will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Uncontrolled resource consumption in braces
The NPM package braces
fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js,
if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.