Vitest RCE脆弱性（CVE-2026-47429ほか）｜影響バージョンの確認・パッチ適用・SCA検知の手順

2026年5月から6月にかけて、Viteベースの人気JavaScriptテストフレームワークVitestに、立て続けに3件の深刻な脆弱性が公表された。中心となるCVE-2026-47429はCVSS 9.8（Critical）で、Vitest UIサーバの不正なファイルアクセス検査を突いて任意ファイルの読み取りとリモートコード実行（RCE）に至る。Vitestは週5300万ダウンロードを超え、無数のCI/CDパイプラインで動いているため、影響範囲は極めて広い。本記事では、影響バージョンの確認・パッチ適用・SCA（Software Composition Analysis）による継続検知までを手順で解説する。

AIエージェント時代のセキュリティ全体像を整理したい方は、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドを先に読むと、本記事の位置づけがつかみやすい。

30秒で理解する

まず要点だけを押さえる。今回のVitest脆弱性は、単独のバグではなく3件のアドバイザリの束である。共通する本質は「Vitestが内部で立ち上げるサーバ（UIサーバ・Browser Mode API・WebSocket RPC）が、信頼できない相手に届く状態だと危険」という一点に尽きる。

・対象と深刻度: CVE-2026-47428（CVSS 9.6）、CVE-2026-47429（CVSS 9.8）、およびCVE採番待ちのCDP経由RCE（GHSA-g8mr-85jm-7xhm、CVSS 9.8）の計3件。いずれもCriticalで、結果はリモートコード実行
・影響範囲: vitest本体は4.1.0未満および3.2.5未満。@vitest/browserは4.1.7以下・3.2.4以下・5.0.0-beta.3以下。関連のvite-plusは0.1.23以下
・修正版: 4.x系は4.1.8以降、3.x系は3.2.5以降、5.0ベータ系は5.0.0-beta.4以降。これを満たせば3件すべて解消
・確認手順: （1）npm ls vitestで直接・推移的依存を洗い出し （2）npm auditでアラート確認 （3）GitHubのDependabot / GHSAアラートを点検
・当面の対応: 即時アップデートが最優先。上げられない場合はサーバを127.0.0.1に固定し、新設のallowWrite/allowExecフラグを無効のまま運用し、信頼できないテスト・設定ファイルをCIで実行しない

この記事は「自分のプロジェクトが影響を受けるか」を最短で判定し、「どう直すか」「どうCIで再発を防ぐか」までを一本で完結させることを目的にしている。攻撃の具体的なペイロードは扱わず、防御・検知・修正のコマンドのみを示す。

何が起きたか — Vitestの3つのRCE脆弱性

Vitestは、Viteのトランスフォームパイプラインをそのまま使えることで急速に普及したテストフレームワークだ。Jestからの移行先として定着し、週5300万ダウンロードという規模に達している。その中核に、テスト結果を可視化するUIサーバ、実ブラウザでテストを走らせるBrowser Mode、そしてそれらを仲介するWebSocket RPCが組み込まれている。今回のRCE脆弱性は、この「テストのために立ち上がる常駐サーバ」群を狙ったものだ。

公表のタイムラインは次の通り。2026年5月19日に2件（CVE-2026-47428とCVE-2026-47429）が同時に開示され、いずれも@hi-ogawa氏が報告した。続く6月1日に、Browser ModeのChrome DevTools Protocol（CDP）ブリッジを突くRCE（GHSA-g8mr-85jm-7xhm）が@sheremet-va氏（Vitestメンテナ）により公表された。3件はそれぞれ攻撃面が異なるが、いずれも「サーバが信頼できない相手に到達可能であること」を前提条件として共有している。

報道の起点となったsecurityonline.infoの記事（2026年6月5日）は、3件をまとめて「CVSS 9.8のRCE群」として紹介した。ただし後述するように、公式のGitHub Security Advisory（GHSA）を確認すると、CVE-2026-47428のCVSSは9.6（ユーザー操作が必要なためAC/UIの評価が異なる）であり、修正バージョンもアドバイザリごとに異なる。本記事は一次ソースであるGHSAの数値を採用している。

npmエコシステムを狙う攻撃の最近の流れは、Microsoftが警告したnpmサプライチェーン侵害｜redhat-cloud-services 31パッケージに自己増殖ワーム「Miasma」でも詳述している。今回のVitest脆弱性は「悪意あるパッケージの混入」ではなく「正規パッケージの設計上の欠陥」だが、依存ツリーの可視化と継続監視という対策の方向性は共通する。

