Esbuild version 0.14.43 represents a minor update over its predecessor, version 0.14.42, primarily focusing on internal improvements and bug fixes rather than introducing groundbreaking new features. For developers already leveraging esbuild, the upgrade to 0.14.43 should be seamless, entailing minimal disruption to existing workflows. The dependency versions for various platforms (Linux, macOS, Windows, Android, FreeBSD, etc.) are bumped to 0.14.43, signaling a synchronized update across all supported architectures.
A notable difference lies in the dist section: version 0.14.43 has a fileCount of 7 and an unpackedSize of 118909, compared to version 0.14.42's fileCount of 6 and unpackedSize of 117840. This suggests the inclusion of an additional file or modifications to existing files, contributing to a slightly larger unpacked size. While the precise nature of this increment isn't explicitly detailed, it's typical for minor releases to incorporate documentation updates, refined platform-specific builds, or patches addressing regressions. This increase also suggests that those new files or different files are added to this new version.
The update was released on 2022-06-08, approximately 10 days after version 0.14.42. For developers concerned with stability and staying current, upgrading to 0.14.43 is generally recommended. It incorporates the latest refinements and assures compatibility with the most recent toolchains and environments. It's advisable to consult the official esbuild changelog for a detailed breakdown of the changes implemented in 0.14.43.
All the vulnerabilities related to the version 0.14.43 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.