どうも、マイクです。おはようございます。
2025年12月6日、土曜日の朝7時をまわりました。ここからの時間は「zenncast」、今日もZennで話題になっているトレンド記事を、ゆるっとでもしっかり、押さえるところは押さえつつ紹介していきます。
今日はですね、セキュリティ界隈をざわつかせている React / Next.js の重大脆弱性の話がドーンと3本、それから技術でギャルゲーを作った楽しいお話、Flutter と Riverpod のアーキテクチャを真面目に掘った記事、あわせて5本ご紹介していきます。エンジニアの方はもちろん、なんとなく名前を聞いたことあるな〜くらいの方にも、全体像がつかめるようにお届けしていきますね。
さて、今日紹介する記事はぜんぶで5本です。ではさっそく1本目からいきましょう。
まず1つ目。「【緊急】Next.js (CVE-2025-66478) / React (CVE-2025-55182) の脆弱性について」という記事です。
これは2025年12月3日に公表された、Next.js と React Server Components、通称 RSC の内部で使われている Flight っていう通信プロトコルの重大な脆弱性の解説記事です。
ポイントは、「認証いらずでリモートコード実行ができちゃう可能性がある」という、かなりヤバい種類のやつだということ。原因は React のデシリアライズ処理、つまり「外から送られてきたデータをオブジェクトに戻す」ときのチェックが甘かったことにあります。その結果、Next.js の標準構成で App Router と RSC を使ってるアプリは、ほぼ全部影響を受ける、と。しかも怖いのが、RSC のペイロード解析が、アプリ側の認証より前に走っちゃう場合があるので、middleware とかでログインチェックしてても、その前にすり抜けて任意コード実行されるかもしれないっていう話なんですね。
CVSS スコアは満点の 10.0。影響を受けるのは Next.js だと 15 / 16 系、React は 19 系の一部ということで、Next.js は v15.0.5 / 15.1.9 / 16.0.7 に、React は v19.0.1 / 19.1.2 / 19.2.1 へのアップデートが必須とされています。この記事では、「react-server-dom-webpack」みたいな内部依存もちゃんとロックファイルを見て更新しようね、っていうところまで具体的に書かれています。
あと、恒久対策として WAF で怪しいリクエストを弾くことや、Renovate みたいなツールでパッチを自動的に検知・更新する体制づくりの大事さも語られていて、「フルスタックフレームワークの見えない内部処理がどれだけセキュリティ境界を複雑にしてるか」、それへの警鐘にもなっている内容でした。Next.js / React 触ってる方は、まずはバージョン確認、これに尽きます。
。。。。
続いて2つ目。「React2Shell (CVE-2025-55182) で気付いた React Server Components のセキュリティの盲点」という記事です。
さきほどの1本目と同じ脆弱性を、もう少し「なにが盲点だったのか」という視点で深掘りしている内容です。CVE-2025-55182、通称 React2Shell。名前からしてもう物騒ですよね。
ここで強調されているのが、「Server Function を自分で実装してなくても、RSC 対応フレームワークを使ってるだけで影響を受け得る」という点です。Next.js 15 / 16 で create-next-app のデフォルト構成をそのまま使っているだけでもアウトになる可能性がある。これはかなり多くの開発者にとって盲点だったはずです。
影響範囲も React 本体だけじゃなくて、react-server-dom-○○ 系のパッケージや、Next.js、React Router など複数のフレームワークに広がっています。「設定でオフにしとけば安心」というタイプの問題ではなくて、React / Next.js 自体を修正版に上げるしかない、と。ここが実務上のインパクト大きいところですよね。
記事では、報告から4日で修正が出たスピード感や、責任ある脆弱性開示と各社の連携、そして一時的な対策として WAF がちゃんと機能した、という「セキュリティ・インシデント対応の好事例」としても整理されています。そのうえで、「どれだけ抽象化されてカッコイイ内部プロトコルでも、信頼できない入力をどう扱うか、っていう原則的なリスクは変わらないんだ」という教訓に落とし込んでくれているのが印象的でした。
依存関係のアップデートをサボらないこと、セキュリティ情報のトラッキングを仕組み化すること。このあたり、耳が痛い人も多いかもしれませんが、React 界隈をやってるなら、ぜひ目を通しておきたい内容です。
。。。。
さあ、空気をちょっと変えていきましょう。3つ目は技術×ゲームのワクワクする話題。「JSでギャルゲー！～JavaScriptでノベルゲームエンジン作った～」という記事です。
タイトルからしてテンション上がりますが、筆者の方は「既存のノベルゲームエンジンを覚えるのが面倒だし、自分の得意な Web 技術で作ったほうが早いでしょ！」という発想から、ブラウザ上で動く OSS のノベルゲームエンジン「WebTaleKit」を自作しています。
このエンジン、UI を HTML + CSS で自由に組めるので、「ゲームエンジン特有の独自UI DSLに縛られる」のではなく、普段のWeb制作のノリで画面を作れるのが特徴です。Vue / React / Svelte なんかと組み合わせることも視野に入っていて、デザイナーとエンジニアの分業もしやすい設計。オートスケール機能で、スマホからでっかいモニタまで、どんな画面サイズでも同じ体験に近づけられるのも、今っぽくていいですよね。
セットアップも、`npm create tale-game` で環境がサクッとできちゃう。シナリオは HTML ライクな独自言語で書いていくスタイルで、テキストの表示速度、ルビ、色や装飾、ウェイト、選択肢など、ノベルゲームに欲しい表現はひと通りカバーされています。しかも、タグからそのまま JavaScript のメソッドや npm パッケージを呼んだり、REST API と連携したりもできちゃう。`.scene` ファイルをビルドして JS に変換して実行、というフローで、「プログラマだけじゃなくて、HTML に慣れてるデザイナーやシナリオライターも触りやすい」というのがコンセプトになっています。
記事中では GitHub やデモ、ドキュメントへの導線もちゃんと用意されていて、「つくったから遊んでみてよ、フィードバックちょうだい！」という距離の近さもいい感じです。技術記事なんだけど、読んでると「自分もなにか作りたくなる」タイプのエントリでした。
。。。。
4つ目、ここからまたモバイル開発に戻ります。「Flutter x Riverpodのアーキテクチャ考察」という記事。
筆者の方はもともと iOS エンジニアで、そこから Flutter に転向したなかで、「Riverpod めっちゃ便利だけど、Flutter 公式が出している MVVM + ChangeNotifier っぽい話とどう折り合いつけるの？」という疑問にちゃんと向き合っている内容です。
Riverpod の世界では ChangeNotifierProvider は「移行期のレガシー」扱いで、今は NotifierProvider を使うのが主流ですよね。ただ、Notifier の State にビューの状態を全部持たせようとすると、ViewModel 的な層がやたら太ってしまって、逆に MVVM が書きづらくなる、というジレンマが出てきます。一方で Flutter 公式のガイドも「MVVM が唯一解です！」とは言っていなくて、関心の分離とか単方向データフローみたいな原則だけ示している状態。じゃあ現場としてどうするのがバランスいいの、という話です。
この記事では、各社の事例やコミュニティのプラクティスを眺めたうえで、「ローカルな State は Flutter Hooks で、グローバルな State は Riverpod で扱う」という、いわば MVHR 的なアプローチが今のところしっくりきている、という考えを紹介しています。ただし、UseCase 層をどう切るかとか、テスト戦略をどう組み立てるかはまだまだ試行錯誤中で、「アーキテクチャに絶対解はなくて、プロダクトの性質やチームの規模によって変わるよね」という結論に落ち着いていきます。
「とりあえず MVVM」とか「とりあえずクリーンアーキテクチャ」ではなくて、Riverpod というツールを前提にしながら、自分たちの現場に合う形をちゃんと考えよう、っていう姿勢が伝わってくるので、Flutter やってる方にはすごく参考になると思います。
。。。。
そして最後、5つ目。「朝起きたら、React・Next.js に重大脆弱性が発生！【CVE-2025-55182・66478】」という記事です。
こちらは1本目・2本目で触れてきた CVE-2025-55182 と 66478 を、「朝起きたら大変なことになっていた React / Next.js 開発者の視点」で、もう少し具体的な挙動まで踏み込んで解説している内容になっています。
問題になったのは、React Server Components の内部で使われている `requireModule` という関数。こいつが、メタデータから渡される「このエクスポートを取ってきて」といった情報を、ろくに検証せずにそのまま扱ってしまった結果、任意のプロパティにアクセスできてしまった、というのが根っこの原因です。修正としては、`hasOwnProperty` を使って、そのエクスポートが本当に存在しているかどうかをちゃんと確認するようにした、という、シンプルだけど重要なガードが入りました。
GitHub にはすでに PoC、概念実証コードも上がっていて、`vm` モジュールや `child_process`、`fs` なんかを組み合わせて、いろんなパターンの RCE ガジェットが確認されています。つまり「理論上の問題」ではなく、「実際に悪用できる形まで到達している」タイプの脆弱性なんですね。
インフラ側では Cloudflare が WAF のルールを即時に適用して、この攻撃をプロアクティブにブロックしている、という話も紹介されています。記事の著者は、実際に `react` / `react-dom` / `next` を脆弱性修正版へさっさとアップデートしており、この記事を読んだ React ユーザーにも、「いますぐバージョン確認して、必要ならアップデートしてください」と強く呼びかけています。
1本目・2本目が全体像や教訓寄りなのに対して、この5本目は「なにがどう危険で、どう直ったのか」、それをできるだけかみ砕いて伝えてくれている印象でした。「朝起きたら重大脆弱性」というタイトルどおり、現場の慌ただしさも含めて伝わってくる記事です。
。。。。
ということで、きょうの zenncast は、全部で5本お届けしました。ざっとおさらいすると、まずは Next.js と React Server Components の重大脆弱性、その全体像とアップデート必須バージョン、そして React2Shell という名前で知られる CVE-2025-55182 の盲点と教訓を2本続けて紹介しました。そこから一転して、JavaScript でノベルゲームエンジン「WebTaleKit」を作った楽しい開発ストーリー、Flutter × Riverpod のアーキテクチャを真面目に考察した記事、最後に再び React / Next.js の脆弱性の技術的な中身と、実際の修正内容に踏み込んだ記事、という流れでした。
それぞれの記事の詳しい内容や、ここでは触れきれなかった図解やコード例なんかは、番組のショーノートにまとめておきますので、気になったものがあればぜひチェックしてみてください。
この「zenncast」では、番組の感想や「こういうテーマ取り上げてほしい！」といったリクエストも募集しています。ラジオネームを添えて、気軽に送ってもらえたらうれしいです。
それでは、そろそろお別れの時間です。今日も聞いてくれてありがとうございました。次回の配信でまたお会いしましょう。
お相手はマイクでした。ではでは、いってらっしゃい。