Storybook's October 2026 Vulnerabilities Explained: Lock Down Your Dev Server

A tool that runs only on your laptop can still take orders from strangers. That is the plain lesson of the Storybook vulnerability published in October 2026. Storybook's dev server can write files in your project, and before the fix it did not check carefully enough who was asking.

Storybook is a popular open-source tool for building UI components one at a time. You run storybook dev, open a browser tab, and click through buttons, forms and cards in isolation. Each example lives in a story file, a small JavaScript or TypeScript file next to your component.

Picture a common setup. A frontend developer in Pune works on a team's design-system repo at a co-working space. Storybook runs on port 6006 all day, while the same browser holds docs, chat and a few random links. The setup is made up, but both weaknesses are real and published.

Two things could go wrong for that developer. A web page in another tab could quietly load the Storybook preview inside itself and send it commands. Or someone else on the co-working Wi-Fi could open the dev server by IP address and get the key to its live channel. Both paths end at the same place: writes to story files on the laptop.

Six terms carry the first half of the story. Each one is explained here once, and the rest of the guide uses the same names.

• Dev server: the program storybook dev starts. It serves web pages and listens for live updates while you code.
• Bind address: which network address a server listens on. 127.0.0.1 (also called localhost or loopback) means only this machine. 0.0.0.0 means every network card, so other devices can connect.
• LAN: local area network, the Wi-Fi or office network your laptop shares with nearby devices.
• Iframe: a page shown inside another page. Storybook's manager (the sidebar UI) shows each story in a preview iframe.
• postMessage: a browser feature that lets one window send a message to another, such as a page to its iframe. The receiver must check who sent it.
• WebSocket and token: a WebSocket is a connection that stays open so the browser and the dev server can push messages both ways. The token is a random secret in the page that your tab sends back to open it.

The Storybook vulnerability is really two advisories that share one fix. Both let an outsider talk to a running storybook dev server and get it to write files in your project. They differ in who the outsider is and how they get in. CVSS, in the table below, is the standard 0 to 10 severity score.

Affected versions are storybook 8.0.0 up to 8.6.18, 9.0.0 up to 9.1.20 and 10.0.0 up to 10.6.1. The same ranges cover @storybook/core, @storybook/core-server and @storybook/experimental-addon-test on 8.x. They also cover @storybook/addon-vitest from 9.0.0, and @storybook/addon-mcp from 10.6.0.

Your browser is the bridge. Any page you open can ask the browser to load http://localhost:6006 inside an iframe, because a page may embed other sites unless they refuse. The request comes from your own machine, so the dev server sees a normal local visitor.

The naive belief: localhost is private

Many developers think a server on localhost is safe because the internet cannot reach it. That belief is wrong for browsers. Every tab runs on your machine, so every site you visit sits on the right side of that wall.

Storybook 10.6.1 already had one defence. It checks the Host header, the name the browser says it is visiting. That blocks DNS rebinding, a trick where an attacker's domain is re-pointed at 127.0.0.1 so the browser treats your server as the attacker's site.

The answer is framing. When a page embeds http://localhost:6006/iframe.html, the browser sends Host: localhost, which passes the check. The attacking page then calls postMessage on that iframe. In 10.6.1, the preview did not check the origin of those messages in dev mode. The origin is the scheme, host and port of the page that sent them.

The advisory's timeline says a reporter showed on 30 September that a malicious site could embed a dev server's preview iframe and send it events. The advisory does not publish every later step. One part of the fix points at the last step: the server now ignores save requests unless they come from the manager's own connection.

The advisory also says recent Chrome and Firefox versions may ask before a website connects to a localhost service. In its words, that reduces the risk but does not remove it. Do not rely on a browser prompt as your only lock.

The token was never hidden from people who could load the page. Storybook writes it into the manager page and the preview page so your tab can open the WebSocket. Unfixed versions also listened on every network interface by default in our 10.6.1 test. So anyone on the co-working Wi-Fi from our setup could load that page by IP address.

