32blog
Web

PHPの脆弱性でNext.jsに移るべきか　移っても安全にならない理由

2026年10月のPHPの重大な脆弱性（PHP2Shell）を受けて、WordPressやPHPのサイトをNext.jsに移すべきか。PHP・WordPress・Next.jsの脆弱性の件数と実際の悪用を一次ソースで比べ、経営者が判断できる形にまとめた。

by omitsu公開23 min read
目次

PHP の重大な脆弱性を理由に Next.js へ移っても、サイトは安全にならない。Next.js にも同じ種類の重大な脆弱性は出ているし、実際の攻撃にも使われた。効くのは言語の乗り換えではなく、2つのことだ。

  • 外から届くリクエストで動くプログラムを、減らす
  • 脆弱性が出たら、すぐ更新できる体制にする

まず、何をすればいいか

今の状況ごとに、やることはこう分かれる。

今の状況やること
PHP 8.2〜8.5 を使っている修正版に更新する。レンタルサーバーなら、事業者が更新したかを確かめる
PHP 8.1 以前を使っている修正版が出ないので、サポート中の版へ上げる。すぐ上げられないなら、外からのアクセスを止めることも考える
更新を誰がやるか決まっていないまず担当を決める。言語を変えても、この問題は消えない
表示の遅さや作り直しなど、別の理由もあるそのときは、移行も選択肢に入る

何が起きたのか

2026年10月21日、PHP の開発チームが、2件の重大な脆弱性を直した版を出した。「PHP2Shell」と呼ばれている。

  • 外から送ったリクエストで、サーバーの上で好きなプログラムを動かされるおそれがある
  • Web で動く PHP は、ほぼすべてが対象
  • いちばん危ない構成（Apache の mod_php）では、ログインなしのリクエスト1つで、アプリやプラグインのコードが動く前に成り立つことが実証されている

公式の告知は、対象をこう書いている。

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

（対象: Web のリクエストを処理しているすべての PHP。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed を含む）

— php.net

そして、回避策では足りないと書いている。

There are no complete mitigations, updating is the only safe choice.

（完全な回避策は無い。更新だけが安全な選択だ）

— PHP 8.5.12 Released!

日本の IPA も注意を出している。修正が出ない古い版を使っている場合は、サポート中の版への更新か、対策済みの製品・サービスへの移行を検討するように、としている。

脆弱性の中身（エンジニア向け）
  • CVE-2026-109618（GHSA-w8hw-w9fx-j79w）: メモリ不足の処理で状態が壊れる。CVSS v4.0 は 9.2
  • CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）: 前のリクエストの解放済みメモリを、次のリクエストが使ってしまう。CVSS v4.0 は 9.2
  • 直った版: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12
  • いちばん危ないのは mod_php。公式は "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs"（認証なしのリクエストで、アプリのコードが動く前に攻撃が成立する実証がある）と書いている
  • NVD の評価は CVSS 3.1 で 9.8 と 8.1。php.net の評価（v4.0 で 9.2）とは基準が違う
  • 8.1 以前は公式の新しい版が出ない。ただし公式は、ソースから組む人向けに、7.4・8.0・8.1 への最小限の修正を出している
  • 公式が挙げる一時しのぎは、リクエストの大きさを手前で絞る、session.upload_progress.enabled=0 にする、8.5 なら fatal_error_backtraces=0 にする、など。どれも完全ではないとされている
  • 2026年10月23日の時点で、CISA の「実際に悪用された脆弱性」の一覧（KEV）には載っていない

出典は記事末尾の参考文献にまとめた。

海外では、どう受け止められたのか

Reddit と Hacker News の議論を、2026年10月26日に 53 スレッド分読んだ。「PHP をやめるべきだ」という声はあった。ただ、多かったのは次の3つの意見だった。

  • 言語ではなく、運用の問題だ
  • ほかの言語にも同じことは起きる
  • 書き直すより、更新するほうが安い

「言語のせいではない」が多数派だった

いちばん支持を集めたコメントの1つは、PHP だけの問題ではないと指摘していた。

PHP isn't going to be the only web language experiencing these kinds of vulnerabilities as AI runs every language through the wringer.

（AI があらゆる言語を徹底的に洗うようになれば、この種の脆弱性に見舞われる Web の言語は PHP だけでは済まない）

— omniuni, r/technology（スコア 2,689）

実際、同じ10月21日に、Next.js が動く土台の Node.js も、リモートでコードを実行される脆弱性（CVE-2026-111497、深刻度 high）を直した版を出している。

Node literally declared security vulnerabilities the same day as PHP

（Node なんて、PHP と同じ日に脆弱性を発表してたぞ）

— svenjoy_it, r/PHP（スコア 138）

止まった会社は、パッチを待っていたのではなかった

IT 管理者の集まる掲示板では、対応が遅れた組織の原因をこう書いた投稿があった。

So the orgs that stayed dark mostly weren't waiting on a patch. They were stuck on "where is PHP running, which version, and who owns it?"