攻撃が成立する3つの経路

3件の脆弱性が、それぞれどの経路でコード実行に至るかを整理しておく。重要なのは、どれも「攻撃者がVitestのサーバ機能に到達できる」ことが起点になっている点だ。

・CVE-2026-47428（otelCarrierスクリプト挿入）: Browser ModeがotelCarrierクエリパラメータをサニタイズせずにインラインのモジュールスクリプトへ埋め込んでいた。攻撃者が細工したブラウザランナーURLを開かせると、Vitestサーバのオリジン上で任意のJavaScriptが実行され、露出したVITEST_API_TOKENと連鎖させることでサーバサイドのコード実行につながり得る。被害者によるURLオープン（ユーザー操作）が必要
・CVE-2026-47429（UIサーバの不正ファイルアクセス）: UIサーバの/__vitest_attachment__ハンドラが、非推奨のisFileServingAllowedを誤った順序で使っていたため、Windows上で\\?\..\形式のパストラバーサルで検査を回避できた。任意ファイル読み取りに加え、saveTestFileでテストファイルを書き込みrerunで実行する経路を併用するとRCEに至る
・CDP経由RCE（GHSA-g8mr-85jm-7xhm）: Browser Modeが公開するcdp()関数が、生のChrome DevTools ProtocolメソッドをWebSocket RPC越しにそのまま転送し、しかもallowWrite/allowExecフラグを尊重していなかった。攻撃者はPage.setDownloadBehaviorとRuntime.evaluateを悪用してvite.config.tsを上書きし、設定リロード時にNode.jsコードを実行させる

プロンプトインジェクションのように「信頼できない入力が制御に変わる」攻撃クラスは近年急増している。入力検証の発想を整理したい場合はプロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01も参考になる。

脆弱性の詳細とCVSS評価

3件のRCE脆弱性のCVSS評価とベクトルを並べると、攻撃の性質の違いが見えてくる。いずれもネットワーク経由（AV:N）かつ攻撃複雑度が低い（AC:L）が、CVE-2026-47428だけは被害者の操作を要する（UI:R）ため総合スコアがやや低い。

3件に共通するのは、機密性・完全性・可用性のすべてに「高（H）」が付いている点だ。任意ファイルの読み取り（機密性）、設定ファイルやテストファイルの書き換え（完全性）、そしてプロセスの掌握（可用性）が同時に成立する。これがRCEの典型的なCVSSプロファイルである。

攻撃フロー（CDP経由RCEの例）

3件のうち最も「テストツールらしからぬ」のがCDP経由RCEだ。Browser ModeがPlaywright ChromiumのようなCDP対応プロバイダを使い、ブラウザAPIサーバを--browser.api.host=0.0.0.0でネットワーク公開し、アクティブなブラウザセッションが存在する——この3条件が揃うと、生成されたランナーページに含まれるAPIトークン・セッションID・プロジェクト名・ルートパスを足がかりに、攻撃者が設定ファイルを書き換えてコード実行に至る。流れを図にすると次のようになる。

この図のポイントは、最終的な実行が「Vitestが自分の設定ファイルを読み込み直す」という正規の動作を通じて起きることだ。つまり、外形上は「Vitestが普通に設定をリロードしただけ」に見える。だからこそ、攻撃面そのものを閉じる（サーバを公開しない、allowExecを無効にする）ことが本質的な対策になる。

影響範囲：影響バージョンと修正バージョン

影響を受けるパッケージとバージョンを、アドバイザリごとに正確に整理する。Vitestはvitest本体と@vitest/browserでアドバイザリが分かれているため、両方を確認する必要がある。

。CVE-2026-47429はvitest 4.1.0で修正済みだが、CDP経由RCEが@vitest/browser 4.1.8を要求するため、4.x系で安全といえるラインは4.1.8だ。中途半端に4.1.0〜4.1.7で止めると、CDP経由RCEが残る点に注意したい。

ソース記事と公式の数値の差分

冒頭で触れた通り、報道の起点となったsecurityonline.infoの記事は3件を「すべてCVSS 9.8、修正版は4.1.6 / 5.0.0-beta.3」とまとめていた。一方、公式GHSAを確認すると、（1）CVE-2026-47428はユーザー操作必須のため9.6であり、（2）修正バージョンはアドバイザリごとに異なり、CVE-2026-47429は4.1.0 / 3.2.5、CDP経由RCEは4.1.8 / 3.2.5 / 5.0.0-beta.4で修正されている。さらに本記事執筆時点でCVE-2026-47429のNVDエントリは「RESERVED（予約済み・詳細未公開）」状態であり、現時点での一次ソースはGitHub Security Advisoryである。数値はすべて公式GHSAに合わせている。

