CVE-2026-27148

What it actually does

Storybook dev server versions before 7.6.23, 8.6.17, 9.1.19, and 10.2.10 fail to validate the Origin of WebSocket connections used for story creation and update workflows. A malicious web page can connect from a developer’s browser to a locally running Storybook instance, or an unauthenticated remote attacker can connect directly if the dev server is exposed. Vulnerable WebSocket handlers accept unsanitized input in the componentFilePath field, enabling injection into story creation/save operations. Depending on how the injected data is processed and written, impact can include persistent cross-site scripting in Storybook content and remote code execution in the development environment. Production Storybook static builds are not affected; the risk is specific to the interactive dev server.

Why it matters to the business

Compromise of a developer workstation or publicly exposed Storybook dev server can lead to stolen source code, tampered UI components, malicious changes entering development workflows, and potential execution of attacker-controlled commands in a build or developer context. The issue has a high severity score but currently has low EPSS probability, no known CISA KEV listing, and no reported exploit maturity in the provided data; however, organizations should still prioritize remediation because exploitation is simple when a developer is running Storybook or when Storybook is exposed for demos or reviews.

How an attack unfolds

In the local-developer scenario, an attacker first lures a developer to a malicious website while the developer has a vulnerable Storybook dev server running, commonly on a local development port. The malicious site opens a WebSocket connection from the browser to the Storybook dev server. Because the dev server does not enforce a trusted Origin check, the connection is accepted even though it originates from an unrelated website. The attacker then sends Storybook WebSocket messages that target the story creation or save functionality and supplies crafted data in the componentFilePath field. Because that field is not safely sanitized before being used, the attacker can inject content that persists into Storybook-managed files or triggers unsafe behavior, resulting in persistent XSS or code execution in the development context. If the Storybook dev server is reachable over the network or internet, the attacker does not need to lure a developer; they can connect directly to the WebSocket interface and send the malicious messages unauthenticated.

How to fix it

Upgrade Storybook to a fixed release: 7.6.23 or later for the 7.x line, 8.6.17 or later for the 8.x line, 9.1.19 or later for the 9.x line, and 10.2.10 or later for the 10.x line. For source consumers, ensure the fix commit 736b0f1aac0c3c1d039ebfff07bc0eb88551b546 or an equivalent later revision is present. Regenerate lockfiles and rebuild development containers or workstation images that include Storybook. Do not expose the Storybook dev server to the internet or broad internal networks; bind it to localhost where possible. If remote access is required for design reviews, place it behind authentication, TLS, and a reverse proxy that restricts allowed origins and clients. As a temporary mitigation where upgrade is delayed, disable public access to Storybook dev servers, block inbound access to common Storybook ports such as 6006, and instruct developers not to browse untrusted sites while vulnerable Storybook instances are running.

How to confirm the fix worked

Confirm dependency versions with package-manager tooling such as npm ls storybook, npm ls @storybook/*, yarn why storybook, pnpm why storybook, and by reviewing package-lock.json, yarn.lock, or pnpm-lock.yaml for versions older than the fixed releases. Verify running dev servers report a fixed Storybook version. Confirm that development services are bound to localhost rather than 0.0.0.0 unless explicitly protected. Scan externally and internally for exposed Storybook interfaces, especially common port 6006. As a security validation, attempt a WebSocket connection to the dev server using an untrusted Origin and confirm the server rejects it. Review project files for unexpected story files or recent modifications after upgrading, because patching prevents future exploitation but does not remove malicious changes already written.

Typical attack path

1. Identify a vulnerable Storybook dev server version prior to 7.6.23, 8.6.17, 9.1.19, or 10.2.10, or infer that a developer commonly runs one locally.
2. For local exploitation, host or deliver a malicious web page and convince a developer with Storybook running to visit it.
3. From the malicious page, initiate a WebSocket connection to the local Storybook dev server; for exposed servers, connect directly over the network.
4. Rely on the missing WebSocket Origin validation to establish the connection without authentication or user approval.
5. Send crafted story creation or story save messages containing malicious input in componentFilePath.
6. Cause Storybook to write or process injected content, producing persistent XSS in Storybook content or remote code execution in the dev server context.
7. Use the resulting access to tamper with project files, execute commands, steal development secrets, or pivot into source-code and build workflows.

How to detect it

Investigate both network-level and host-level evidence. For exposed Storybook servers, review reverse proxy, web server, firewall, and packet-capture logs for WebSocket upgrade requests to Storybook from unfamiliar IP addresses, especially requests with unexpected Origin headers. For local hijacking, evidence may be limited because the browser connects to localhost; review browser history, endpoint telemetry, DNS logs, and EDR network events for developers visiting suspicious sites while Storybook was running. Review Storybook dev server console output, terminal scrollback, shell history, and process logs for story creation/save activity. Inspect source trees for newly created or unexpectedly modified story files, unusual import paths, injected script content, traversal sequences, shell metacharacters, or anomalous componentFilePath values. Use EDR to identify child processes spawned by node or Storybook processes, especially shells, package managers, curl/wget, PowerShell, or other command interpreters. If Storybook was published through a proxy, correlate WebSocket upgrade timestamps with file modification times in repositories and developer workspaces. Also review git status, local commits, and uncommitted changes for malicious additions before accepting or merging UI component updates.

• componentFilePath
• /storybook-server-channel
• Upgrade: websocket
• Sec-WebSocket-Key:
• Origin: null
• Origin: file://
• localhost:6006
• 127.0.0.1:6006
• 0.0.0.0:6006
• <script
• javascript:
• onerror=
• onload=
• ../
• ..\\
• $(
• `
• ;curl
• ;wget
• powershell
• cmd.exe
• /bin/sh
• /bin/bash
• .stories.js
• .stories.jsx
• .stories.ts
• .stories.tsx
• node_modules/.bin/storybook
• storybook dev

What your security team should do

• Inventory Storybook usage across repositories, developer images, CI images, and demo environments, prioritizing any instance reachable beyond localhost.
• Upgrade all affected Storybook versions to 7.6.23, 8.6.17, 9.1.19, 10.2.10, or later, and ensure lockfiles are updated.
• Block public and broad internal access to Storybook dev servers; restrict to localhost or authenticated, allowlisted access only.
• Search source repositories and workstations for unexpected story-file changes, suspicious componentFilePath usage, embedded scripts, and recent modifications around the time vulnerable dev servers were used.
• Review reverse proxy, endpoint, and dev-server logs for WebSocket upgrades to Storybook from unusual origins or remote clients.
• Add secure development guidance warning teams not to expose frontend dev servers without authentication and not to run vulnerable local dev tooling while browsing untrusted sites.
• Because the issue is not currently KEV-listed and EPSS is low, align urgency with exposure: treat public Storybook dev servers as emergency fixes and local-only developer usage as high-priority patching.