Standard version 4.1.0 introduces key updates for JavaScript developers focused on code quality and consistency, building upon its predecessor, version 4.0.1. The most significant change lies in the updated dependency on eslint. Version 4.1.0 integrates a specific commit from the eslint repository directly from Github (git://github.com/eslint/eslint.git#fff52aecaf1d073952201b3f128e6664f529a24e), ensuring a precise and potentially cutting-edge set of linting rules. In contrast, version 4.0.1 relies on eslint version ^0.21.0, indicating a broader range of compatible versions. This means developers upgrading to 4.1.0 should be aware of potential changes in linting behavior due to the shift to a specific eslint commit which may lead to new warnings or errors in their codebase.
Another relevant difference is the version of eslint-config-standard. Version 4.1.0 uses eslint-config-standard version 3.1.0, while version 4.0.1 used ~2.0.0. This indicates updates to the set of standard ESLint rules and configurations used by the linter.
Both versions share a common set of core dependencies, including tools for file system operations, handling input, and managing asynchronous tasks. Developers will find familiar utilities like glob, uniq, and xtend are remain consistent across versions. Ultimately, the jump to eslint from Git in 4.1.0 requires developers to fully test their codebase when upgrading.
All the vulnerabilities related to the version 4.1.0 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.
Regular Expression Denial of Service (ReDoS)
A vulnerability was found in diff before v3.5.0, the affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.
Tmp files readable by other users in sync-exec
Affected versions of sync-exec
use files located in /tmp/
to buffer command results before returning values. As /tmp/
is almost always set with world readable permissions, this may allow low privilege users on the system to read the results of commands run via sync-exec
under a higher privilege user.
There is currently no direct patch for sync-exec
, as the child_process.execSync
function provided in Node.js v0.12.0 and later provides the same functionality natively.
The best mitigation currently is to update to Node.js v0.12.0 or later, and migrate all uses of sync-exec
to child_process.execSync()
.
semver vulnerable to Regular Expression Denial of Service
Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
Prototype Pollution in JSON5 via Parse Method
The parse
method of the JSON5 library before and including version 2.2.1
does not restrict parsing of keys named __proto__
, allowing specially crafted strings to pollute the prototype of the resulting object.
This vulnerability pollutes the prototype of the object returned by JSON5.parse
and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations.
This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from JSON5.parse
. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution.
This vulnerability is patched in json5 v2.2.2 and later. A patch has also been backported for json5 v1 in versions v1.0.2 and later.
Suppose a developer wants to allow users and admins to perform some risky operation, but they want to restrict what non-admins can do. To accomplish this, they accept a JSON blob from the user, parse it using JSON5.parse
, confirm that the provided data does not set some sensitive keys, and then performs the risky operation using the validated data:
const JSON5 = require('json5');
const doSomethingDangerous = (props) => {
if (props.isAdmin) {
console.log('Doing dangerous thing as admin.');
} else {
console.log('Doing dangerous thing as user.');
}
};
const secCheckKeysSet = (obj, searchKeys) => {
let searchKeyFound = false;
Object.keys(obj).forEach((key) => {
if (searchKeys.indexOf(key) > -1) {
searchKeyFound = true;
}
});
return searchKeyFound;
};
const props = JSON5.parse('{"foo": "bar"}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as user."
} else {
throw new Error('Forbidden...');
}
If the user attempts to set the isAdmin
key, their request will be rejected:
const props = JSON5.parse('{"foo": "bar", "isAdmin": true}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props);
} else {
throw new Error('Forbidden...'); // Error: Forbidden...
}
However, users can instead set the __proto__
key to {"isAdmin": true}
. JSON5
will parse this key and will set the isAdmin
key on the prototype of the returned object, allowing the user to bypass the security check and run their request as an admin:
const props = JSON5.parse('{"foo": "bar", "__proto__": {"isAdmin": true}}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as admin."
} else {
throw new Error('Forbidden...');
}
Prototype Pollution in lodash
Versions of lodash
before 4.17.12 are vulnerable to Prototype Pollution. The function defaultsDeep
allows a malicious user to modify the prototype of Object
via {constructor: {prototype: {...}}}
causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.12 or later.
Prototype Pollution in lodash
Versions of lodash
before 4.17.5 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object
via __proto__
causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.5 or later.
Prototype Pollution in lodash
Versions of lodash
before 4.17.11 are vulnerable to prototype pollution.
The vulnerable functions are 'defaultsDeep', 'merge', and 'mergeWith' which allow a malicious user to modify the prototype of Object
via {constructor: {prototype: {...}}}
causing the addition or modification of an existing property that will exist on all objects.
Update to version 4.17.11 or later.
Regular Expression Denial of Service (ReDoS) in lodash
lodash prior to 4.7.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.7.11.
Prototype Pollution in lodash
Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions pick
, set
, setWith
, update
, updateWith
, and zipObjectDeep
allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays.
This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.
Regular Expression Denial of Service (ReDoS) in lodash
All versions of package lodash prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber
, trim
and trimEnd
functions.
Steps to reproduce (provided by reporter Liyuan Chen):
var lo = require('lodash');
function build_blank(n) {
var ret = "1"
for (var i = 0; i < n; i++) {
ret += " "
}
return ret + "1";
}
var s = build_blank(50000) var time0 = Date.now();
lo.trim(s)
var time_cost0 = Date.now() - time0;
console.log("time_cost0: " + time_cost0);
var time1 = Date.now();
lo.toNumber(s) var time_cost1 = Date.now() - time1;
console.log("time_cost1: " + time_cost1);
var time2 = Date.now();
lo.trimEnd(s);
var time_cost2 = Date.now() - time2;
console.log("time_cost2: " + time_cost2);
Command Injection in lodash
lodash
versions prior to 4.17.21 are vulnerable to Command Injection via the template function.
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-regenerator
No 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