Esbuild is a blazing-fast JavaScript bundler and minifier, designed to dramatically improve build times for web developers. Version 0.7.4 follows closely on the heels of version 0.7.3, both sharing the same core purpose of streamlining the development workflow. Both versions are MIT licensed, available on GitHub, and packaged with a compact file structure.
While both provide the same functionality and features, a subtle difference lies in the unpacked size of the distributed package. Version 0.7.3 unpacks to 38316 bytes, while version 0.7.4 is slightly smaller at 38150 bytes. Also, it is important to consider the release date. Version 0.7.3 was released at 2020-09-23T00:13:36.259Z, while version 0.7.4 was released later the same day at 2020-09-23T18:23:07.197Z. This reduction, though minimal, could hint at under-the-hood optimizations or minor bug fixes. For developers, this means a slightly leaner footprint for your project. Given the very proximate release dates, the changes are likely incremental.
Both versions are downloadable as gzipped tarballs, ready for integration into your projects via npm. For developers seeking peak performance in their JavaScript build processes, Esbuild remains a compelling choice. Weighing only a few kilobytes, it promises to speed up the bundling and minification process compared to traditional tools. It's advantageous to check the changelog in the repository, in this case at Github, a tool which provides a more detailed overview of the changes between versions.
All the vulnerabilities related to the version 0.7.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.