Nuxt 4.5.1／3.21.10セキュリティパッチ公開。サーバーRCEや認証バイパスを修正
Nuxt開発チームは2026年7月27日、メジャーバージョン4系の4.5.1と3系の3.21.10をセキュリティパッチとして公開した。今回のリリースでは、深刻度が高いサーバーサイドのリモートコード実行（RCE）や認証バイパスなど、6つの脆弱性が修正されている。
Nuxtを利用しているプロジェクトはただちにアップグレードすることが推奨される。開発環境限定の脆弱性も含まれており、本番環境で影響を受けない場合でも、安全のため最新版への更新が求められる。
修正内容には、特定条件でのサーバー上での任意コード実行や、大文字を含むルートルールの認証バイパスなどが含まれている。また、キャッシュページで他ユーザーのデータが漏洩する問題（4.xのみ）や、DevTools経由のRCEも併せて修正された。
セキュリティパッチの全体像と影響範囲
今回のセキュリティリリースは、Nuxt 4.xと3.xの両系統にまたがる。4.xユーザーは4.5.1へ、3.xユーザーは3.21.10へアップグレードする必要がある。修正対象の脆弱性は、サーバーサイドRCE（深刻度：高）、未承認コンポーネントの生成（中）、ルートルール認証バイパス（高）、DoS（高）、キャッシュ時のクロスユーザー情報漏洩（高、4.xのみ）、開発サーバーのパス開示（低）、DevToolsのRCE（緊急、開発時限定）の7件だ。
いずれの脆弱性も、GitHubのアドバイザリを通じて報告され、複数のセキュリティ研究者の協力によって特定された。NuxtチームはVercel、Netlify、Cloudflareの各社とも協力し、一部の脆弱性については公開前に緩和策を展開している。
サーバーサイドを狙う深刻な脆弱性
サーバーアイランドProps経由のRCE
この脆弱性（CVE-2026-53721）は、vue.runtimeCompilerが有効になっている場合に発動する。デフォルトでは無効化されているため、大半のプロジェクトは影響を受けない。しかし、該当する設定では、サーバーコンポーネントやアイランドのPropsにtemplateキーを注入されることで、サーバー（Nitro）上で任意のコードが実行される可能性があった。
攻撃が成立するには、<component :is>やresolveDynamicComponent、h()といったVueの動的コンポーネント解決にPropsが渡る必要がある。@nuxt/uiが提供するreka-uiのasプロパティのようなパターンも該当する。実務上は、動的コンポーネントとサーバーアイランドを併用する設計で注意が必要だ。
このデモは、vue.runtimeCompilerが有効な場合の攻撃の流れを概念的に示している。実際には、同設定をオフにしているプロジェクトは影響を受けず、また4.5.1／3.21.10で根本的な修正が行われている。
未承認コンポーネントのインスタンス化
RCEほどではないが、こちらはvue.runtimeCompilerが無効でも影響を受ける。サーバーアイランドが宣言していないPropsを転用して、asプロパティに攻撃者が任意のHTML要素名やコンポーネント名を渡すことで、意図しない要素を生成できてしまう。
たとえば{ "as": "iframe" }のようなデータを渡されると、iframe要素が生成される可能性がある。コード実行には至らないが、予期しないDOM構造を作られてしまう点は脅威だ。Propsの宣言やinheritAttrs: falseで防ぐこともできるが、フレームワーク側での修正により、今後はこうした不正なインスタンス化はブロックされる。
認証バイパスとリソース消費攻撃
ルートルールの認証バイパス（大文字・小文字の不一致）
NuxtではrouteRulesにappMiddlewareを指定することで認証ゲートを設けられる。しかし、ルールキーに大文字が含まれる場合、リクエストのパスとケースインセンシティブにマッチせず、認証ミドルウェアがスキップされる問題があった。
これは4.4.7／3.21.7で修正された問題（CVE-2026-51354）に起因するリグレッションだ。当時の修正が逆にこの不具合を生んだ。具体的には、pages/Admin.vueのようなファイルやrouteRules: { '/Admin': ... }のような明示的なキーで、/adminへのアクセスがルールを迂回してしまう。
今回のパッチでは、ルートルールのマッチングがVue Routerと同様にケースインセンシティブに統一された。これにより大文字小文字の混在があっても、正しくミドルウェアが適用される。もし意図的にケースセンシティブなマッチングを利用していた場合は、router.options.sensitive: trueの設定が必要だ。
この図は、/Adminというルールに対して/adminがアクセスされるケースを示している。修正前はルールが適用されなかったが、4.5.1／3.21.10以降はケースを問わず認証ミドルウェアが動く。
サーバーコンポーネントへのDoS攻撃
サーバーコンポーネントやアイランドのエンドポイント（/__nuxt_island）に対して、v-forに巨大なPropsを渡すなどしてサーバーをクラッシュさせるDoS攻撃が可能だった。また、巨大なリクエストボディの解析でCPUを浪費させる問題も確認されている。どちらも認証不要で実行でき、サービス停止につながる。
修正では、こうしたPropの展開やリクエストのバリデーションが強化され、攻撃が成立しないようになった。
キャッシュページにおけるクロスユーザー情報漏洩（4.x限定）
Nuxt 4.x（4.4.0以上）で、cache、swr、isrのルートルールを認証付きページに適用している場合、キャッシュされた_payload.jsonが別のユーザーに提供される可能性があった。HTML自体は正しくユーザーごとに分離されていたが、ペイロードデータのキャッシュが意図せず共有されていたのだ。
この脆弱性は3.xには存在しない。修正バージョンにアップグレードしても、既にキャッシュされている不正なペイロードは削除されないため、別途キャッシュのパージ（CDNやブラウザキャッシュのクリア）が必要になる。
開発環境限定の脆弱性
Nuxt DevToolsのリモートコード実行（緊急）
この問題（GHSA-279x-mwfv-vcqv）は、nuxt devを実行している開発マシンに影響する。DevToolsが有効な状態で、Vite HMRソケット上で認証不要のRPCメソッドが露出しており、攻撃者が任意のコマンドを実行できる可能性があった。攻撃経路としては、同一ホスト上の別プロセス、--hostオプション使用時のLAN内の他端末、あるいは悪意あるWebサイトへの訪問が考えられる。
この脆弱性は@nuxt/devtools@3.3.1で修正されており、Nuxt本体のアップグレードに加えてロックファイルからこのバージョンが解決されることを確認する必要がある。
本番ビルドではDevToolsとHMR自体が含まれないため、この問題が本番環境に影響することは決してない。しかし、開発者が攻撃を受けるとソースコード漏洩やシステム侵害につながるため、早急な更新が推奨される。
開発サーバーのパス開示（低）
nuxi dev --hostでネットワークインターフェースにバインドしている場合に限り、Chrome DevToolsのワークスペースエンドポイントを経由して、プロジェクトの絶対パスとワークスペースUUIDがLAN上のクライアントに漏洩する問題があった。信頼できないネットワークで開発サーバーを公開している環境は注意が必要だ。
アップグレード手順と注意点
アップグレードは以下のコマンドで実行できる。ロックファイルの更新とともに、依存解決を最新化するために--dedupeオプションを付与する。
npx nuxt upgrade --dedupeこれにより、@nuxt/devtoolsも最新の3.3.1に引き上げられ、DevToolsのRCEも同時に修正される。
キャッシュ関連の脆弱性が悪用されていた場合に備え、本番環境のCDNキャッシュやブラウザキャッシュをクリアすることも推奨する。アップグレードだけでは過去にキャッシュされた不正なペイロードは消えないからだ。
また、ケースセンシティブなルートルールを意図的に使っている場合は、nuxt.config.tsでrouter.options.sensitiveを明示的に設定する必要がある点に注意してほしい。
謝辞と安全な報告体制
これらの脆弱性は、GitHubのプライベートアドバイザリやVercel OSS Bug Bountyプログラムを通じて報告された。Nuxtチームは、問題を責任をもって開示した以下のセキュリティ研究者に謝意を表している。
- Pig-Tail
- sec-reex
- DavidCarliez
- manop55555
- dinhvaren
- quantumshiro
- Saku0512
- TazmiDev
また、サーバーRCEについては、Vercel、Netlify、Cloudflareの各社と連携し、公開前に緩和策を配備する準備が整えられた。
Nuxtのセキュリティ脆弱性を発見した場合は、GitHub Security Advisoryから非公開で報告するか、security@nuxtjs.orgへメールすることが推奨されている。
この記事のポイント
- Nuxt 4.5.1と3.21.10は緊急度の高いセキュリティパッチであり、即時アップグレードが推奨
- サーバーアイランド経由のRCEは特定条件でのみ発生するが、影響度は高い
- ルートルールの大文字・小文字の不一致による認証バイパスは、4.4.7/3.21.7の修正に起因するリグレッション
- キャッシュ時のクロスユーザー情報漏洩は4.xにのみ存在し、キャッシュの手動クリアが必要
- DevToolsのRCEは開発環境限定だが、開発端末の侵害を防ぐためロックファイルの更新を忘れずに
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Nuxt 4.5リリース、Vite 8とRspack 2でビルド基盤を刷新
Nuxt 4.5の全体像とNuxt 5への布石
2026年7月18日、Vue.jsベースのフルスタックフレームワーク「Nuxt」の最新メジャーアップデート、バージョン4.5が公開された。今回のリリースは、ビルド基盤の刷新から実験的なSSRストリーミング、新たなコンポーザブルや安定したエラーコードシステムの導入に至るまで、多岐にわたる変更を含む大規模なものだ。同時に、次のメジャーバージョンであるNuxt 5に向けた内部的な準備が大きく進んだ節目でもある。
Nuxtチームの声明によれば、本リリースの大きな柱は3つある。Vite 8への移行、Rspack 2とRsbuildによるビルダーの再構築、そして実験的機能として提供されるSSRストリーミングだ。これらはいずれも開発体験と本番環境のパフォーマンスに直結するテーマであり、エンジニアにとっては見逃せないポイントが詰まっている。また、Nuxt 3系の最終ラインとなるv3.21.9も同時にリリースされ、3系ユーザーはv4への移行が推奨される状況となった。
上図のように、Nuxt 4.5は過去と未来をつなぐ架け橋の役割を担っている。3系から4系への移行は比較的スムーズだったとの声が多く、公式のアップグレードガイドも継続的にメンテナンスされている。v4.5で入った基盤変更の多くは「将来のv5への移行をできるだけ退屈にする」ための仕込みだ。チームは今後、Nuxt 5の安定化と互換性ユーティリティの作成に注力する方針を示している。
ビルド基盤の刷新 〜 Vite 8 と Rspack 2 + Rsbuild
Vite 8 への移行と開発体験の向上
Nuxt 4.5の内部では、ビルドツールがVite 8に引き上げられた。Vite 8はRolldownを採用した次世代の内部アーキテクチャを持ち、コールドスタートの高速化やHMR（Hot Module Replacement）の安定性向上が図られている。Nuxtブログの記事によれば、多くのアプリケーションにとってこのアップグレードは透過的であり、特別な設定変更なしに恩恵を受けられるという。
とはいえ、独自のViteプラグインやvite.configに手を加えているプロジェクトでは、Viteの移行ガイドを確認したほうが安全だ。エコシステム内のプラグインの中には特定のViteバージョンに依存しているものもあるため、本番環境に適用する前に互換性を検証することが推奨される。
Rspack 2 と Rsbuild ベースの新ビルダー
Rspackビルダーを利用しているプロジェクトにとっては、今回の変更はより大きな意味を持つ。Nuxt 4.5ではRust製バンドラであるRspackがバージョン2にアップデートされ、さらにそのビルダーはRsbuild（Rspackをラップする高レベルツール）を基盤とする形に再構築された。
パブリックなインターフェースは変わらず、従来通り builder:'rspack' の設定で利用できる。内部では、開発サーバーがRsbuildのミドルウェアモードで動作するようになり、webpack-dev-middlewareやwebpack-hot-middlewareが置き換えられた。また、SSR時のスコープ付きスタイルIDや厳密なESM解決のためにRspack専用のVueローダーが新たに導入されている。
この変更により、ビルド時間の短縮や開発サーバーの応答性向上が期待できる。Nuxtブログの記事では「内部的には全面的にRsbuildに移行したが、外部からはほとんど意識させない」と説明されており、アップグレード時の学習コストは低く抑えられている。
実験的SSRストリーミングで変わる初期表示速度
Nuxt 4.5で導入された実験的機能の中でも、特に注目度が高いのがSSRストリーミングだ。これは従来のサーバーサイドレンダリング（SSR）の常識を覆し、First Contentful Paint（FCP）やTime to First Byte（TTFB）を大幅に改善する可能性を秘めている。
従来のSSRとの違い
これまでのNuxtのSSRでは、サーバー側でページ全体のレンダリングが完了するまでHTMLのバッファリングを行い、完成したレスポンスを一括でクライアントに送信していた。これに対し、SSRストリーミングでは、HTMLの骨格部分（head要素、スタイル、プリロードヒント、エントリースクリプト）を直ちにフラッシュし、その後Vueがボディをレンダリングしながらストリームで送り出す仕組みになっている。
ブラウザはhead部分を受け取った時点でCSSやフォントのダウンロードを開始できるため、ユーザーは白い画面を待たされる時間が減る。特にヒーローイメージや重いスクリプトを次のページでプリロードしたいケースでは、その効果が顕著になるだろう。
クローラー対応と注意点
検索エンジンのボットに対しては、SSRストリーミングが自動的に無効化され、従来通り完全にレンダリングされたHTMLが返される。ユーザーエージェントの正規表現でカスタマイズも可能で、特定のルートだけストリーミングを無効にすることもできる。
ただし、ストリーミングを有効にする前に理解しておくべき制約が1つある。ストリーミングではHTTPステータスコードやヘッダーが最初のバイトで確定するため、レンダリング中にレスポンスを変更する処理（例えばsetup内でのsetResponseStatusやミドルウェアでのCookie書き込み）はクライアントに届かなくなる。Nuxtはリダイレクトやキャッシュルールなど、よくあるケースについては自動的にバッファリングレンダラーにフォールバックする仕組みを備えている。開発時には、ドロップされたミューテーションを警告で通知してくれるため、予期せぬ不具合に気づきやすい。
安定したエラーコードと新しいコンポーザブル
Nuxt 4.5では開発者体験を向上させる構文やユーティリティが複数追加された。その中でも、全開発者に影響がある安定したエラーコードシステムと、実務で即戦力となる新コンポーザブルについて解説する。
nostics ベースの安定エラーコード
Nuxtは今回、nosticsという仕組みを採用し、ビルド時や実行時の警告・エラーに「NUXT_E1001」のような不変のコードを付与するようになった。各コードには、なぜそれが発生したのかの説明と具体的な修正案がインラインで表示される。さらに、1行では説明しきれないエラーは専用のドキュメントページにリンクされる。
たとえば「コンポーザブルがNuxtコンテキスト外で呼ばれた」という古くからのエラーは、NUXT_E1001としてコード化され、runWithContext()の使い方まで含めた解説ページが用意された。本番ビルドでは冗長なテキストが削除され、コードだけが残るため、バンドルサイズへの影響も最小限に抑えられている。
この仕組みは、エラーの切り分けやチーム内での情報共有を格段に容易にする。Nuxtブログの記事では「この基盤の上に、さらに優れたエラーメッセージを積み重ねていく」と述べられており、今後のリリースでも拡充が続く見込みだ。
useLayout コンポーザブルと名前付きビュー
新たに追加された useLayout コンポーザブルは、現在のルートに解決されたレイアウト名をリアクティブに取得できる。これまではコンポーネント内から「このページはどのレイアウトを使っているか」をクリーンに知る手段がなく、工夫が必要だった。useLayoutは読み取り専用のcomputed refを返すため、ナビゲーションに応じて自動的に値が更新される。
さらに、名前付きビュー（Named Views）のサポートも公式に組み込まれた。親ページが複数の <NuxtPage> アウトレットをレンダリングする場合、ファイル名に 名前@ビュー名.vue の規約を使うことで、各アウトレットに対応するページコンポーネントを配置できる。これはVue Routerでは以前から可能だった機能を、Nuxtのファイルベースルーティングに統合したものだ。
useFetch / useAsyncData の enabled オプション
データフェッチの制御が柔軟になったのも地味に嬉しいポイントだ。useFetchやuseAsyncDataに enabled オプションが追加され、条件を満たすまでリクエストをブロックできるようになった。enabledがfalseの間は、初回フェッチも手動のexecute/refreshも、ウォッチャーによるトリガーもすべて抑制される。trueからfalseに変わった場合は実行中のリクエストがキャンセルされ、既存のdataは維持されるため、UIの一貫性を保ちやすい。
Nuxtブログの記事では、検索窓の入力が2文字を超えるまでAPIを叩かない、というユースケースが例示されている。依存関係の多いクエリや条件付きのデータ取得が必要な画面で、コードをシンプルに保てるだろう。
パフォーマンス改善とアップグレード時の注意点
Nuxt 4.5では、上記の主要機能に加えて、開発サーバーの起動高速化や本番ビルドのスリム化といったパフォーマンス改善も多数盛り込まれている。たとえば、NuxtがViteのファイルウォッチャーを共有する「共有ウォッチャー」モードは、メモリ使用量とファイルハンドル数を削減し、大規模プロジェクトでの起動時間を短縮する。この機能は将来のデフォルトだが、今すぐ experimental.watcher:'builder' で試すことができる。
また、プロダクションビルドでは、アイランド（Islands）を使用しない場合にアイランドレンダラーのチャンクが丸ごと省略されるなど、不要なコードの除去も進んだ。これらは設定不要で自動的に適用される。
アップグレード前に確認すべきポイント
今回のリリースはメジャーな依存関係のアップグレードを3つ含んでいるため、アップグレード時にはいくつか注意点がある。Nuxtチームが推奨するアップグレードコマンドは npx nuxt upgrade --dedupe で、ロックファイルの重複を整理しつつ、関連するunjsエコシステムのパッケージもまとめて更新できる。
- Vite 8：カスタムViteプラグインやvite.configの特殊設定がある場合、Viteの移行ガイドを事前に確認する
- Rspack 2：builder: ‘rspack’ を使用中の場合、内部がRsbuildベースに切り替わっているため、独自のRspack設定を見直す必要があるかもしれない
- unhead v3：useHeadの型が厳格化され、v2で許容されていた一部のコードが型エラーになる可能性がある。ただしランタイム動作は幅広く互換性が保たれている
これらの確認を経れば、多くのプロジェクトはスムーズに移行できるだろう。Nuxtブログの記事でも「大半のアプリでは透過的なアップグレードになる」とされており、恐れるほどの破壊的変更は限定的だ。
この記事のポイント
- Nuxt 4.5はVite 8、Rspack 2 + Rsbuildへの移行によりビルドパフォーマンスが底上げされた。v5への布石として内部基盤の刷新が進んでいる
- 実験的SSRストリーミングを有効にすると、HTMLシェルを先に送信しTTFBを改善できる。クローラーには自動で従来のSSRが提供される
- 安定エラーコードシステムにより、エラーの原因と修正法がコードベースで即座に把握可能になり、開発生産性が向上する
- useLayout、名前付きビュー、enabledオプションなど、実務ですぐ使える新構文が追加された
- アップグレード時はVite 8、Rspack 2、unhead v3の3点を中心に互換性を確認すれば、多くのプロジェクトはスムーズに移行できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験