⚡対応確認の手順（重点セクション）

ここからが本記事の中心だ。「自分のプロジェクトが影響を受けるか」を確実に判定する手順を、パッケージマネージャ別に示す。直接依存だけでなく推移的依存（他のツール経由で入っているvitest）も必ず確認する。

Step 1: 自分のプロジェクトで使っているか確認

まずvitestがツリーのどこに、どのバージョンで入っているかを洗い出す。npm lsは推移的依存も含めて表示する。

# npm: 直接依存・推移的依存の両方をツリー表示
npm ls vitest @vitest/browser

# yarn / pnpm: なぜそのバージョンが入っているかを遡る
yarn why vitest
pnpm why vitest

# モノレポは全ワークスペースを横断して確認
pnpm -r exec npm ls vitest

npm lsが「(empty)」を返せばvitestは依存ツリーに存在しない。逆に複数バージョンが並ぶ場合は、推移的依存で古いvitestが残っているサインなので要注意だ。

Step 2: バージョン確認

検出されたvitestが影響バージョン帯（4.1.0未満 / 3.2.5未満 など）かどうかを、宣言（package.json）と実体（lockfile）の両面から確認する。

# 宣言上のバージョンレンジ
grep -E '"vitest"|"@vitest/|"vite"' package.json

# npm: lockfileで「実際に固定されているバージョン」を確認
grep -A 2 '"node_modules/vitest"' package-lock.json

# pnpm / yarn のlockfile
grep -A 3 "vitest@" pnpm-lock.yaml
grep -A 3 'vitest@' yarn.lock

ここで重要なのは、package.jsonが^4.0.0のような幅を持つレンジでも、lockfileで固定された実体が影響帯かどうかで判定するという点だ。lockfileを基準にすること。

Step 3: npm audit / GHSA 確認

npm auditはlockfileとGitHub Advisory Databaseを突き合わせ、既知脆弱性を報告する。CIに組み込みやすい最も手軽な検知手段だ。

# 既知脆弱性の要約
npm audit

# 機械可読な詳細（CI連携やフィルタ用）
npm audit --json | jq '.vulnerabilities | keys'

# 特定リポジトリのGHSAアラートをAPIで取得
gh api graphql -f query='
  query {
    repository(owner:"YOUR_ORG", name:"YOUR_REPO") {
      vulnerabilityAlerts(first: 20, states: OPEN) {
        nodes { securityAdvisory { ghsaId summary severity } }
      }
    }
  }'

npm auditがvitestや@vitest/browserをHigh/Criticalとして挙げたら、Step 2で確認した実体バージョンと、本記事の影響範囲表を突き合わせる。

Step 4: GitHub Dependabot / Security alerts の点検

GitHubを使っているなら、Dependabotアラートが最も網羅的だ。リポジトリの Settings → Code security → Dependabot alerts を開き、vitest関連のアラートが出ていないかを確認する。あわせて、

・Dependabotのセキュリティ更新（自動PR作成）が有効になっているか
・Dependabotの自動マージ設定が、意図せず未レビューのまま走っていないか
・privateリポジトリでDependabotが無効化されたままになっていないか

を点検する。privateリポジトリではDependabotがデフォルト無効のことがあり、見落としの温床になりやすい。

Step 5: 過去のCI実行を遡って汚染を検査

影響バージョンを使っていた期間に、CIが攻撃を受けた痕跡がないかを確認する。特にfork PRから誰でもトリガーできるテスト経路があった場合は重点的に調べる。

・公開リポジトリで、fork PRがvitestを含むテストジョブを起動できる設定だったか（GitHub Actionsのpull_request_targetは特に注意）
・CIログに、vitest起動時の不審な外部通信・想定外のコマンド実行・vite.config.tsの予期せぬ変更がないか
・CI環境のsecret（トークン・APIキー）が、当該期間にローテーションされず露出していなかったか

CIの認証情報が漏れた場合の封じ込めは多層で考える必要がある。トークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターンで、漏洩を前提とした被害最小化の設計を解説している。

⚙️ 修正手順

影響を確認したら、修正は基本的に「各系列の最新パッチへ上げる」だけだ。ただし推移的依存とlockfileの扱いで詰まりやすいので、ケース別に示す。

A. シンプルなアップデート

