モダンな技術ならセキュリティは安全？React2Shell・Next.jsの脆弱性・npm攻撃から考える

ReactやNext.js、サーバーレスのような新しい技術を選べば、セキュリティは安全になるのか。結論から言うと、新しい技術を使っているだけで安全とは限りません。新しい技術は一部の脆弱性を起きにくくしますが、フレームワーク自体にも脆弱性は見つかり、依存するパッケージが攻撃者に狙われることもあります。安全に使い続けるには、継続的な更新と、アクセス制御・認証情報の管理といった基本的な対策が欠かせません。

本記事では、2025年以降に公表されたReact・Next.js・npmの事例と、OWASP Top 10:2025をもとに、新しい技術で減るリスクと残るリスクを整理します。（調査時点: 2026年10月）

新しい技術で減るリスクはあるのか？

減るリスクはあります。たとえばReactは、画面に表示する文字列を既定でエスケープします。利用者が入力した文字列をそのまま画面に出しても、スクリプトとして実行されにくくなり、クロスサイトスクリプティング（XSS）が起きにくくなります。ただし、HTMLをそのまま差し込むdangerouslySetInnerHTMLのような機能を使うと、この保護は効きません。

サーバーレスやマネージドサービスを使えば、OSやミドルウェアの更新、TLS証明書の更新をクラウド事業者に任せられます。TypeScriptの型チェックやORMは、型の取り違えやSQLの組み立てミスを減らします。

このように、新しい技術は「よくある失敗」の一部を、仕組みで起きにくくしてくれます。問題は、それで残りのリスクまで消えたように感じてしまうことです。

モダンな技術でも起きた深刻な脆弱性

2025年以降だけでも、React・Next.jsには次のような脆弱性が公表されています。

React2Shell：新しい機能に見つかった最高深刻度の脆弱性

Reactは2025年12月3日、React Server Componentsに、認証なしでサーバー上の任意のコードを実行できる脆弱性があると公表しました。深刻度はCVSSの最高値10.0です。Reactは、サーバー関数を実装していないアプリでも、React Server Componentsに対応していれば影響を受ける可能性があると説明しています。Next.jsのApp Routerもこの機能を使っています。

米国のCISAは12月5日、実際に悪用が確認された脆弱性の一覧（KEVカタログ）にこの脆弱性を追加しました。公表から2日で、悪用の確認まで進んだことになります。

React Server Componentsは、Reactの中でも比較的新しい機能です。新しい機能を使うほど便利になる一方で、その機能自体が新しい攻撃の入口になることを示した事例です。

一度の更新では終わらなかった

React2Shellの修正のあとも、Reactは2025年12月から2026年1月にかけて、React Server Componentsに関するサービス拒否やソースコード露出の脆弱性を追加で公表しました。2026年1月には、それまでのサービス拒否の修正が不完全だったとして、新たな修正版を出しています（Reactの続報）。

12月に急いで更新した会社でも、1月の修正版を適用していなければ、別の脆弱性が残ったままになります。大きな脆弱性への対応は、一度の更新ではなく、続報を追い続ける作業です。

Next.jsのミドルウェア迂回：認証の置き場所の問題

2025年3月に公表されたCVE-2025-29927では、Next.jsが内部で使うヘッダーをリクエストに付けると、ミドルウェアの処理を飛ばせました。ミドルウェアだけでログインの確認をしていたアプリでは、認証を通らずに保護されたページへ到達できるおそれがありました。

Vercelは事後報告で、影響を受けたのはnext startで自社運用しているアプリで、Vercel上のアプリは影響を受けなかったと説明しています。同時に、ミドルウェアをルートを守る唯一の手段にすべきではないとも書いています。どこで動かすかによって影響が変わり、認証のチェックを一か所に頼る設計そのものがリスクになる、という教訓です。

依存しているパッケージそのものが狙われる

モダンなWeb開発では、npmなどから数百〜数千のパッケージを取り込んで動かします。自分たちのコードに問題がなくても、取り込んだパッケージが乗っ取られれば、そのまま被害を受けます。

2025年9月8日には、chalk（週に約3億回ダウンロード）やdebugなど、広く使われるnpmパッケージの管理者アカウントが、npmのサポートを装ったフィッシングメールで乗っ取られました。攻撃者は暗号資産の送金先を書き換えるコードを入れた版を公開しました（Semgrepの解説）。

