Esbuild version 0.14.30 is a minor release following version 0.14.29 in the popular JavaScript and CSS bundler and minifier. Both versions maintain the core functionality of providing extremely fast build times for web development workflows. The primary difference between the two versions lies in the updated dependencies. Specifically, all platform-specific binary packages like esbuild-linux-64, esbuild-darwin-arm64, and esbuild-windows-64 have been bumped from version 0.14.29 to 0.14.30. These platform-specific packages are crucial as they contain the native executable for esbuild tailored to each operating system and architecture. Essentially, this update incorporates the latest bug fixes, performance improvements, and potentially new platform support baked into the core esbuild engine for each respective operating system. For developers considering an upgrade, this means a seamless transition with the potential for enhanced stability and performance across different deployment environments. The fileCount and unpackedSize in the dist object remain the same, suggesting the update primarily focuses on the underlying compiled binaries without significant changes to the JavaScript interface or overall package structure. The release date also indicates the recentness of the update, suggesting active maintenance and continuous improvement of the esbuild project. Developers should upgrade to version 0.14.30 to ensure they are benefiting from the most up-to-date and optimized version of esbuild for their target platform.
All the vulnerabilities related to the version 0.14.30 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.