We tested this on our own machine. Storybook 10.6.1, started with plain storybook dev and no --host flag, listened on 0.0.0.0:6006. Its startup banner even printed an On your network address. Version 10.6.2 listened on 127.0.0.1:6006 only.

Why 0.0.0.0? Storybook 10.6.1 passed no host to Node's listen call. Node's documentation says that with no host, a server accepts connections on :: when IPv6 is available, or 0.0.0.0 otherwise. Both mean every interface.

With the token, a device on the LAN can open the same WebSocket your browser uses. The advisory says that channel could inject code into story files or create new files. If the Vitest addon is installed, a payload could also use a Vitest API to write other files. The advisory says the risk is higher with an older Vitest version.

Only when extra conditions line up. Both advisories describe file writes as the direct result. Code execution needs a second step: something on your machine later runs a changed or new file with your user's rights.

For the website path, the advisory says it needs user interaction and a later local runtime run. For the LAN path, it says code can run under the right circumstances, depending on the payload, where the file lands and what software you use. Neither advisory claims a one-click takeover.

Two groups are clearly outside the blast radius. A built, static Storybook, the output of storybook build, has no write channel and no token. A dev server never opened in a browser, such as one driven by headless automation, is outside the website path.

Beginners can stop here, after one step. Upgrade Storybook to 8.6.19, 9.1.21 or 10.6.2, then run npx storybook --version to confirm. The rest of this guide is for engineers: what the fix changed, how to test your setup and what still needs care.

The fix closes both doors and narrows what the channel will accept. One new term first: frame-ancestors is a rule, sent in a Content-Security-Policy response header, that tells browsers which sites may embed a page. We installed storybook 10.6.1 and 10.6.2 from npm and compared their behaviour and source. We read the 8.6.19 and 9.1.21 packages to confirm the same default.

The four main changes

• Default bind address: 127.0.0.1. To share on a LAN, pass --host with your LAN IP. The advisory also asks you to list that IP in core.allowedHosts and allow only known IPs in a firewall.
• Framing: a Content-Security-Policy header with frame-ancestors 'self' plus localhost names tells browsers to refuse embedding by other sites. The flag security.insecureRemoteIframeEmbed turns it off.
• Messages: in dev mode the preview drops postMessage events from unknown origins. The flag security.insecureIframeMessaging turns the check off; built Storybooks still accept any origin.
• Vitest addon: when browser mode is on, the addon sets allowWrite and allowExec to false unless your Vitest config sets them.

Smaller changes back these up. The server now tags each WebSocket client as manager, preview or server, and ignores core events from the wrong one. Save requests may write only serialized args and story titles, so a request can no longer smuggle in a play function.

Two breaking changes are the most likely to touch your setup. The highlight event changed its signature with no flag to restore it, and the advisory says Chromatic's Visual Tests addon needs 5.5.1 or later. Composition that embeds a dev server from another host may need the flags above; the advisory suggests composing built Storybooks instead.

Five quick checks give clear output. Run them inside the project that has Storybook installed.

1. 1

   Check the installed version

   Run npx storybook --version. Our 10.6.1 project printed 10.6.1. Any version from 8.6.19, 9.1.21 or 10.6.2 upward on the same major line is fixed.

2. 2

   Find every copy in the tree

   Run npm ls storybook. Addons pull storybook in too, so every line should show the same fixed version. Repeat for @storybook/addon-vitest if you use it.

3. 3

   Start Storybook and look at the banner

   On a fixed version, the Local line shows http://127.0.0.1:6006/. The network line tells you to run with --host and your IP instead of printing an address.

4. 4

   Read the bind address

   While it runs, use lsof, a tool that lists open files and network sockets, as below. 127.0.0.1:6006 means only your machine can connect. An asterisk before :6006 means every interface is listening. On Windows, or without lsof, the banner from step 3 is the simplest check.

5. 5

   Confirm the framing header

   Run the curl command below. A fixed version prints a Content-Security-Policy line with frame-ancestors. An old version prints nothing.

npx storybook --version
npm ls storybook

