NYC 8.3.1 is a minor release of the Istanbul command-line interface, a popular tool for measuring code coverage in JavaScript projects. Compared to its predecessor, version 8.3.0, this update brings several key dependency upgrades that developers should be aware of. The most notable change is the upgrade of yargs from version 5.0.0 to version 6.0.0, a widely used command-line argument parser that could affect how you configure NYC. Additionally, test-exclude sees an update from version 2.1.2 to 2.1.3, potentially impacting your test exclusion rules. Another significant dependency lift is yargs-parser, moving from version 3.1.0 to 4.0.2. Finally, istanbul-lib-source-maps gets bumped from 1.0.1 to 1.0.2.
While these upgrades may seem incremental, the core functionality of NYC for generating comprehensive coverage reports remains consistent. Developers can still rely on NYC for its robust features, including support for various reporting formats (HTML, text, lcov), seamless integration with testing frameworks like Mocha and Jest, and its ability to instrument code on-the-fly. The package continues to offer a wealth of configuration options through command-line arguments and configuration files, allowing developers to fine-tune the coverage analysis to their specific needs. Remember to review your configuration, particularly command-line arguments, to ensure compatibility with the updated yargs library. As with any new release, developers are encouraged to test the upgrade in a development environment before deploying to production.
All the vulnerabilities related to the version 8.3.1 of the package
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.
Regular Expression Denial of Service (ReDoS) in braces
A vulnerability was found in Braces versions prior to 2.3.1. Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.
Regular Expression Denial of Service in braces
Versions of braces prior to 2.3.1 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.
Upgrade to version 2.3.1 or higher.
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.
yargs-parser Vulnerable to Prototype Pollution
Affected versions of yargs-parser are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of Object, causing the addition or modification of an existing property that will exist on all objects.
Parsing the argument --foo.__proto__.bar baz' adds a bar property with value baz to all objects. This is only exploitable if attackers have control over the arguments being passed to yargs-parser.
Upgrade to versions 13.1.2, 15.0.1, 18.1.1 or later.
Regular Expression Denial of Service (ReDoS) in cross-spawn
Versions of the package cross-spawn before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.
Babel vulnerable to arbitrary code execution when compiling specifically crafted malicious code
Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the path.evaluate()or path.evaluateTruthy() internal Babel methods.
Known affected plugins are:
@babel/plugin-transform-runtime@babel/preset-env when using its useBuiltIns option@babel/helper-define-polyfill-provider, such as babel-plugin-polyfill-corejs3, babel-plugin-polyfill-corejs2, babel-plugin-polyfill-es-shims, babel-plugin-polyfill-regeneratorNo other plugins under the @babel/ namespace are impacted, but third-party plugins might be.
Users that only compile trusted code are not impacted.
The vulnerability has been fixed in @babel/traverse@7.23.2.
Babel 6 does not receive security fixes anymore (see Babel's security policy), hence there is no patch planned for babel-traverse@6.
@babel/traverse to v7.23.2 or higher. You can do this by deleting it from your package manager's lockfile and re-installing the dependencies. @babel/core >=7.23.2 will automatically pull in a non-vulnerable version.@babel/traverse and are using one of the affected packages mentioned above, upgrade them to their latest version to avoid triggering the vulnerable code path in affected @babel/traverse versions:
@babel/plugin-transform-runtime v7.23.2@babel/preset-env v7.23.2@babel/helper-define-polyfill-provider v0.4.3babel-plugin-polyfill-corejs2 v0.4.6babel-plugin-polyfill-corejs3 v0.8.5babel-plugin-polyfill-es-shims v0.10.0babel-plugin-polyfill-regenerator v0.5.3