直接依存としてvitestを持つ単一パッケージのプロジェクトなら、これで十分だ。

# 4.x系を使っている場合（3件すべてを塞ぐ 4.1.8 以降へ）
npm install -D vitest@^4.1.8

# Browser Mode を使っている場合は @vitest/browser も明示的に
npm install -D @vitest/browser@^4.1.8

# 推移的依存も含めてlockfileを更新し、再現インストールで固定
npm update vitest @vitest/browser
npm ci

更新後は必ずnpm ls vitestを再実行し、影響帯のバージョンがツリーに残っていないことを確認する。

B. モノレポでの一括更新

pnpm / yarn workspacesやTurborepoでは、ワークスペースをまたいでバージョンが散らばりやすい。-r（recursive）で一括更新するのが確実だ。

# pnpm workspaces: 全ワークスペースのvitestを更新
pnpm -r update vitest@^4.1.8 @vitest/browser@^4.1.8

# yarn workspaces
yarn workspaces foreach -A up vitest@^4.1.8

# 更新後、残存バージョンがないか全ワークスペースを再確認
pnpm -r exec npm ls vitest

pnpm.overrides（package.jsonのpnpm.overrides）やresolutions（yarn）を使えば、推移的依存として入った古いvitestも強制的に修正版へ寄せられる。

{
  "pnpm": {
    "overrides": {
      "vitest@<4.1.8": "4.1.8",
      "@vitest/browser@<4.1.8": "4.1.8"
    }
  }
}

C. すぐにアップデートできない場合の暫定対策

メジャー更新が絡んでテストが壊れるなど、即時更新が難しい場合は攻撃面そのものを閉じる。今回の3件はいずれもサーバの公開を前提とするため、公開をやめれば実害リスクは大きく下がる。

・サーバをlocalhostに固定する: Vitest設定でserverやapi.hostを127.0.0.1に明示し、0.0.0.0バインドをやめる
・新設のallowWrite/allowExecを無効のまま運用する: 修正版ではサーバが非localhostにバインドされると、これらは既定で無効になり、UIは読み取り専用（ブラウザ内コード編集・テスト実行が無効）になる。暫定対策としてもこの状態を維持する
・CIをfork PRから隔離する: pull_request_targetでsecretを露出させない。fork PRのテストはsecretなしの隔離環境で走らせる
・Vitest実行コンテナをサンドボックス化する: ネットワークegressを遮断し、secretへのアクセス権限を最小化する
・信頼できないテストファイル・設定ファイルをCIで実行しない: 外部から差し込まれたvite.config.tsやテストファイルが、レビューなしに走らない経路を断つ

これらはあくまで時間稼ぎだ。恒久対策は修正版へのアップデートであることを忘れないこと。

SCA（Software Composition Analysis）でCIから検知する

今回のような「依存ライブラリの脆弱性」は、人手の棚卸しでは追いきれない。SCAツールをCIに組み込み、影響バージョンがマージされる前に止める仕組みが本質的な再発防止策になる。代表的なツールを比較する。

実務上の順序としては、まずDependabotで「気づける状態」を作るのが最短だ。GitHubリポジトリなら追加コストなしで脆弱性アラートと更新PRが回り始める。dependabot.ymlの最小構成は次の通り。

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # vitest等の重大更新を優先的に拾う
    open-pull-requests-limit: 10

そのうえで、npm auditをCIの必須チェックにし、High以上を検出したらマージをブロックする。

# High以上の脆弱性があれば非ゼロ終了でCIを止める
npm audit --audit-level=high

Dependabotで通知を受け、npm auditでマージをブロックし、必要に応じてSocketで挙動を確認する——この3層で「影響バージョンが本番に出ない」状態を作れる。

似たパターンで狙われやすい開発ツール

Vitestの今回の脆弱性は、特殊な事故ではない。「開発者の手元やCIで常駐サーバを立ち上げる開発ツール」は、構造的に同じリスクを抱えている。Vitest自身、2025年2月にも類似のRCEを公表していた。

・CVE-2025-24964（GHSA-9crc-q9x8-hgqq）: Vitest APIサーバが待ち受け中に悪意あるWebサイトを訪れると、Originヘッダ検証と認可の欠如によりCross-site WebSocket Hijacking（CSWSH）が成立し、saveTestFile＋rerunでRCEに至る（2025年2月）
・CVE-2025-24963（GHSA-8gvc-j273-4wm5）: Browser Modeが任意ファイルを配信してしまう問題（2025年2月）

