ESLint version 0.7.2 represents a minor update over its predecessor, version 0.7.1, within the popular JavaScript linting tool. Both versions share the same core functionality, providing developers with a powerful means to enforce code style consistency and identify potential errors in their JavaScript projects. Core dependencies remain identical, including essential packages like Esprima for parsing, Esprima for pattern checking, js-yaml for configuration file handling, and minimatch for globbing file paths. The developer dependencies also remain the same.
The key distinction between the two versions lies in the timing of their release. Version 0.7.2 was published on July 8th, 2014, a day after version 0.7.1 which was released on July 7th, 2014. This suggests that version 0.7.2 is likely a patch release, addressing minor bugs or edge-case issues discovered shortly after the initial 0.7.1 release. While no specific bug fixes or feature additions are explicitly outlined in the provided data, the immediate succession of releases indicates a focused effort to refine the stability and reliability of ESLint.
For developers considering which version to use, opting for the newer 0.7.2 is generally advisable, as it likely incorporates improvements that enhance the overall linting experience. However, given the shared dependency structure and rapid release cycle, the functional differences are expected to be minimal and neither version introduces breaking changes. Developers should always consult the official ESLint changelog for a comprehensive understanding of specific changes in each release. Both versions ensures code quality and adheres to coding best practices.
All the vulnerabilities related to the version 0.7.2 of the package
debug Inefficient Regular Expression Complexity vulnerability
A vulnerability classified as problematic has been found in debug-js debug up to 3.0.x. This affects the function useColors of the file src/node.js. The manipulation of the argument str leads to inefficient regular expression complexity. Upgrading to version 3.1.0 is able to address this issue. The name of the patch is c38a0166c266a679c8de012d4eaccec3f944e685. It is recommended to upgrade the affected component. The identifier VDB-217665 was assigned to this vulnerability. The patch has been backported to the 2.6.x branch in version 2.6.9.
Regular Expression Denial of Service in debug
Affected versions of debug are vulnerable to regular expression denial of service when untrusted user input is passed into the o formatter.
As it takes 50,000 characters to block the event loop for 2 seconds, this issue is a low severity issue.
This was later re-introduced in version v3.2.0, and then repatched in versions 3.2.7 and 4.3.1.
Version 2.x.x: Update to version 2.6.9 or later. Version 3.1.x: Update to version 3.1.0 or later. Version 3.2.x: Update to version 3.2.7 or later. Version 4.x.x: Update to version 4.3.1 or later.
Denial of Service in js-yaml
Versions of js-yaml prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service.
Upgrade to version 3.13.0.
Code Injection in js-yaml
Versions of js-yaml prior to 3.13.1 are vulnerable to Code Injection. The load() function may execute arbitrary code injected through a malicious YAML file. Objects that have toString as key, JavaScript code as value and are used as explicit mapping keys allow attackers to execute the supplied code through the load() function. The safeLoad() function is unaffected.
An example payload is
{ toString: !<tag:yaml.org,2002:js/function> 'function (){return Date.now()}' } : 1
which returns the object
{
"1553107949161": 1
}
Upgrade to version 3.13.1.
Arbitrary Code Execution in underscore
The package underscore from 1.13.0-0 and before 1.13.0-2, from 1.3.2 and before 1.12.1 are vulnerable to Arbitrary Code Execution via the template function, particularly when a variable property is passed as an argument as it is not sanitized.
Regular Expression Denial of Service in underscore.string
Versions of underscore.string prior to 3.3.5 are vulnerable to Regular Expression Denial of Service (ReDoS).
The function unescapeHTML is vulnerable to ReDoS due to an overly-broad regex. The slowdown is approximately 2s for 50,000 characters but grows exponentially with larger inputs.
Upgrade to version 3.3.5 or higher.
Regular Expression Denial of Service in minimatch
Affected versions of minimatch are vulnerable to regular expression denial of service attacks when user input is passed into the pattern argument of minimatch(path, pattern).
var minimatch = require(“minimatch”);
// utility function for generating long strings
var genstr = function (len, chr) {
var result = “”;
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
var exploit = “[!” + genstr(1000000, “\\”) + “A”;
// minimatch exploit.
console.log(“starting minimatch”);
minimatch(“foo”, exploit);
console.log(“finishing minimatch”);
Update to version 3.0.2 or later.
minimatch ReDoS vulnerability
A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.