NYC version 11.0.2 represents a minor update to the popular command-line interface for Istanbul, a code coverage tool. Comparing it to the previous stable version, 11.0.1, the primary difference lies in the updated dependency for spawn-wrap. Notably, version 11.0.1 uses spawn-wrap version 1.2.4, while 11.0.2 advances to version 1.3.6. While seemingly small, such dependency updates can bring various benefits, potentially including bug fixes, performance improvements related to child process handling, or enhanced compatibility with different environments.
NYC empowers JavaScript developers to measure the effectiveness of their tests. By instrumenting code and tracking which lines are executed during test runs, NYC generates detailed coverage reports, helping identify areas lacking sufficient testing. NYC supports various test runners, integrates seamlessly into existing workflows offering terminal reports, HTML reports, and more. For developers, this update signifies a continued commitment to stability and refinement. While the core functionality remains consistent, the updated spawn-wrap dependency highlights attention to detail and a proactive approach to maintaining compatibility and performance. Developers relying on spawn-wrap either directly or indirectly through NYC might find that this update resolves specific existing issues or improves the reliability of their test coverage reports. Moreover, using the latest version ensures you're benefiting from the most recent bug fixes and optimizations, contributing to a smoother and more reliable development experience.
All the vulnerabilities related to the version 11.0.2 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.
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.
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