@storybook/react version 8.0.5 represents a minor version update over its predecessor, version 8.0.4, within the Storybook ecosystem, a popular tool for building UI components in isolation. While both versions share the same core dependencies like React, React DOM, and Typescript, as well as common utilities such as Lodash, Semver, and Acorn for JavaScript parsing, the subtle changes are worth noting for developers. A key differentiator lies in the updated internal dependencies, specifically within the Storybook suite itself. Components like @storybook/types, @storybook/docs-tools, @storybook/preview-api, @storybook/client-logger, and @storybook/react-dom-shim have all been bumped from version 8.0.4 to 8.0.5. This likely signifies bug fixes, performance enhancements, or new features within these internal modules that contribute to a more refined Storybook experience. The releaseDate field indicates a faster release cycle, with 8.0.5 being released shortly after 8.0.4. This suggests a focus on rapid iteration and potentially addressing immediate issues identified in the previous release. For developers, this upgrade signifies a commitment to stability and continuous improvement within the Storybook environment. While the core functionalities remain consistent, embracing version 8.0.5 ensures access to the latest refinements and bug fixes within Storybook's rendering and documentation tools, contributing to a smoother and more efficient component development workflow. Consider checking the official Storybook changelog for detailed specifics on the improvements included in this minor release.
All the vulnerabilities related to the version 8.0.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.