Esbuild versions 0.7.5 and 0.7.6 represent incremental updates to this blazing-fast JavaScript bundler and minifier, a tool designed to significantly improve build times compared to traditional bundlers like Webpack. Both versions maintain consistent core features, offering developers a streamlined and efficient solution for preparing code for production. The license continues to be MIT, ensuring open-source flexibility, and the repository remains accessible on GitHub, fostering community contributions and transparency.
Examining the dist section, both versions 0.7.5 and 0.7.6 share identical characteristics: a file count of 6 and an unpacked size of 38150 bytes. This suggests the core architecture and overall size of the package remained unchanged between these two releases. The most notable distinction lies in the releaseDate. Version 0.7.6 was published on September 26, 2020, while version 0.7.5 was released on September 24, 2020. This indicates that version 0.7.6 contained fixes and/or very minor improvements introduced within that short timeframe.
For developers using esbuild, this generally means updating from 0.7.5 to 0.7.6 involves minimal risk of breaking changes. The update likely focuses on bug fixes or small enhancements. While specific changes aren't detailed in the provided metadata, developers should consult the official esbuild changelog or release notes to understand precisely what was addressed. Choosing the newer version is usually recommended, as it incorporates the latest refinements, contributing to a more stable and reliable bundling process. Esbuild's speed and ease of use make it an attractive choice for projects aiming to reduce build times without complex configuration.
All the vulnerabilities related to the version 0.7.6 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.