NYC version 11.8.0 represents a minor update to the popular command-line interface for Istanbul, a code coverage tool for JavaScript. Compared to the previous stable release, version 11.7.3, there aren't any significant changes in dependencies, both direct and development related. The core functionality remains consistent, indicating a focus on stability and incremental improvements rather than introducing groundbreaking features.
Both versions share the same fundamental set of dependencies, ensuring a consistent and predictable environment for developers. Libraries like glob for file matching, yargs for command-line argument parsing, and Istanbul's core libraries (istanbul-lib-*) for instrumentation and reporting are identical. Similarly, development dependencies like mocha for testing, standard for code style, and coveralls for coverage reporting remain unchanged.
The notable difference lies in the dist metadata. Version 11.8.0 has a slightly larger fileCount (4743 vs 4742) and unpackedSize (14134680 vs 14132787 bytes) compared to v11.7.3. This small increase implies minor adjustments, potentially bug fixes, documentation updates, or very small internal code improvements. The later releaseDate for v11.8.0 also confirms it's a more recent build.
For developers using NYC, this update suggests a continued commitment to maintaining a robust and dependable code coverage tool. Upgrading from version 11.7.3 to 11.8.0 should pose minimal risk of breaking changes, while potentially benefiting from subtle enhancements and bug fixes, even if not explicitly documented. It's recommended to upgrade to ensure using the latest stable version that provide the best code coverage reports.
All the vulnerabilities related to the version 11.8.0 of the package
Denial of Service in mem
Versions of mem prior to 4.0.0 are vulnerable to Denial of Service (DoS). The package fails to remove old values from the cache even after a value passes its maxAge property. This may allow attackers to exhaust the system's memory if they are able to abuse the application logging.
Upgrade to version 4.0.0 or later.
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.
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