Esbuild version 0.14.10 is a minor release following 0.14.9 in the popular JavaScript and CSS bundler ecosystem. Both versions maintain the core functionality of providing extremely fast bundling and minification capabilities. The primary distinction lies in the dependency versions of platform-specific binary packages. Version 0.14.10 updates all esbuild-* dependencies (e.g., esbuild-linux-64, esbuild-windows-64, esbuild-darwin-arm64) to version 0.14.10, while version 0.14.9 uses version 0.14.9 for the same dependencies.
For developers, this means upgrading to 0.14.10 ensures they are using the latest builds for their target operating systems and architectures. While the core API and functionality remain consistent, these updated dependencies likely incorporate bug fixes, performance improvements, or compatibility enhancements specific to each platform. Furthermore, while the fileCount remains at 6 in both versions, the unpackedSize metric has slightly increased from 108396 in v0.14.9 to 108715 bytes in v0.14.10, suggesting the updates probably bring some new or altered functionalities of the core dependencies. This release pattern is typical for esbuild, focusing on frequent, incremental improvements and platform support. Developers should upgrade to 0.14.10 primarily to ensure they're benefiting from these under-the-hood advancements, which could resolve platform specific bugs or improve performance. Finally, the newer version was released on December 31st 2021, while the previous one on December 29th 2021.
All the vulnerabilities related to the version 0.14.10 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.