Rollup plugin esbuild minify, a tool designed to streamline Rollup bundles with esbuild's minification capabilities, saw a notable update from version 1.1.0 to 1.1.1. The core functionality remains consistent – offering developers a simple way to reduce bundle sizes and clean up code. The key difference lies in the updated dependencies, specifically the move to esbuild version ^0.19.4 in the newer release, compared to ^0.17.18 in the previous. This update likely brings performance improvements, bug fixes, and potentially new minification features inherent to the newer esbuild version, which users can leverage for optimized builds.
Furthermore, the rollup peer dependency has been updated to allow rollup ^4, providing compatibility with the latest major version of the bundler. This is crucial for developers using recent versions of Rollup, ensuring seamless integration without compatibility issues. While the developer dependencies like c8, rollup, tehanu, denolint, @semantic-release/git, and @semantic-release/changelog also experienced minor version bumps, these are primarily relevant for development of the plugin itself and less so for end-users incorporating it into their workflows. The unpacked size of the package has slightly increased from 12432 to 12612, potentially due to the updated esbuild dependency. Developers should upgrade to version 1.1.1 to benefit from the latest esbuild enhancements and Rollup compatibility.
All the vulnerabilities related to the version 1.1.1 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.