The @storybook/react package has been updated from version 8.0.3 to 8.0.4, offering incremental improvements for React Storybook users. While the core functionality remains consistent, reflected in the shared description as "Storybook React renderer," developers should note subtle changes in the underlying dependencies. The most significant difference lies in the versions of Storybook's internal packages. Several packages were bumped to version 8.0.4, including @storybook/types, @storybook/docs-tools, @storybook/preview-api, @storybook/client-logger, and @storybook/test. These updates likely encompass bug fixes, performance enhancements, and potentially new features within the Storybook ecosystem itself, though detailed changelogs for each sub-package should be consulted for specifics. Furthermore, the unpacked size of version 8.0.4 is slightly bigger than that of 8.0.3(104597 vs 104487), indicating minor additions or adjustments to the codebase. The release dates highlight the rapid iteration, with version 8.0.4 released shortly after 8.0.3. For developers already using Storybook 8.0.3, upgrading to 8.0.4 is generally recommended to leverage the latest refinements and maintain compatibility across the Storybook suite. As always before doing new deployments please, ensure thorough testing after upgrading to identify and address any potential integration issues within your specific project configuration, especially related to type definitions.
All the vulnerabilities related to the version 8.0.4 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.