Esbuild, a blazing-fast JavaScript bundler and minifier, saw a small update with the release of version 0.1.17, quickly following its predecessor, version 0.1.16. Both versions continue to offer developers an efficient solution for bundling and minifying JavaScript code, licensed under the permissive MIT license. The core functionality remains consistent, focusing on speed and ease of use, making it an attractive alternative to slower bundlers.
The key difference between versions 0.1.17 and 0.1.16 lies in the internal implementation, reflected in the distribution details. Version 0.1.17 has a slightly larger unpacked size of 2567 bytes and contains 4 files, whereas version 0.1.16 has an unpacked size of 2463 bytes and contains only 3 files. This suggests the introduction of a new file or modifications to existing ones, likely to include bug fixes, performance enhancements, or minor feature additions. The release dates indicate a rapid iteration cycle, with version 0.1.17 arriving only a few days after version 0.1.16.
For developers, this incremental update signifies the project's active maintenance and commitment to stability. While the specific nature of the changes needs further investigation (perhaps looking at the commit logs in the GitHub repository to understand the specific adjustments), the bump in version number suggests it's worth upgrading from 0.1.16 to potentially benefit from these improvements, ensure you're using the best and most recent version. Esbuild remains a compelling choice for performance-conscious developers seeking a more efficient JavaScript bundling and minification workflow.
All the vulnerabilities related to the version 0.1.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.