Esbuild version 0.14.2 represents a minor update to the extremely fast JavaScript and CSS bundler and minifier, building upon the foundation laid by version 0.14.1. Both versions share a common purpose: to provide developers with a high-performance tool for preparing their web assets for production. A key characteristic of esbuild is its speed; it fundamentally differs from other tools by using a totally different approach that leverages native code, not Javascript, which results in significant speed improvements.
The core dependencies and optional dependencies remain consistent between the two versions: both rely on platform-specific binaries (e.g., esbuild-linux-64, esbuild-windows-64) to ensure compatibility across various operating systems and architectures. These pre-built binaries are downloaded during installation based on which operating system and architecture is being used, this avoid cross-compilation and allows the installation to be fast and easy. The optional dependencies let developers install esbuild in every OS and architecture although the building process will only succeed in the targeted platform, for example, if a developer install esbuild using Windows, only the windows dependencies will be used and it does not matter which other dependencies are present.
The primary distinction lies in the internal changes and bug fixes incorporated within this minor release. While the API and core functionality likely remain the same, developers can expect that version 0.14.2 addresses any issues or edge cases identified in the prior version. This incremental update should offer improved stability and reliability for those already using version 0.14.1, and new adopters can benefit from the latest refinements to the tool. The slight increase in unpacked size, from 104346 to 104384 bytes may indicate that the update adds some bytes, maybe bug fixes or additional exports. Esbuild is licensed under the MIT license and hosted on GitHub, inviting community contributions and ensuring open access for all developers.
All the vulnerabilities related to the version 0.14.2 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.