All the vulnerabilities related to the version 4.3.33 of the package
fast-redact vulnerable to prototype pollution
fast-redact is a package that provides do very fast object redaction. A Prototype Pollution vulnerability in the nestedRestore function of fast-redact version 3.5.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence.
Babel has inefficient RegExp complexity in generated code with .replace when transpiling named capturing groups
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:
.replace
method on a regular expression that contains named capturing groups.replace
If you are using @babel/preset-env
with the targets
option, the transform that injects the vulnerable code is automatically enabled if:
You can verify what transforms @babel/preset-env
is using by enabling the debug
option.
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.
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).
This vulnerability was reported and fixed in https://github.com/babel/babel/pull/17173.
esbuild enables any website to send any requests to the development server and read the response
esbuild allows any websites to send any request to the development server and read the response due to default CORS settings.
esbuild sets Access-Control-Allow-Origin: *
header to all requests, including the SSE connection, which allows any websites to send any request to the development server and read the response.
https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L121 https://github.com/evanw/esbuild/blob/df815ac27b84f8b34374c9182a93c94718f8a630/pkg/api/serve_other.go#L363
Attack scenario:
http://malicious.example.com
).fetch('http://127.0.0.1:8000/main.js')
request by JS in that malicious web page. This request is normally blocked by same-origin policy, but that's not the case for the reasons above.http://127.0.0.1:8000/main.js
.In this scenario, I assumed that the attacker knows the URL of the bundle output file name. But the attacker can also get that information by
/index.html
: normally you have a script tag here/assets
: it's common to have a assets
directory when you have JS files and CSS files in a different directory and the directory listing feature tells the attacker the list of files/esbuild
SSE endpoint: the SSE endpoint sends the URL path of the changed files when the file is changed (new EventSource('/esbuild').addEventListener('change', e => console.log(e.type, e.data))
)The scenario above fetches the compiled content, but if the victim has the source map option enabled, the attacker can also get the non-compiled content by fetching the source map file.
npm i
npm run watch
fetch('http://127.0.0.1:8000/app.js').then(r => r.text()).then(content => console.log(content))
in a different website's dev tools.Users using the serve feature may get the source code stolen by malicious websites.