Babel-core versions 6.22.0 and 6.21.0 represent iterative improvements to the core Babel compiler. Examining the dependency updates reveals key changes beneficial for developers. In version 6.22.0, almost all Babel-related dependencies such as babel-code-frame, babel-generator, babel-helpers, babel-messages, babel-template, babel-runtime, babel-register, babel-traverse, and babel-types are bumped to ^6.22.0, ensuring consistent compatibility and likely incorporating bug fixes and new features across the Babel ecosystem. Conversely, version 6.21.0 shows a more fragmented dependency landscape with older versions of some of these packages. Babylon, a core parser, remains consistent across both versions at ^6.11.0.
Notably, the development dependencies also reflect this synchronized update pattern. Version 6.22.0 uses babel-helper-fixtures and babel-helper-transform-fixture-test-runner at ^6.22.0, while version 6.21.0 uses older versions. Developers upgrading to 6.22.0 benefit from enhanced stability, bug fixes, and potentially new functionalities integrated into each of the updated dependencies, leading to a more cohesive development experience. The synchronized dependency versions simplify dependency management and reduce the risk of version conflicts. From a development perspective, these updates mean developers can leverage the latest features and improvements within the Babel toolchain, ensuring their code transformations are utilizing the most up-to-date capabilities.
All the vulnerabilities related to the version 6.22.0 of the package
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.3Prototype 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...');
}