Esbuild version 0.8.1 arrived just days after its predecessor, 0.8.0, presenting developers with an incrementally updated iteration of this remarkably fast JavaScript bundler and minifier. Both versions maintain the core value proposition: delivering unparalleled build speeds for JavaScript projects. Licensed under the MIT license, the package encourages open-source adoption and community contributions. The Git repository remains consistent across both versions, hosted at the established GitHub location, ensuring developers can easily access the source code and contribute to its ongoing development.
A key difference lies in the unpacked size, with version 0.8.1 increasing to 49854 bytes from 0.8.0's 40347 bytes, indicating adjustments or potential additions to the codebase. This could encompass bug fixes, performance enhancements, or even minor feature tweaks implemented in the newer version. While the fileCount remains steady at 6, the increased unpacked size suggests a deeper dive into what the new version brings. More details would be needed to specify the enhancements, but one can assume that 0.8.1 is the most optimal version available. If you're aiming for the most recent stable and potentially refined build of esbuild, version 0.8.1, released on November 1st, 2020, is the recommended choice. However, 0.8.0 could be more than capable of running with minimal size impact. Both versions are distributed as gzipped tarballs directly from the npm registry, making them easily installable via standard package management tools to boost JavaScript development workflows.
All the vulnerabilities related to the version 0.8.1 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.