Tsup, a zero-config TypeScript bundler powered by esbuild, has released version 8.3.5, a minor update over the previous stable version, 8.3.4. While the core functionality remains consistent, several subtle changes may be of interest to developers. The dependency list is identical between the two versions, including crucial tools like esbuild, Sucrase, and Rollup. This implies that the primary bundling and transformation processes are unchanged, meaning developers can expect consistent output and compilation speed.
However, the "dist" object within the package metadata reveals a slight difference. Version 8.3.5 has a slightly smaller unpacked size of 440113 bytes compared to 8.3.4's 440144 bytes. This minor reduction, while seemingly insignificant, hints at potential optimizations in the bundled code or a slight restructuring of the package contents.
The release dates also suggest a very rapid release cycle. Version 8.3.4 was released on October 25, 2024, and version 8.3.5 was released just a day after, on October 26, 2024. Such a quick turnaround often indicates a hotfix or a minor adjustment to address an immediate issue or improve stability shortly after the preceding release. Developers experiencing problems with 8.3.4 might find 8.3.5 a worthwhile upgrade for potential bug fixes or performance improvements. Given the very small changes, it's likely a low-risk upgrade for most users already on the 8.3.x series.
All the vulnerabilities related to the version 8.3.5 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.