Esbuild versions 0.11.22 and 0.11.23 present developers with incrementally updated iterations of an exceptionally fast JavaScript bundler and minifier. Both versions share identical descriptions, licensing under the MIT license, and the same repository location on GitHub, indicating continuity in the project's core mission and maintainership by Evan Wallace. The distribution details for both releases also show a likeness in structure, possessing an equal fileCount of 6 and an unpackedSize of 87986 bytes. The most obvious difference, and the key differentiator for developers tracking updates, lies in their release dates. Version 0.11.23 was published on May 16, 2021, at 11:06:24.110Z, marking a marginal advancement from version 0.11.22, which was released on May 15, 2021, at 08:53:14.915Z.
While the data provided doesn't detail specific code-level changes, this update suggests a probable bug fix or minor enhancement incorporated in the newer version. Developers contemplating which version to implement should ideally opt for the most recent release (0.11.23) to benefit from potential rectifications and improvement, even if they are seemingly small. For those keen on leveraging the performance benefits of esbuild a best practice when dealing with package updates is to carefully review the changelog or release notes on the project's GitHub repository to understand the exact nature of changes between these versions and access a fuller understanding of what may have been implemented.
All the vulnerabilities related to the version 0.11.23 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.