@storybook/react version 7.0.23 is a patch update, released on June 22, 2023, following version 7.0.22 which was released just a few days before, on June 17, 2023. Both versions target developers using React with Storybook, offering tools for building UI components in isolation. The core functionalities remain consistent, focusing on providing a robust environment for component development, testing, and documentation. Key dependencies like react, react-dom, acorn, lodash, and prop-types remain within the same acceptable version ranges, ensuring compatibility with a wide array of React projects spanning versions 16, 17, and 18.
The primary distinction lies in the internal dependencies versions. @storybook/types, @storybook/docs-tools, @storybook/core-client, @storybook/preview-api, @storybook/client-logger, and @storybook/react-dom-shim were all updated from version 7.0.22 to 7.0.23. While the specific nature of these internal changes isn't detailed, patch releases typically address bug fixes, performance improvements, or minor adjustments that enhance the overall stability and reliability of the Storybook environment.
Developers upgrading from 7.0.22 to 7.0.23 can expect a smoother, potentially more refined experience without major API changes disrupting their workflow. Staying current with patch updates ensures access to the latest enhancements and bug fixes, contributing to a more consistent and productive development process. It's recommended to review the Storybook changelog for detailed information on the specific refinements included in this release.
All the vulnerabilities related to the version 7.0.23 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.