Impact

Using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code.

Known affected plugins are: - @babel/plugin-transform-modules-systemjs - @babel/preset-env when using the modules: "systemjs" option, as it delegates to @babel/plugin-transform-modules-systemjs

No other plugins under the @babel namespace are impacted.

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/plugin-transform-modules-systemjs@7.29.4.

Babel also released @babel/preset-env@7.29.5, updating its @babel/plugin-transform-modules-systemjs dependency, to simplify forcing the update if you are using @babel/preset-env directly.

Workarounds

- Pin @babel/parser to v7.11.5. The downgrade will completely disable string module name parsing, but it would also disable other new language features and the build pipeline may fail as a result. Only do so if you are working on a legacy codebase and can not upgrade @babel/plugin-transform-modules-systemjs to v7.29.4. - Do not use the modules: "systemjs" option, migrate the codebase to native ES Modules or any other module formats.

Credits Babel thanks Daniel Cervera for reporting the vulnerability.

Impact

When using Babel to compile regular expression named capturing groups, Babel will generate a polyfill for the .replace method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to .replace).

Your generated code is vulnerable if all the following conditions are true: - You use Babel to compile regular expression named capturing groups - You use the .replace method on a regular expression that contains named capturing groups - Your code uses untrusted strings as the second argument of .replace

If you are using @babel/preset-env with the targets option, the transform that injects the vulnerable code is automatically enabled if: - you use duplicated named capturing groups, and target any browser older than Chrome/Edge 126, Opera 112, Firefox 129, Safari 17.4, or Node.js 23 - you use any named capturing groups, and target any browser older than Chrome 64, Opera 71, Edge 79, Firefox 78, Safari 11.1, or Node.js 10

You can verify what transforms @babel/preset-env is using by enabling the debug option.

Patches

This problem has been fixed in @babel/helpers and @babel/runtime 7.26.10 and 8.0.0-alpha.17, please upgrade. It's likely that you do not directly depend on @babel/helpers, and instead you depend on @babel/core (which itself depends on @babel/helpers). Upgrading to @babel/core 7.26.10 is not required, but it guarantees that you are on a new enough @babel/helpers version.

Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code.

Workarounds

If you are passing user-provided strings as the second argument of .replace on regular expressions that contain named capturing groups, validate the input and make sure it does not contain the substring $< if it's then not followed by > (possibly with other characters in between).

References

This vulnerability was reported and fixed in https://github.com/babel/babel/pull/17173.

Impact

Using @babel/core to compile maliciously crafted code can allow ab attacker to read any source map from the system that is running Babel, if these conditions are all true: - the attacker controls the input source code - the attacker can read the output source code - the attacker knows the path of the source map file that they want to read

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/core@7.29.6 and @babel/core@8.0.0-rc.6.

Workarounds

Callers can mitigate the issue without upgrading by setting inputSourceMap: false in their Babel options.

Callers can also manually extract the #sourceMappingURL comment from the input source code, validate whether the source map that it links to is allowed to be read, and if it is pass an object to inputSourceMap (passing false when it's not).

Credits

Thanks Teodor-Cristian Radoi for reporting the vulnerability.