（止まったままの組織の多くは、パッチを待っていたわけではない。「PHP がどこで動いていて、どの版で、誰の持ち物なのか」で詰まっていた）

— arhimedosin, r/ITManagers

逆に、日ごろから更新していた会社は、すぐ片付いた。

We upgrade our major PHP version every year, staying just behind bleeding edge. The business has questioned why for years: this was their answer.

（うちは毎年 PHP のメジャー版を上げて、最新の一歩手前にいる。会社には何年も「なぜ」と問われてきた。これがその答えだ）

— tommyk1210, r/ExperiencedDevs（スコア 540）

移るなら、言語より「静的なサイト」という声

移行を勧める人の多くが挙げていたのは、別の言語ではなく、静的なサイトだった。

I'm really not sure how you mitigate this issue, other than serving static HTML and reducing the attack surface to cut out dependencies like PHP.

（静的な HTML を配って、PHP のような依存を外し、攻められる面を減らす以外に、この問題をどう和らげられるのか分からない）

— rectang, Hacker News

現場で起きたことと、白熱したやり取り（エンジニア向け）

現場で起きたこと

いずれも本人の書き込みで、裏は取れていない。

  • 上司がパッチを止めた。"My boss said we can't patch w/o a pointed Jira card, and it can wait for the next sprint..."（チケットが無いとパッチは当てられない、次のスプリントでいい、と言われた）— DOOManiac, r/PHP（スコア 110）。後の返信で、冗談ではなかったと書いている
  • 止めるほうが安いと判断した。"For most of them it's cheaper to lose a day of work than to pay for recovery."（多くの客にとって、1日仕事を失うほうが、復旧に払うより安い）— lpapez, Hacker News
  • WAF で足りると言う客がいた。"I had a bunch of clients telling me Cloudflare is all they need to prevent this"（Cloudflare さえあれば防げると言う客が何人もいた）— Capricorn2481, Hacker News
  • PHP を使っていないのに止められた。"My hosting provider just informed me that they took down my website over this to "protect" me. It's a static website that does not use any php."（ホスティング会社が「守るため」にサイトを止めたと連絡してきた。PHP を一切使わない静的なサイトなのに）— jillesvangurp, Hacker News
  • 侵害されたという書き込みは数件あったが、どれも本人の申告だけだった。「成功した攻撃は確認されていない」という声も、同じくらいあった

白熱したやり取り

r/nextjs には「Will next js ever be secure??」（Next.js はいつか安全になるのか）というスレッドが立った。最初の返信の1つはこうだった。

Will php ever be secure??

— qascevgd, r/nextjs（スコア 12）

Hacker News では「今どき移行は安いのだから、PHP は終わらせるべきだ」という意見に、反論が続いた。

What's easier, maintaining PHP or migrating/breaking every single PHP-based site?

（PHP を保守するのと、PHP のサイトを1つ残らず移行して壊すのと、どっちが楽だ？）

— jmull, Hacker News

WordPress を管理画面だけ残して表示を Next.js で作る構成（ヘッドレス）には、2026年3月の時点で、保守の費用を心配する声が出ていた。

Most can't afford the cost difference to build headless, let alone the massively increased cost of maintenance and future additions.

（ほとんどの客は、ヘッドレスで作る差額を払えない。ましてや、大きく増える保守と今後の追加の費用は）

— Nomadic_Dev, r/Wordpress

集め方

  • Reddit 39 スレッド、Hacker News 14 スレッド。コメントは 5,458 件を読んだ
  • Reddit はブラウザで開き、返信を広げながら読んだ。大きなスレッドは、全コメントの半分ほどまでしか広げていない
  • スコアは 2026年10月26日の値。Hacker News はコメント単位の点数が取れないので書いていない

Next.js に移れば、安全になるのか

ならない。PHP 本体だけを見ると、Next.js のほうが脆弱性の件数は多い。ただし、この比べ方は公平ではない。

PHP は言語の土台だけで、Next.js は多くの機能を抱えた枠組みだ。並べるなら、実際にサイトを動かしている組み合わせ同士で比べる必要がある。

組み合わせ2025年の脆弱性実際の攻撃に使われた例
PHP 本体14件（GitHub の告知）PHP2Shell は未掲載。過去に CGI・FPM まわりで3件
WordPress の本体・プラグイン・テーマ11,334件（うち本体は6件）2026年7月の wp2shell、9月にも1件（どちらも本体）
Next.js14件（GitHub の告知）React2Shell（React を通して影響）
React（Server Components）4件（GitHub の告知）2025年12月の React2Shell
  • WordPress で見つかる脆弱性の 91% はプラグイン、9% はテーマだった
  • よく狙われる脆弱性は、公開から大量に攻撃されるまでの中央値が5時間だった
  • Next.js と React も無傷ではない。React2Shell は CVSS 10.0 で、公開された攻撃コードが出回り、ランサムウェアの攻撃にも使われた

