Esbuild is a blazing-fast JavaScript bundler and minifier, designed for speed and efficiency. Comparing versions 0.1.3 and 0.1.4, we see subtle changes that nonetheless highlight the project's ongoing development. Both share the same core attributes: MIT license, identical description, and a lightweight footprint with a fileCount of 3 and an unpackedSize of 2462. The repository remains consistent, pointing to the official GitHub repository.
The key difference lies in the releaseDate. Version 0.1.4 was released on April 15, 2020, while version 0.1.3 was released on April 13, 2020. This 2-day gap signifies that version 0.1.4 incorporates bug fixes, performance improvements, or minor feature additions implemented after the 0.1.3 release.
For developers, this means upgrading to version 0.1.4 is generally recommended. While the small version bump suggests incremental improvements rather than significant breaking changes, incorporating the latest version ensures leveraging the most up-to-date optimizations and stability enhancements. When integrating esbuild into your workflow, aiming for the recent stable release like 0.1.4 provides the best experience in terms of speed and reliability for bundling and minifying JavaScript code, making it a valuable tool for modern web development. Always consult the official esbuild changelog or release notes for detailed specifics about changes between any two versions.
All the vulnerabilities related to the version 0.1.4 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.