Esbuild 0.17.6 represents a minor version update over its predecessor, 0.17.5, in the widely-used JavaScript and CSS bundler ecosystem. Both versions share the core functionality of providing exceptionally fast bundling and minification, making them valuable tools for optimizing web application performance. The primary difference lies in the version bump of their bundled platform-specific binaries. These binaries, such as @esbuild/linux-x64 and @esbuild/win32-arm64, are essential for esbuild to function correctly across diverse operating systems and architectures. Each undergoes a corresponding version increment from 0.17.5 to 0.17.6, signifying potential bug fixes, performance enhancements, or support for newer system environments within those specific builds. This update ensures that developers leveraging esbuild benefit from the latest refinements tailored to their target platform. The metadata reveals a minor increase in unpacked size, hinting at possible code additions or adjustments within the platform binaries.
For developers, upgrading from 0.17.5 to 0.17.6 is generally recommended. Doing so to ensure that you are using the latest esbuild and its enhancements to each of the platform variants. The fast build times of esbuild, stemming from its native code implementation, continue to be a significant draw for developers seeking to accelerate their build processes. The wide array of supported platforms, detailed in the dependency and optionalDependency lists, facilitates cross-platform compatibility, simplifying deployment workflows. Check the changelog for details on what enhancements each version offers. Both versions maintains the MIT license.
All the vulnerabilities related to the version 0.17.6 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.