Esbuild version 0.16.8 represents a minor version bump over the previous stable release, 0.16.7, in this extremely fast JavaScript and CSS bundler and minifier. Examining the package data, the core functionality and intended use remain consistent, as indicated by the identical description, license (MIT), and repository details. Both versions also exhibit the same comprehensive support across a wide array of platforms, from Linux (various architectures) and Windows to macOS, Android, and FreeBSD, evidenced by the identical list of dependencies and optional dependencies. These dependencies are essentially pre-built binaries for different operating systems and architectures, allowing esbuild to execute natively and achieve its performance goals.
The key difference lies in the version numbers of the dependencies themselves. Version 0.16.8 utilizes version 0.16.8 of the architecture-specific packages like "@esbuild/linux-x64," while version 0.16.7 utilizes version 0.16.7 of the same packages. This suggests bug fixes, performance improvements, or potentially new features within these platform-specific binaries. The "dist" section also reveals minor differences, with fileCount of 7 and unpackedSize of 123183 identical between the two releases, but different release dates. Developers should upgrade to 0.16.8 primarily to benefit from these incremental improvements, as they very likely address stability or efficiency, but also ensure they are using the latest versions for their particular target environments, reducing the risk of encountering platform-specific bugs of running into security issues of the dependencies. While no major API changes are implied, consulting the official esbuild changelog or release notes is always recommended before upgrading to confirm compatibility and understand the specifics of the improvements included in version 0.16.8.
All the vulnerabilities related to the version 0.16.8 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.