Vite 6.4.4の脆弱性の確認方法、開発サーバーから.envを読み取られるおそれと6.4.5への更新（CVE-2026-118662）

Viteの開発サーバーは、server.fs.denyに一致するファイルを返さないようにしています。公式アドバイザリによると、6.4.4では要求に?raw、?import&raw、?import&url&inlineなどのクエリを付けると、この設定で拒否した.envや*.crtなどが正常な応答（HTTP 200）で返ります。[1]

.envには鍵やパスワードを置くことが多く、条件がそろうと認証なしで中身を読まれるおそれがあります。深刻度は、Viteの評価（CVEの採番機関のGitHubも同じ値）でCVSS 4.0の6.9（警告）です。NVDは独自の評価をまだ付けていません。GitHub Advisory Databaseへの収録は10月30日（日本時間）で、提供元の公表より後です。[1][3][12]

公式アドバイザリは、次の3つの条件がすべてそろうアプリだけが影響を受けるとしています。表の初期値は、Vite公式の設定文書の記載です。[1][2]

初期値のままなら、プロジェクトのルートにある.envは2つ目と3つ目の条件に当てはまります。分かれ目は1つ目の公開の有無です（公式文書の初期値から見た当社の整理）。コンテナの中の開発サーバーに外から接続する構成では、--hostを付けて公開していることがあります。アドバイザリの条件は開発サーバーについてのもので、vite previewやビルドした成果物の記載はありません。[1][2]

米CISAの「悪用が確認された脆弱性の一覧（KEV）」には、11月1日の確認時点（10月30日版）で載っていません。今後30日に悪用される見込みの推定（EPSS）は0.3%です（10月31日時点）。[7][13]

アドバイザリには問題を起こすクエリが書かれていて、再現に必要な情報は公開されています。開発サーバーを公開した場合に?raw?importなどで拒否を回避できた、よく似たViteの過去の脆弱性CVE-2025-31125は、2026年1月22日からKEVに載っています。[1][7]

推奨する版は、Viteの公式アドバイザリと、npmに公開済みの版から出しました（11月1日確認）。上げる前に、Viteの変更履歴で変更点を確かめてください。[1][5][6]

Viteの方針では、6系は「2つ前のメジャー版」にあたり、最新のマイナー版（6.4）だけがセキュリティの修正を受けます。6.4.5の後に6系の新しい版は出ていません（11月1日確認）。[6][11]

1. 使っているViteの版を、間接の依存まで含めて確かめます。pnpmはpnpm why vite、Yarnはyarn why viteで同じことを確かめられます。6.4.4が1か所でも出れば対象です。

   ターミナル

   npm ls vite --all

2. 開発サーバーをネットワークに公開していないかを、起動スクリプトと設定ファイルで確かめます。

   ターミナル

   grep -n -- "--host" package.json
   grep -n "host" vite.config.*

3. Viteを直接入れている場合は、6.4.5以上に上げます。

   ターミナル

   npm install -D vite@^6.4.5

4. Astroなど上位のツールの依存で6.4.4が入っている場合は、package.jsonのoverridesで版を指定し、npm installし直します。Viteを直接の依存にも書いている場合は、値を"$vite"にします。[15]pnpmはpnpm.overrides、Yarnはresolutionsに同じ指定を書きます。

   package.json

   "overrides": {
     "vite": "^6.4.5"
   }

5. 開発サーバーを起動し直し、動いているViteの版を確かめます。

   ターミナル

   npx vite --version
   npm ls vite --all

6. 自分の開発サーバーで、拒否したファイルが返らないことを確かめます。プロジェクトのルートに.envがある状態で、応答が200以外（拒否）になれば直っています。

   ターミナル

   curl -s -o /dev/null -w "%{http_code}\n" "http://localhost:5173/.env?raw"

公式のアドバイザリに回避策の記載はありません。条件から見ると、開発サーバーをネットワークに公開しない（--hostやserver.hostを外し、localhostだけで待ち受ける）環境は影響の条件から外れます。これは当社の整理で、提供元が示した回避策ではありません。[1][2]

公開していた期間に.envへ置いていた鍵は、読まれた可能性を前提に替えるかを判断します（当社の整理）。また、publicディレクトリのファイルは拒否の設定にかかわらずそのまま配信されるので、機密のファイルを置いていないかも確かめます。[4]

Viteは10月6日、開発サーバーの別の脆弱性（GHSA-rq7h-c2jc-7f22、GHSA-9jrq-w75r-8gcw）を公表し、6系の修正版として6.4.4を出しました。公式の説明では、6.4.4はその修正のために変更（#20410）を取り込みましたが、組み合わせて必要な変更（#22160）を取り込みませんでした。このため、4月に7系・8系で直った同じ種類の問題（GHSA-v2wj-q39q-566r）が、6系で起きるようになりました。[1][8][9][14]

10月6日の告知に応じて6.4.4へ上げた環境ほど対象になり、6.4.3以前に留まった環境はこの件の対象外です。ただし6.4.3以前は10月6日の2件の対象なので、戻すのではなく6.4.5へ進みます。6.4.4が6系の最新だったのは、npmに出た日本時間の10月6日14時49分から、6.4.5が出た21日14時35分までです。この間にnpm installやロックファイルの作り直しで6系の範囲を解決した環境に入りえます。[6]

Viteを直接入れていなくても、上位のツールの依存で入ります。たとえばAstro 5系の最終版5.18.2は、Viteを^6.4.1の範囲で求めます。Astroの版は変えていなくても、ロックファイルを作った時期によってViteは6.4.4になります。判断には、上位のツールの版ではなく、npm ls viteに出るViteの版を使います。[10]

脆弱性の公表・更新一覧で、JavaScript / TypeScriptの関連情報を調べることもできます。