@storybook/addon-essentials version 8.1.1 represents a minor update over the previous stable release, 8.1.0, incorporating incremental improvements and bug fixes to enhance the Storybook development experience. The core functionality of providing curated addons that elevate Storybook remains consistent. Key dependencies like ts-dedent, @storybook/addon-docs, @storybook/core-common, and other essential addons such as actions, measure, outline, controls, toolbars, viewport, highlight, and backgrounds are all updated to version 8.1.1, ensuring compatibility and feature parity across the Storybook ecosystem. This synchronization is crucial for developers relying on the interplay of these addons for comprehensive component documentation, interaction testing, and visual debugging.
While the devDependencies and metadata like license, repository, and funding remain unchanged, the crucial distinction lies in the updated versions of its dependencies. This update signals a focus on stability and refinement, promising a smoother and potentially more robust experience for developers. The primary benefit of upgrading to 8.1.1 centers on leveraging the latest enhancements and fixes introduced within the individual addons themselves. Developers can anticipate resolved issues and optimized performance across the addon suite, leading to a more streamlined workflow for building, documenting, and testing UI components within Storybook. The relatively short interval between releases (May 14th to May 15th) indicates a quick response to address potential bugs or compatibility concerns discovered in the initial 8.1.0 release.
All the vulnerabilities related to the version 8.1.1 of the package
Cross site scripting in markdown-to-jsx
Versions of the package markdown-to-jsx before 7.4.0 are vulnerable to Cross-site Scripting (XSS) via the src property due to improper input sanitization. An attacker can execute arbitrary code by injecting a malicious iframe element in the markdown.
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.