これらと今回の3件は、いずれも「ローカル前提で作られたサーバ機能が、ネットワークに露出したときに崩れる」という同根の構造を持つ。開発ツール一般に視野を広げると、devサーバ・ビルドツール・テストランナーが攻撃面になる事例は珍しくない。Jest・Mocha・Playwright・Cypress・Vite・esbuildといったツール群も、HMRサーバやインスペクタ、デバッグポートを開く以上、同じ注意が必要だ。

加えて、正規パッケージの欠陥とは別系統で、悪意あるパッケージの混入というnpmサプライチェーン攻撃も並行して激化している。両者は対策の重なりが大きく、依存ツリーの可視化・継続監視・最小権限という基本が効く。

npmサプライチェーン攻撃の具体例と防御はMicrosoftが警告したnpmサプライチェーン侵害｜redhat-cloud-services 31パッケージに自己増殖ワーム「Miasma」で詳しく扱っている。

企業向けチェックリストとよくある落とし穴

最後に、組織として今回のVitest脆弱性に対応する際のチェックリストと、現場で頻発する落とし穴をまとめる。

企業向け対応チェックリスト

・全プロジェクトのvitest使用状況を棚卸しする（npm ls / SBOMで横断把握）
・各系列の最新パッチ（4.1.8 / 3.2.5 / 5.0.0-beta.4）へのアップデート計画を立て、デプロイ環境まで反映する
・CI/CDでSCAを自動化し、High以上の脆弱性はPRをブロックする
・セキュリティポリシーに「信頼できないテスト・設定ファイルをCIで実行しない」を明文化する
・Vitestサーバはデフォルトでlocalhostバインド、allowWrite/allowExecは無効を標準とする
・インシデント対応プレイブックに「CI経由でsecretが漏洩した場合」のローテーション手順を含める

よくある落とし穴

・推移的依存の見落とし: package.jsonの直接依存だけ更新し、他ツール経由で入った古いvitestを放置する。npm ls vitestで全バージョンを確認すること
・環境間の更新漏れ: ローカルでアップデートしたのに、CI環境のlockfileやキャッシュが古いまま。npm ciで再現インストールし、CIキャッシュも更新する
・強制fixによる破壊: npm audit fix --forceがメジャーダウングレード/アップグレードを引き起こしテストを壊す。差分を確認してから適用する
・Dependabot PRの放置: 自動作成されたセキュリティ更新PRを承認せず溜める。これでは検知しても直っていない
・fork PR経由の設定injection: 公開リポジトリでfork PRからvitest設定ファイルが走る経路を見落とす。pull_request_targetの権限を最小化する
・privateリポでのDependabot無効化: privateではDependabotが無効のことがあり、アラート自体が出ない。明示的に有効化する

これらはいずれも「直したつもりで直っていない」状態を生む典型例だ。確認→修正→再確認のループを、npm lsとnpm auditを軸に回すことが、結局のところ最も確実な対策になる。

まとめ

Vitestの3件のRCE脆弱性（CVE-2026-47428 / CVE-2026-47429 / CDP経由RCE）は、いずれも「テスト用に立ち上がるサーバが、信頼できない相手に届く」状況で発火する。逆に言えば、各系列の最新パッチ（4.1.8 / 3.2.5 / 5.0.0-beta.4）へ上げ、サーバをlocalhostに固定し、SCAをCIに組み込む——この3点を押さえれば、今回の脆弱性は確実に封じられる。NVDの詳細公開を待つ必要はない。GHSAの情報で影響範囲は確定しており、今すぐnpm ls vitestから始められる。

参照ソース

・Vitest Security Advisories（公式・GitHub） — 一次ソース。GHSA-2h32-95rg-cppp / GHSA-5xrq-8626-4rwp / GHSA-g8mr-85jm-7xhm の影響範囲・修正版・CVSSはここを基準にした
・GHSA-g8mr-85jm-7xhm: Exposed Browser Mode API Can Proxy CDP and Overwrite Config Files, Leading to RCE — CDP経由RCEの詳細とallowWrite/allowExec緩和策
・CVE-2026-47429: When Vitest UI server is listening, arbitrary file can be read and executed（GitHub Advisory Database）
・CVE-2026-47428: Vitest browser mode serves unsanitized otelCarrier query parameter as inline script（GitHub Advisory Database）
・Vitest Remote Code Execution Vulnerabilities（securityonline.info、報道） — 本記事執筆の起点。CVSS・修正版の表記は公式GHSAを優先して補正した </content> </invoke>