Esbuild 0.18.15 is a minor version update to the blazing-fast JavaScript and CSS bundler, following closely on the heels of version 0.18.14. The core functionality and purpose remain the same: to provide developers with an extremely efficient tool for bundling and minifying code. The primary change between these releases is the update of the internal dependencies.
Both versions bundle pre-built binaries for a wide range of platforms, including Linux, Windows, macOS, Android, and FreeBSD, covering various architectures like x64, ARM, ARM64, and others. This extensive platform support makes esbuild readily available across different development environments and deployment scenarios. Crucially, the dependencies, named with the "@esbuild/" prefix followed by the target platform and architecture, have been bumped from version 0.18.14 to 0.18.15.
For developers, this consistent updating of dependencies is important for maintaining compatibility, performance, and security. While the core API and usage are likely unchanged, upgrading to 0.18.15 ensures that you're using the latest optimized native builds for your target platform. The unpackedSize indicates a minor increase, which could point to minor changes for the included dependencies.
If you are currently on 0.18.14 and relying on esbuild's dependable performance, updating to 0.18.15 is a recommended, relatively risk-free operation. Since fileCount remains the same, we can presume this latest released focuses on internal tweaks and minor fixes. Developers should monitor the esbuild changelog or release notes for detailed information on the specific changes incorporated in the internal builds.
All the vulnerabilities related to the version 0.18.15 of the package
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 inpm run watchfetch('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.