Esbuild version 0.6.17 represents a minor update to the popular JavaScript bundler and minifier, building upon the solid foundation of version 0.6.16. Both versions continue to offer developers an extremely fast and efficient solution for bundling and minifying JavaScript code. This speed is a key selling point, enabling quicker build times and a more streamlined development workflow. Both versions share the same MIT license, offering flexibility for various project types, and are hosted on GitHub, encouraging community contributions and transparency.
The primary visible difference between these two releases lies in their unpacked size, with version 0.6.17 being slightly larger at 31022 bytes compared to 0.6.16's 29538 bytes. This increase suggests the addition of new features, performance improvements, or bug fixes that developers should explore. While the file count remains the same at 6, indicating no significant structural changes, the release dates highlight the recency of these versions. Version 0.6.17 was released just two days after 0.6.16, suggesting a possible hotfix or immediate follow-up to address specific issues. Developers relying on esbuild should investigate the changelog or release notes for 0.6.17 to understand the precise changes and assess any impact on their projects. These versions are perfect for developers seeking a fast and efficient way to bundle and minify JavaScript as they allow seamless integration and improved web performance.
All the vulnerabilities related to the version 0.6.17 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.