# while storybook dev runs on port 6006 (macOS and Linux)
lsof -nP -iTCP:6006 -sTCP:LISTEN

curl -sI http://127.0.0.1:6006/ | grep -i content-security-policy

What just happened? The lsof line shows who can connect, and the curl line shows whether other sites may embed the page. Here is what we saw on Linux, 25 October 2026; we did not test macOS. On 10.6.1, the last columns of the lsof line read TCP *:6006 (LISTEN), and curl printed nothing. On 10.6.2, they read TCP 127.0.0.1:6006 (LISTEN), and curl printed the frame-ancestors line.

# 10.6.2 output (lsof line trimmed to its first and last columns)
node    TCP 127.0.0.1:6006 (LISTEN)
Content-Security-Policy: frame-ancestors 'self' http://localhost:* http://*.localhost:* http://127.0.0.1:*

Upgrade first, then look for the settings that reopen the doors. The advisories ask you to upgrade before you run storybook dev again, and not to run an affected dev server until you can.

1. 1

   Upgrade every Storybook package together

   Move to 8.6.19, 9.1.21 or 10.6.2, or later on your line. Keep framework packages and addons such as addon-vitest on the same version, then commit the lockfile.

2. 2

   Search scripts for --host

   Look in package.json, Docker files and docs for --host 0.0.0.0 or -h 0.0.0.0. Remove it unless you truly need LAN access.

3. 3

   Share on a LAN the narrow way

   If a teammate must open your Storybook, pass --host with your LAN IP, list it in core.allowedHosts and allow only known IPs in your firewall. Never do this on public Wi-Fi.

4. 4

   Leave the new flags off

   Do not set security.insecureRemoteIframeEmbed, security.insecureIframeMessaging or core.allowedHosts true unless you can name the exact reason. For composition, the advisory suggests building composed Storybooks instead.

5. 5

   Re-enable Vitest write and exec only on purpose

   If your browser-mode tests really write files or run commands, set allowWrite or allowExec yourself in the Vitest config, and know that you have widened the channel.

6. 6

   Look back at story files

   If you ran an old version on shared Wi-Fi, review recent git changes in story files and new files you did not create. This is a precaution, not a sign that you were attacked.

Your attack surface is every place an attacker could reach your systems. A local dev server belongs on that list: it is a web server with write access to your source code, and your browser visits untrusted pages all day. Any tool with both traits has this exposure in principle. These advisories show five defences in one place.

• Bind narrowly: listen on 127.0.0.1 by default and make LAN exposure a deliberate flag, ideally with a named IP.
• Check Host on every HTTP request: this stops DNS rebinding. Storybook 10.6.1 had it and was still exposed, which shows one check is not enough.
• Refuse framing: frame-ancestors stops other sites embedding your pages, so they cannot drive them with postMessage.
• Check the origin of every message: a postMessage listener that skips this check obeys any window that can reach it.
• Treat page-embedded tokens as weak: a secret printed into HTML protects only as far as the page is unreachable.

The deeper lesson is layered failure. Each gap alone was small: a wide bind address, a missing frame rule, an unchecked message, loose save validation. Together they formed a path from a web page or a Wi-Fi neighbour to your project folder.

Use it as a case study in trust boundaries for developer tools. Interviewers want to hear who can reach the server, what it can do, and which layer should have stopped each step.

1. 1

   Name the asset

   The dev server can write files in the project and trigger test runs. That makes it worth attacking even though it is only on a laptop.

2. 2

   List who can reach it

   The local browser and every tab in it, plus the whole LAN when it binds to 0.0.0.0. Each is a different attacker with different abilities.

3. 3

   Walk one path end to end

   A web page frames the preview and sends postMessage events. Those events reach the dev server, which writes a story file.

4. 4

   Put a control on each hop

   Loopback bind for the LAN, frame-ancestors for embedding, origin checks for messages, sender roles for WebSocket events, strict validation for file writes.

5. 5

   Scope the impact honestly

   File writes are direct; code runs only if a local runtime later executes the file. Built static output is not affected.