Esbuild, a blazing-fast JavaScript and CSS bundler, has a new version, 0.17.19, released on May 13, 2023. Comparing it to its predecessor, version 0.17.18 released on April 22, 2023, the core functionality and purpose remain consistent: providing an exceptionally quick bundling and minification solution. While the descriptions are identical, diving into the technical details reveals subtle but crucial differences.
Both versions share the same dependencies and optional dependencies, which consist primarily of pre-built binaries for various operating systems and architectures, ensuring esbuild's cross-platform compatibility. Supporting architectures like Linux (arm, x64, arm64, riscv64), Windows (x64, ia32, arm64), macOS (x64, arm64), Android, FreeBSD, and even more niche systems like SunOS and NetBSD, demonstrates the project's commitment to broad accessibility. The versions of these dependencies are also bumped up, such as "@esbuild/linux-x64" moving from "0.17.18" to "0.17.19" reflecting that the binaries ship with the parent package. Furthermore, both distributions have a fileCount of 7 and an unpackedSize of 130127. The most significant differentiator is the release date, reflecting bug fixes, performance improvements, or minor feature enhancements that, while not explicitly detailed on the manifest, collectively warrant a new version rollout. For developers, upgrading is typically recommended, as newer versions tend to offer a more polished and robust experience due to continuous development efforts and community contributions. Whether the update fixed a specific bug or introduced a crucial optimization, staying current helps ensure stability and potentially unlocking even faster build times.
All the vulnerabilities related to the version 0.17.19 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.