つまり、穴の大半は PHP 本体ではなく、その上に載るプラグインにある。一方で、Next.js に移っても、重大な穴が出ること自体は変わらない。

数字の出どころと、数え方の違い（エンジニア向け）
  • PHP 本体・Next.js・React の件数は、GitHub の security advisories（php/php-src、vercel/next.js、facebook/react）を 2026年10月26日に全件取って数えた
    • PHP 本体の告知が GitHub に載り始めたのは 2023年2月。それ以前の脆弱性は入っていない
    • 2026年は、PHP 本体 29件（うち Critical 2）、Next.js 44件（うち Critical 5）、React 6件（うち Critical 1）
    • Next.js の 2026年の Critical 5件のうち3件は、画像の加工など外部の部品が原因で、その機能を使う場合だけ影響する
  • WordPress の 11,334件・91%・本体6件・中央値5時間は、Patchstack の年次報告による。GitHub の告知とは数え方が違うので、桁の違いを見るための数字として読んでほしい
  • 実際の攻撃に使われたかは、CISA の KEV（2026年10月23日版）で確かめた
    • PHP 本体: CVE-2012-1823、CVE-2019-11043、CVE-2024-4577
    • WordPress 本体: CVE-2026-60137、CVE-2026-63030（wp2shell、2026年7月21日に掲載）、CVE-2026-87902（2026年9月25日に掲載）
    • React: CVE-2025-55182（React2Shell、2025年12月5日に掲載。ランサムウェアでの使用は "Known"）
  • Next.js の修正が出るのは、今の版と1つ前の版だけ。1つ前の版は、公開から2年で打ち切られる。PHP は1つの系列を4年支える

うちも「Next.js なら安全」と思い込んでいた

このサイトは、もともと WordPress で動いていた。2026年2月に Next.js へ移した。

移した一番の理由は、表示の速さだった。WordPress の更新のメンテも面倒だった。ただ、古いテーマやプラグインのせいで問題が起きたことはない。

そして正直に書くと、「Next.js ならプラグインもテーマも無いから、安全だろう」と思い込んでいた。今回調べて、それが半分しか当たっていないと分かった。

  • 当たっていたこと: プラグインやテーマが無いので、WordPress で穴の大半を占める部分が丸ごと無い。外から触れる管理画面も無い
  • 外れていたこと: Next.js 自体にも重大な穴は出る。修正が出る期間は PHP より短く、更新を追う手間はむしろ増える

本当に効く対策は何か

言語を変えるより、次の3つのほうが効く。

1. 外から届くリクエストで動くプログラムを減らす

今回の PHP の穴は、PHP がリクエストを処理する中で起きる。逆に言えば、リクエストが PHP に届かなければ、穴があっても狙いようがない。

  • 見るだけのページは、あらかじめ HTML に書き出して配る。WordPress でも、Next.js でもできる
  • 管理画面は、自分の会社の回線や VPN からしか届かないようにする
  • お問い合わせのように入力を受け取る機能だけ、プログラムを動かす。その機能は、ほかのデータに届かない場所に分けて置く

2. 脆弱性が出たら、すぐ更新できる体制にする

今回、PHP の公式は修正版を出す前日に予告を出した。修正版が出た日に更新できたかどうかで、危険にさらされる期間が変わる。

  • 誰が更新するのかを決めておく（社内の担当、制作会社、レンタルサーバーの事業者）
  • 「何日以内に更新するか」を、保守の契約や社内の決まりに書いておく
  • サポートが切れた版を使い続けない

3. 国のフィルタや WAF だけに頼らない

外国からのアクセスを止めたり、攻撃らしいリクエストを手前で止める WAF を置いたりするのは、無駄ではない。ただ、更新の代わりにはならない。

  • WAF が止められるのは、知られている攻撃の形だけだ。今回も AWS や Vercel が WAF のルールを出したが、Vercel は "does not replace patching"（パッチの代わりにはならない）と書いている
  • 国で止めても、日本にあるサーバーから送られれば通る
  • PHP の公式も、更新以外の手は完全ではないと書いている

移行を考えていいのは、どんなときか

移行そのものが悪いわけではない。言語の乗り換えだけを理由にしないことが大事だ。

移行の理由判断
PHP の脆弱性が怖い理由にならない。更新の体制を先に整える
PHP 8.1 以前で、上げるには作り直しが要る移行も選択肢になる
表示が遅い、デザインを作り直したい移行の理由になる
プラグインが多く、更新のたびに表示の確認が重い移行の理由になる。ただし、Next.js も更新は要る

Next.js に移したときの良い点と悪い点は、こうなる。

  • 良い点: ページの多くを HTML に書き出せる。プラグインやテーマ、外から触れる管理画面が無い。表示が速くなりやすい
  • 悪い点: Next.js 自体にも重大な穴は出る。修正が出る期間が短い。WordPress のような自動更新の仕組みは無い。記事の更新はエンジニアでないと難しい

参考文献