その直後には、自己増殖するマルウェア「Shai-Hulud」が広がりました。CISAの注意喚起によると、このマルウェアは開発環境からGitHubのトークンやクラウドのAPIキーを盗み、乗っ取った開発者の権限で別のパッケージに不正なコードを入れて公開しました。500以上のパッケージが影響を受けています。

CISAは対策として、lockfileで依存関係を確認すること、安全な版にバージョンを固定すること、開発者の認証情報をすぐに作り直すこと、GitHubやnpmのアカウントにフィッシングに強い多要素認証を必須にすることなどを挙げています。どれも新しい技術の機能ではなく、運用の基本です。

OWASP Top 10:2025で上位に来るのは設計と設定

Webアプリの代表的なリスクをまとめたOWASP Top 10は、2025年版で次のように並びを変えました。

図はOWASP Top 10:2025の公式サイトから、CC BY 3.0の条件に従って掲載しています。

1位は2021年版に続いて「アクセス制御の不備（Broken Access Control）」、2位は「セキュリティ設定のミス（Security Misconfiguration）」です。3位には「ソフトウェアサプライチェーンの不備（Software Supply Chain Failures）」が新設されました。これは2021年版の「脆弱で古くなったコンポーネント」を広げたもので、依存パッケージ、ビルドの仕組み、配布の経路まで含みます。

上位3つはいずれも、どのフレームワークを選んだかよりも、誰に何を許可するか、どう設定するか、取り込んだ部品をどう管理するか、で決まるリスクです。新しい技術を選んでも、この3つは利用者の責任として残ります。

新しい技術ならではの注意点

新しい技術には、古い技術とは違う種類の負担もあります。

Next.jsのミドルウェア迂回では、12系・13系への修正は当初のサポート方針の範囲外で、利用者の声を受けて後から提供されました。サポートが終わった版を使い続けると、深刻な脆弱性が見つかっても修正が出ない場合があります。どの版がいつまで修正を受けられるかを把握しておく必要があります。

AIにコードを書かせる場合も同じです。新しいフレームワークで書かれたコードでも、アクセス制御の抜けや秘密情報の埋め込みは起こります。確認の観点はAIで作った業務システムを本番に出す前の確認項目にまとめています。

安全に使い続けるための基本対策

新しい技術の利点を生かしつつ、残るリスクに備えるには、次の基本対策を続けることが必要です。

1. 使っている部品とバージョンを把握する。 lockfileを管理し、本番で動いているフレームワークとランタイムのバージョンを確認できるようにする
2. 脆弱性情報を追い続ける。 フレームワークの公式ブログ、GitHubのセキュリティアドバイザリ、CISAのKEVカタログを確認し、Dependabotなどの通知を有効にする
3. 更新の手順と担当者を決める。 通常の更新の周期と、深刻な脆弱性が出たときに当日中に判断できる連絡経路を用意する
4. 認証と権限のチェックをサーバー側で行う。 ミドルウェアなど一か所に頼らず、データを返す処理の直前で権限を確認する
5. 開発者のアカウントと認証情報を守る。 GitHubやnpmには多要素認証を必須にし、トークンの権限を絞り、漏洩が疑われたらすぐに作り直す
6. 異常に気づける状態にする。 ログを保存し、エラーや不審な通信を確認できるようにする

脆弱性の深刻度の数値だけで優先順位を決めない考え方は、CVSSのスコアと対応優先順位で解説しています。ライブラリの更新、IAM、退職者のアカウント、SaaSの整理まで含めた確認項目は、Webサービス事業者のセキュリティ対策にまとめています。

wrenがモダンな技術を使うときに決めていること

wrenは、ad-cre.aiやCS Copilot.aiといった自社サービスでReact・Next.jsを使い、受託開発でも同じ技術を採用しています。新しい技術を選ぶこと自体を目的にせず、更新を続けられる体制とあわせて選ぶようにしています。

まとめ：技術を選んだあとに、守り続ける

モダンな技術は、よくある脆弱性の一部を起きにくくし、インフラの管理を任せられる範囲を広げてくれます。それでも、フレームワーク自体の脆弱性、依存パッケージの乗っ取り、アクセス制御や設定のミスは残ります。安全かどうかを決めるのは、技術の新しさではなく、選んだあとに更新と基本対策を続けられるかどうかです。

更新や監視を担う人が社内にいない場合は、SRE顧問に依頼できることを参考に、外部に任せる範囲を検討してください。wrenのSRE顧問では、依存関係の更新、監視、障害対応の手順づくりを担当しています。SRE顧問の相談フォームに、使っている技術と現在の更新体制を書いてお送りいただければ、関わり方の案をメールでお返しします。