On this page (7 sections)
Storybook has shipped patches for a weakness in the preview served by its development server. If a developer has an affected dev server running and visits a hostile web page, that page may be able to trigger unauthorized edits to files in the developer's project. In some setups those edits can later run as code with the developer's own privileges.
Teams that run storybook dev on laptops, shared build hosts or dev containers should read on. The maintainers say they know of no exploitation in the wild, but the patch also changes several network defaults, so it pays to plan the upgrade and test it rather than only bumping a version number.
What happened
According to the GitHub advisory, the Storybook team received a responsible disclosure on September 30th. The report demonstrated that a malicious site can embed the preview iframe of a dev server and push events to that server on the developer's machine. The advisory was published on October 12, 2026 and last updated on October 21, 2026.
The CVE record describes the root cause as insufficient restrictions on iframe embedding and on the origin of messages, which lets attacker-controlled events reach the running preview. It also states that the developer must visit the malicious site and interact with the injected interface, so this is not a flaw that fires with no user action at all.
How the weakness works
Web pages can embed other pages in iframes and exchange data with them through the browser's postMessage mechanism. A service that listens for those messages should decide which sites may frame it and which senders it trusts. Per the advisory, affected Storybook versions were too permissive here, so a page from an unrelated domain could frame the preview and send it events.
A second, related issue involved the highlight event that Storybook's accessibility addon uses to draw clickable highlights in the preview. The advisory says that event's API was open enough to trigger arbitrary events, including ones handled by the user's dev server, and that it has been reworked.
The impact comes in two stages. First, unauthorized changes to story files. Second, and only if a local runtime later executes a changed file, code execution under the developer's account. The second stage depends on your tooling, but developer machines commonly hold source code, access tokens and cloud credentials, which is why closing the first stage matters.
Who is affected
You are exposed if you run a Storybook dev server on a vulnerable version and open it in a web browser. The advisory lists these npm packages with vulnerable ranges: storybook, @storybook/core, @storybook/core-server and @storybook/experimental-addon-test (8.x), plus @storybook/addon-vitest (9.0.0 and later lines). It also lists @storybook/addon-mcp for versions from 10.6.0 up to 10.6.2 and for 11 alpha builds before 11.0.0-alpha.6.
The advisory says you are not impacted in these cases:
- You run a dev server that you never open in a web browser, for example headless automation or MCP clients
- You run or visit a built (static) version of Storybook
How to check your exposure
The following read-only command prints the installed versions of the main Storybook packages in a project. Run it from the project root and compare the output with the fixed versions above; a package that is not installed is simply reported as empty.
npm ls storybook @storybook/core @storybook/core-server @storybook/addon-vitest @storybook/addon-mcpIf you use another package manager, use its own listing command. Check lockfiles in every repository, CI image and shared dev container, not just your own machine, because a project can stay pinned to an older release.
What to do now
Upgrade to the patched release for your major version before you run storybook dev again. The advisory says that if you cannot upgrade right away, you should not run an affected dev server until you can.
0 of 7 done
Changes in default behavior
| Change | Effect | Opt-out flag |
|---|---|---|
| Iframe embedding over the network disabled | Manager or preview cannot be embedded on a site with a different host name; built Storybooks are unaffected | security.insecureRemoteIframeEmbed |
| Preview rejects messages from unknown hosts | In dev mode only its own origin and other localhost services are accepted; a composed Storybook on another origin fails to load unless it has been built | security.insecureIframeMessaging |
| Highlight event signature changed | The old permissive API is gone; Chromatic Visual Tests needs 5.5.1 or later | No flag provided |
Follow-up checks
No indicators of compromise have been published for this issue, and the maintainers report no known exploitation, so treat these as hygiene steps rather than a hunt for a known signature. Look through version control history for unexpected edits to story files, especially on machines where a dev server was running while you browsed other sites. If you find changes you cannot explain, consider the machine potentially exposed and rotate any credentials stored on it.
For the longer term, keep dev servers off shared networks, avoid browsing untrusted sites in the browser profile you use for local development, and include developer tooling in your regular dependency update checks. Our guide Is my WordPress plugin vulnerable? describes a similar habit for plugins, and Small business website security covers wider basics. For your public sites, the free security headers checker shows which framing protections your production pages send.
Sources and confidence
The technical details in this article come from one primary source, the GitHub advisory GHSA-f2ph-cmg5-wxc8. The CVE record covers the same issue and points to the same advisory, fix commits and release tags such as v8.6.19, v10.6.2 and v11.0.0-alpha.6, so it is not independent confirmation. Only one independent publisher covers the story so far. The severity also differs between the advisory page (Critical) and the CVE data (CVSS 8.6, high), so base your priority on how and where your dev servers actually run.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.