UIコンポーネントの開発環境Storybookで、開発サーバー（storybook dev）を起動中に悪意あるWebサイトを開くと、プロジェクトのファイルを書き換えられるおそれがある脆弱性CVE-2026-114125が公表されました。GitHub Advisory Databaseは2026年10月21日に深刻度Critical（CVSS v4.0で9.4）として掲載しています。翌22日には、同じLANにいる端末から開発サーバーへコードを差し込めるCVE-2026-114126（High・8.7）も掲載されました。どちらも修正版は8.6.19・9.1.21・10.6.2です。本記事では、対象になる版と条件、自社のプロジェクトが当てはまるかを確かめるコマンド、更新で既定の動作が変わる箇所への対処を実装者の目線で整理します。記載内容は2026年10月28日時点の公開情報にもとづきます。
まとめ：storybook devを止めて修正版へ上げ、待ち受けは127.0.0.1に絞る
修正版は8系が8.6.19、9系が9.1.21、10系が10.6.2、11系のプレリリースが11.0.0-alpha.6です。Storybookチームは、更新するまで影響のある版の開発サーバーを起動しないよう求めています。2026年10月28日時点のnpmの最新は10.6.4でした。
影響を受けるのは開発サーバーだけです。storybook buildで作った静的ファイルを公開している場合、この2件の対象ではありません。ただし2025年12月のCVE-2025-68429はビルド成果物に.envの値が混ざる問題なので、公開中のStorybookがある場合はそちらの修正版も確かめてください。
修正版では、開発サーバーの待ち受けが既定で127.0.0.1だけになり、別ホストからのiframe埋め込みも止まります。Dockerの中で動かしている、社内LANで開発サーバーを見せ合っている、といった運用はそのままでは動かなくなります。設定で元に戻す前に、共有は静的ビルドへ寄せるのが安全です。悪用は2026年10月28日時点でアドバイザリに確認されていません。
2026年10月に公表されたStorybook脆弱性2件と開発サーバー系CVEの全体像
2026年10月の2件は、入口が違うだけで、最終的に起きることは同じです。開発者のPC上にあるストーリーファイル（*.stories.tsxなど）が書き換えられ、条件がそろうと開発者の権限でコードが動きます。
CVE-2026-114125で悪意あるWebサイトから物語ファイルが書き換わる流れ
Storybookチームのアドバイザリによると、問題の起点はプレビュー画面のiframeが通信相手のオリジンを確かめていなかったことです。開発サーバーを動かしたまま攻撃者のサイトを開くと、そのサイトがプレビューを埋め込み、開発サーバーへイベントを送れました。利用者の操作を伴えば、ストーリーファイルを無断で書き換えさせられます。書き換えたファイルがローカルの実行環境で動けば、開発者の権限で任意のコードが実行されるおそれがあります。
GitHubの評価はCVSS v4.0で9.4です。ネットワーク経由・権限不要で、利用者の操作（UI:P）を前提にしています。対象のパッケージは次のとおりです。
storybook：8.0.0以上8.6.19未満、9.0.0以上9.1.21未満、10.0.0以上10.6.2未満、11.0.0-alpha.0以上11.0.0-alpha.6未満@storybook/addon-vitest：9系・10系・11系で上と同じ範囲@storybook/addon-mcp：10.6.0以上10.6.2未満と11系のアルファ版- 8系の
@storybook/core・@storybook/core-server・@storybook/experimental-addon-test：8.6.19未満
ブラウザで一度も開かない開発サーバー（ヘッドレスの自動実行やMCPクライアントからの利用）と、ビルド済みのStorybookは対象外です。最近のChromeとFirefoxは、Webサイトがlocalhostへ接続する前に許可を求めることがあり、危険は下がります。ただしアドバイザリは「なくなるわけではない」としており、知らないサイトにこの許可を与えないよう求める内容です。Chromeの仕組みはLocal Network Accessの告知のとおりで、Chrome 142から許可の確認が出ます。
CVE-2026-114126で同一LANの端末がWebSocketトークンを盗める条件
もう1件のCVE-2026-114126は、開発サーバーのHTMLを読み込める相手なら誰でもWebSocketの認証トークンを取れた、という問題です。同じLANの端末はIPアドレスで開発サーバーを開けるため、トークンを入手し、ストーリーファイルへコードを差し込んだり新しいファイルを作ったりできました。CVSS v4.0は8.7で、攻撃元が隣接ネットワーク（AV:A）に限られる分、114125より低く評価されています。
影響が大きくなるのは、Vitestアドオンを入れていて、Vitest自体の版が古い場合です。アドバイザリによると、差し込んだ内容からテストを実行させ、Vitestの機能を使ってさらに別のファイルを書き込めました。カフェや出張先のWi-Fi、本物を装ったアクセスポイントにつないで開発サーバーを動かしていた場合が典型の該当例です。ポートを公開していないコンテナ、または127.0.0.1だけで公開しているコンテナで動かしていれば対象外になります。
2025年12月と2026年2月に公表された開発サーバー系CVEの対象版と修正版
Storybookでは、開発サーバーを狙う脆弱性が2026年に入って3件目です。過去の2件は今回より前の修正版で直っているため、今回の修正版へ上げれば同時に解消します。
| 識別番号 | 内容 | 影響する場所 | 修正版 |
|---|---|---|---|
| CVE-2026-114125 | 悪意あるサイトからのコード差し込み | 開発サーバー | 8.6.19・9.1.21・10.6.2 |
| CVE-2026-114126 | LANからのコード差し込み | 開発サーバー | 8.6.19・9.1.21・10.6.2 |
| CVE-2026-27148 | WebSocketの乗っ取り | 開発サーバー | 8.6.17・9.1.19・10.2.10 |
| CVE-2025-68429 | .envの値がビルドに混入 | ビルド成果物 | 7.6.21 8.6.15 9.1.17 10.1.10 |
2026年2月のCVE-2026-27148は、WebSocketが接続元のオリジンを検証せず、悪意あるサイトを開くだけでストーリーの作成・保存の処理を呼べたものです。2025年12月のCVE-2025-68429だけは性質が違い、.envファイルのある場所でstorybook buildを実行すると、その値が成果物に入ることがありました。公開したStorybookに秘密の値が含まれていた場合、Storybookチームはその鍵を漏れたものとして入れ替えるよう求めています。
自社プロジェクトが対象かをnpm lsと起動スクリプトで確かめる手順
判定は「版」「開発サーバーの使い方」「待ち受けアドレス」の順に進めます。版が修正版以上なら、その時点で対象外と記録して構いません。
npm lsとpnpm whyでstorybookとaddon-vitestの版を調べる
package.jsonの"^10.3.0"のような指定は範囲で、実際に入っている版ではありません。ロックファイルが解決した版をコマンドで読み取ります。モノレポでは、ワークスペースごとに別の版が入っていることがあります。
# 実際に入っている版（モノレポでは全ワークスペースを表示）
npm ls storybook @storybook/addon-vitest @storybook/addon-mcp --all
# pnpm の場合
pnpm why storybook
pnpm why @storybook/addon-vitest
# 8 系は本体の分割パッケージも確かめる
npm ls @storybook/core @storybook/core-server --all
# 公開中の系列ごとの最新を確かめる
npm view storybook dist-tags
判定の基準はGitHub Advisory Databaseの範囲です。8系なら8.6.19、9系なら9.1.21、10系なら10.6.2以上であれば修正済みです。7系以前はこの2件の範囲に含まれていませんが、7系はCVE-2025-68429の対象なので、ビルドを公開している場合は7.6.21以上かを見てください。DependabotやRenovateを使っている場合、GitHub Advisory Databaseへの掲載が10月21日と22日なので、それ以降にアラートが出ていないかもあわせて確認します。
静的ビルドの公開物と開発サーバーで対象が分かれる理由と見分け方
今回の2件は、ファイルを書き換える役目を持つ開発サーバーの機能を突いたものです。storybook buildで作る静的ファイルには、ファイルを書き込む仕組みもWebSocketもありません。社内やChromaticで公開しているStorybookを閲覧するだけなら、閲覧者のPCも公開先のサーバーも対象外です。
見分けは、起動に使うスクリプトで行います。package.jsonのscriptsにstorybook dev（7系以前はstart-storybook）があれば開発サーバーを使っています。デザイナーや企画担当がリポジトリを取得してnpm run storybookで見ている場合、その人のPCも開発者と同じく対象です。エンジニア以外の利用者を判定から漏らしやすいので、配布先の一覧も確かめてください。Storybook自体の構成と起動方法はStorybookとは？使い方をv10.6で解説でまとめています。
storybook devの待ち受けアドレスをnetstatとlsofで確かめる手順
CVE-2026-114126に当てはまるかは、開発サーバーがどのアドレスで待ち受けていたかで決まります。修正前の版は、すべてのネットワークインターフェースで待ち受けていました。既定のポート6006で起動した状態で、次のコマンドを実行します。
# macOS / Linux：待ち受けアドレスを表示
lsof -nP -iTCP:6006 -sTCP:LISTEN
# Windows（PowerShell）
Get-NetTCPConnection -LocalPort 6006 -State Listen | Select-Object LocalAddress, LocalPort
# 起動スクリプトで --host を指定していないかを探す
grep -nE "storybook dev|--host|-h " package.json
結果が127.0.0.1だけなら、同じLANの端末からは届きません。*・0.0.0.0・::が出たら、LANから到達できる状態です。Docker Composeで"6006:6006"と書いている場合も、ホストの全インターフェースにポートを公開しているため該当します。
修正版8.6.19・9.1.21・10.6.2への更新と既定値の変更で止まる機能への対処
対象と判定したら、開発サーバーを止めてから更新します。Storybookチームは今回の修正で、8系と9系も含めて既定の動作を変えました。更新後に動かなくなる箇所を先に把握しておくと、設定で安全性を戻してしまう事態を避けられます。
系列ごとの修正版と最新10.6.4へ上げる更新コマンドと確認の順番
同じメジャー系列の中で上げるのが、影響の最も小さい更新です。storybook本体とアドオンは版をそろえる必要があるため、まとめて指定します。
# 10 系のまま上げる（10.6.2 以上の最新を入れる）
npm install -D storybook@^10.6.2 @storybook/addon-vitest@^10.6.2
# 9 系のまま上げる
npm install -D storybook@^9.1.21 @storybook/addon-vitest@^9.1.21
# 8 系のまま上げる（分割パッケージも 8.6.19 にそろえる）
npm install -D storybook@^8.6.19
# 入った版を確かめる
npm ls storybook --all
修正は10.6.2・9.1.21・8.6.19として2026年10月12日にnpmへ公開されました。8系と9系のリリースノートには、プレビューのpostMessageを既知のオリジンに限る、localhost以外からのiframe埋め込みを止める、保存先をプロジェクトのルートに閉じ込める、など列挙されている変更内容は10項目です。10系の変更は修正のプルリクエスト#36726で確認できます。11系はまだアルファ版なので、本番の開発環境で使っているなら10系へ戻すことも選択肢に入ります。
127.0.0.1待ち受けへの変更でDocker内のStorybookが開けなくなる場合
修正版の開発サーバーは、既定で127.0.0.1だけで待ち受けます。コンテナの中で起動すると、コンテナ外のブラウザからは開けません。コンテナ内では--host 0.0.0.0で待ち受け、ホスト側は127.0.0.1だけにポートを公開します。
# compose.yaml（ホスト側は 127.0.0.1 だけに公開する）
services:
storybook:
build: .
command: npx storybook dev -p 6006 --host 0.0.0.0
ports:
- "127.0.0.1:6006:6006"
// .storybook/main.ts（--host 0.0.0.0 のときはアクセスに使うホスト名を列挙する）
const config = {
framework: "@storybook/react-vite",
stories: ["../src/**/*.stories.@(ts|tsx)"],
core: {
allowedHosts: ["storybook.example.local"],
},
};
export default config;
アドバイザリによると、--host 0.0.0.0でcore.allowedHostsを指定しないと、ホストとオリジンの検証が無効になり、起動時に警告と確認が出ます。Storybookのcoreの設定では、allowedHostsは既定が空の配列で、localhostとローカルネットワークのアドレスは常に許可されます。リバースプロキシ経由のホスト名を使うときに列挙する項目です。trueを指定すると検証が外れるので、今回の修正を打ち消す設定として扱ってください。CLIのオプションの--hostにLANのIPアドレスを直接指定した場合は、検証が有効なまま共有できます。
iframe埋め込み・コンポジション・Vitestアドオンの既定値変更への対処
待ち受けのほかにも、ネットワークに関わる4つの動作が既定で変わりました。影響の出やすい順に並べます。
- 別ホストのWebサイトから開発サーバーをiframeで埋め込めなくなった（ビルド済みは従来どおり埋め込める）。戻すフラグは
security.insecureRemoteIframeEmbed - 別オリジンの開発サーバーを束ねるコンポジションが読み込めなくなった。
security.insecureIframeMessagingで戻せるが、Storybookチームは束ねる側をビルドして使うよう勧めている - アクセシビリティアドオンが使う
highlightイベントの形が変わった。ChromaticのVisual Testsアドオンは5.5.1以上へ上げないと、ハイライトからのリンクが動かない - Vitestアドオンが、Vitestのブラウザモードで動くコードからのファイル書き込みとコマンド実行（
browser.api.allowWrite・browser.api.allowExec）を止めた
社内のドキュメントサイトに開発サーバーを埋め込んでいた構成は、上記の1つ目に該当する運用です。フラグで戻すより、埋め込み先をビルド済みのStorybookへ切り替えるほうが今回の修正を残せます。Visual Testsアドオンを含むChromaticの運用はChromaticとは？Storybook連携のビジュアルテスト自動化で解説している内容を確認してください。4つ目は、テストからファイルを書き出していた場合にだけ表に出ます。Vitestのブラウザモードの設定はVitest Browser Modeの使い方を参照してください。
開発サーバーを社内LANや外部に見せてきた運用を続けるか改める判断基準
Storybookの開発サーバーは、ファイルを書き換える権限を持ったまま外から届く場所に置かれがちでした。版を上げて終わりにしてよいチームと、運用まで直すべきチームを分けて判断します。
更新後に確かめたいストーリーファイルの意図しない変更と新規ファイル
アドバイザリは悪用を確認していないと明記しています。それでも、修正前の版で開発サーバーを動かしながら外部サイトを閲覧していた、または公共のWi-Fiで開発サーバーを動かしていたなら、ストーリーファイルとその周辺に身に覚えのない変更がないかを確かめておくと判断の根拠が残ります。攻撃が成功した場合に変わるのは、ストーリーファイルと、Vitestアドオン経由で書かれる別のファイルです。
# 未コミットの変更と、追跡外の新しいファイルを一覧する
git status --porcelain
git ls-files --others --exclude-standard
# 直近 30 日にストーリーファイルへ入った変更を差分つきで見る
git log --since="30 days ago" -p -- "*.stories.*"
# play 関数や外部への通信がストーリーに入っていないかを探す
grep -rnE "play:|fetch\(|child_process|eval\(" --include="*.stories.*" src
不審な変更が見つかり、それがコミットされてCIで実行されていた場合は、CIに置いた秘密の値を入れ替える前提で調べ直してください。ストーリーファイルはCIや共有ライブラリを通じてチーム全体に広がるため、2026年2月のCVE-2026-27148のアドバイザリもサプライチェーンへの波及を警告しています。npmを起点にした同種の被害の広がり方はShai-Huludとは？npmサプライチェーン攻撃の全体像で整理した内容を確認してください。顧客の情報を扱う環境で漏えいが疑われる場合の届出の要否は、個人情報保護委員会への報告義務の整理とあわせて判断します。
共有をstorybook buildかChromaticへ寄せ開発サーバーを晒さない判断
版を上げるだけで済ませてよいのは、各自のPCでlocalhostだけで開発サーバーを使い、共有には最初からビルド済みのStorybookを使っているチームです。この場合、今回の既定値の変更でも困る場面はほとんどありません。
運用を改めるべきなのは、レビューのために開発サーバーを社内LANや外部へ見せてきたチームです。開発サーバーは「ファイルを書き換えられるサーバー」であり、閲覧用の公開には向きません。CVE-2026-27148のアドバイザリも、開発サーバーを意図して公開していると、悪意あるサイトを経由しなくても誰でも攻撃できると書いています。--host 0.0.0.0とallowedHosts: trueで元の動きに戻すことは、今回の対象に自ら戻ることと同じなので採用しません。共有はstorybook buildの成果物を静的ファイルとして配るか、Chromaticへ公開する形に切り替えてください。
開発用のサーバーやツールが社内外のどこから届くかは、Storybookに限らず把握が漏れやすい領域です。ローカルで動く開発ツールを狙う手口はPlaywright MCPのセキュリティとCVE-2025-9611対策でも扱いました。開発環境と公開環境の境目を外から点検したい場合は、一創の脆弱性診断・セキュリティ診断でご相談いただけます。
Storybookの脆弱性CVE-2026-114125対応でよく受ける質問と回答
CVE-2026-114125とCVE-2026-114126について、対応の現場で出やすい疑問をまとめました。
Chromaticや社内サーバーで公開しているStorybookも更新が必要ですか？
公開しているのがstorybook buildで作った静的ファイルなら、今回の2件の対象ではありません。閲覧者のPCも公開先のサーバーも影響を受けないため、公開物の作り直しは不要です。ただし、そのビルドを作った開発者のPCでは開発サーバーも使っているはずなので、手元のstorybookは修正版へ上げてください。ビルド成果物に.envの値が混ざるCVE-2025-68429は別の問題で、7.6.21・8.6.15・9.1.17・10.1.10より前の版でビルドした公開物は確認が必要です。
CIでstorybook buildやテストを実行しているだけでも対象ですか？
CIでstorybook buildを実行しているだけなら、開発サーバーを起動しないため対象外です。Vitestアドオンでストーリーをテストしている場合も、ブラウザで開発サーバーを開かない自動実行は、アドバイザリの対象外の例に挙がっています。とはいえ、CIの依存関係も開発者のPCと同じロックファイルから入るため、ロックファイルの更新でまとめて修正版にそろえるのが手間の少ない方法です。
すぐに更新できない場合の回避策はありますか？
Storybookチームが示している回避策は、修正版に上げるまで影響のある版の開発サーバーを起動しないことだけです。設定で穴をふさぐ方法は案内されていません。どうしても起動する必要があるなら、信頼できるネットワークだけで動かし、開発サーバーを開いたブラウザで他のサイトを閲覧しないことと、localhostへの接続の許可を知らないサイトに与えないことで危険を下げられます。あくまで更新までのつなぎです。
悪用は確認されていますか？更新はどのくらい急ぐべきですか？
2026年10月28日時点で、Storybookチームは実際のプロジェクトで悪用された証拠を受け取っていないと説明しています。攻撃には複数の弱点を順に突く必要があるとも書かれています。それでも、開発者が日常的に開発サーバーを起動したままWebを閲覧することを考えると、次にstorybook devを起動する前に更新するのが現実的な期限です。公共のWi-Fiで作業するメンバーがいるチームは、当日中の更新を勧めます。
修正版に上げたあと社内LANの同僚とStorybookを見せ合えますか？
見せ合えます。方法は2つあり、安全なのはstorybook buildで作った静的ファイルを任意の静的ファイルサーバーで配る方法です。開発中の画面をその場で見せたい場合は、storybook dev --host 192.168.0.110のように自分のLANのIPアドレスを指定すれば、ホストとオリジンの検証を保ったまま共有できます。この場合も、公共のWi-Fiでは使わず、ファイアウォールで接続元を同僚のIPアドレスに絞るようアドバイザリは勧めています。
関連記事
- Storybookとは？使い方をv10.6で解説｜導入・Next.js連携・CSF Next・テスト：Storybookの構成と導入手順の基本を確認できます。
- 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：CVSS v4.0の読み方と修正までの流れの基礎です。
- サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位：開発環境を起点にした攻撃の位置づけを確かめられます。
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：トークンの扱いと失効の設計を見直す際に役立ちます。
- Playwright MCPのセキュリティ｜危険性とCVE-2025-9611対策：ローカルで動く開発ツールが外部から操作される別の事例です。
