PHPの脆弱性にどう対応する？更新を追えないPHPサイトをReact・Next.jsで作り直す判断基準

PHPは、Webサイトの多くで使われているサーバー側のプログラミング言語です。W3Techsの2026年10月21日の集計では、サーバー側の言語が判明しているサイトの69.3%がPHPです。WordPressをはじめ多くのCMSがPHPで動いているため、「自社サイトはPHPで作った覚えがない」という会社でも、実際にはPHPが動いていることが少なくありません。

PHPプロジェクトは2026年だけで、5月・7月（2回）・9月・10月とセキュリティリリースを5回出しています。10月のものは特に深刻だとして、事前に予告されてから公開されました。

php.netが公表したセキュリティリリースの内容

PHPセキュリティチームは2026年10月20日、php.netで「Upcoming Critical PHP Security Release」として翌日のリリースを予告し、10月21日14:00（UTC、日本時間23:00）に修正版を公開しました。公開と同時に出されたセキュリティアドバイザリ「Security advisory: Critical remote code execution vulnerabilities, update now」の冒頭にはこうあります。

「PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.」（PHP 8.5.12・8.4.27・8.3.36・8.2.35は、認証なしのリモートコード実行を許しうる2件の重大な脆弱性を修正します。すべてのPHP利用者に、直ちに更新することを強く推奨します。）

アドバイザリには、すぐに更新できない場合の設定による軽減策も載っています。ただ、その項には「while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.」（更新だけが完全な解決策であり、以下の対策は特定の攻撃経路への露出を減らすものの、インストールを安全にするものではない。）とあり、公式自身が軽減策を更新の代わりにしていません。

各バージョンのリリース告知（PHP 8.5.12・8.4.27・8.3.36・8.2.35）にも「This is a security release」とあります。脆弱性ごとの技術的な詳細は、PHPプロジェクトがGitHubで公開しているアドバイザリ（GHSA-w8hw-w9fx-j79w・GHSA-6wmf-4rv5-p3rp）で読めます。

10月21日の時点で、IPAはこの2件を悪用した攻撃を確認していません。それでもIPAは「攻撃者はこれらの脆弱性を悪用し、極めて短時間で攻撃を実行する可能性もある」と書いています。悪用の報告が出る前に更新しておくべきです。

国家サイバー統括室・IPAの注意喚起で求められている対応

国家サイバー統括室（内閣官房）は2026年10月21日、注意・警戒情報の公式X（@cyber_forecast）で次のように注意喚起しました。

「2026年10月21日、多くのウェブサイトで使用されているPHP更新プログラムが公開されました。重大な脆弱性に関するセキュリティ修正が含まれていますので、可及的速やかに適用してください。適切な対応がなされない場合、ウェブサイト等が侵害を受ける可能性があります。」

同日の公開前の投稿では、修正パッチを速やかに適用することが困難な場合は、ウェブサイト等を一時的に停止させることもリスク低減の有効策の一つだと案内しています。

IPA（情報処理推進機構）も同日、「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を公開し、PHPを利用しているウェブサイト・ウェブサービスの棚卸しと、公開され次第の速やかな更新を呼びかけました。あわせて「サポート終了の古いPHPを利用し続けているウェブサイト・ウェブサービスも見受けられます」と指摘しています。

自社サイトが影響を受けるかを確認する方法

社内に開発者がいない会社でも、次の順で確認できます。

• サイトがPHPで動いているかを確かめる。WordPressなどのCMSで作られたサイトはPHPで動いています。分からなければ、制作会社かサーバーの事業者に問い合わせます
• PHPのバージョンを確かめる。レンタルサーバーやクラウドの管理画面に、バージョンの表示・切り替えの項目があることが多いです。WordPressなら管理画面の「サイトヘルス」でも確認できます
• 対象かどうかを判断する。8.2.35・8.3.36・8.4.27・8.5.12より前のバージョンはすべて対象です。8.1以前は公式の更新が届かないため、更新先のバージョンごと検討が必要です
• 誰が更新するかを確かめる。レンタルサーバーでは事業者側で更新される場合もあります。保守契約があれば、制作会社に対応の予定を確認します

ここで「誰に聞けばよいか分からない」「制作会社と連絡が取れない」となった場合、それ自体が今のサイトの大きなリスクです。

PHPには、バージョンごとにサポート期限があります。バグ修正を含む通常のサポート（Active Support）が終わると、セキュリティ修正だけが提供される期間（Security Support）に入り、それも終わるとサポート終了（EOL）になります。

サポート中・セキュリティ修正のみ・サポート終了の3段階

W3Techsの同じ集計で、バージョン別では8系が65.2%、7系が27.0%、5系が7.7%、4系が0.1%です。7系以前はすべてサポートが終了しているため、PHPサイトの少なくとも約35%は、公式の修正が届かないバージョンで動いていることになります。8.0・8.1もサポート終了なので、実際の割合はさらに高くなります。

放置したPHPサイトで起きうること

サポートが終了したバージョンでは、新しく見つかった脆弱性の修正が原則として提供されません。脆弱性の内容が公開されると、攻撃者はそれを基に未更新のサイトを探します。実際に被害が出た例として、2024年にはPHPのCGI版の脆弱性（CVE-2024-4577）が、Windowsの日本語環境などで悪用できることが分かり、IPAは「国内の複数組織においてこの脆弱性が悪用され、当該製品が稼働する Web サービスに webshell が設置されていたとの指摘があります」として注意喚起しました（2024年7月5日）。

サイトが侵害されると、改ざんによる偽ページの表示、問い合わせフォームに入力された個人情報の窃取、他のサイトを攻撃する踏み台にされる、検索エンジンやブラウザに「危険なサイト」と表示される、といったことが起こりえます。コーポレートサイトであっても、会社の信用に直接関わります。

更新できる体制があるなら、まず更新してください。作り直しは、更新を続けられない場合の選択肢であって、更新の代わりにはなりません。

対応の手順

• PHPを使っているサイト・サービスを棚卸しする
• 各サイトのPHPのバージョンと、誰が更新を担当するかを確かめる
• サポート中のバージョンなら、8.2.35・8.3.36・8.4.27・8.5.12のいずれかへ更新する。レンタルサーバーなら管理画面でバージョンを切り替えるか、事業者の案内に従う
• PHP本体だけでなく、WordPressなどのCMS本体・プラグイン・テーマ、フレームワーク、サーバーOSも更新する
• 更新後にサイトの表示と主要な機能（問い合わせフォームなど）が動くことを確かめる
• 更新がすぐにできない場合は、公開範囲の限定や一時停止など、影響を減らす対処を検討する

アップデートが難しくなる典型パターン

更新が「できるはずなのに進まない」サイトには、共通した事情があります。

• サイトを作った会社と連絡が取れない、または保守契約が終わっていて、誰が更新するか決まっていない
• 社内に開発者や情報システムの専任がおらず、管理画面のログイン情報やサーバーの契約の所在が分からない
• 古いバージョンのCMS・フレームワーク・プラグインに依存しており、PHPを上げると動かなくなる。更新のために改修が必要で、改修のためにまた別の更新が必要になる
• サポート終了のバージョン（8.1以前）で動いており、更新先のバージョンへ上げるには動作確認と改修を伴う
• 更新のたびに手作業で確認が必要で、担当者の負担が大きく、後回しになっている

こうしたサイトでは、今回の更新を何とか乗り切っても、次のセキュリティリリースで同じ問題に直面します。

選択肢は大きく3つです。今のまま更新を続ける「継続運用」、更新の妨げになっている部分だけを直す「部分改修」、そして1から作り直す「全面リプレイス」です。

判断の軸は「今回の更新ができるか」ではなく、「これから先も更新を追い続けられるか」です。次の項目に複数当てはまるなら、作り直しを検討する段階にあります。

• サイトを作った会社・担当者と連絡が取れない、または保守契約がない
• サイトの構成（CMS・プラグイン・サーバー）を把握している人が社内にいない
• サポート終了のPHPで動いていて、更新先に上げると動かなくなる
• ここ数年、セキュリティリリースのたびに更新できていない
• サイトの内容や機能が古く、どのみちリニューアルを検討していた

作り直すなら、GinTrickはReactとNext.js（TypeScript）を提案しています。ただ、ReactやNext.jsにしたからといって脆弱性対応がいらなくなるわけではありません。変わるのは「構成」と「更新の追いやすさ」です。

静的生成と配信の分離で、サーバー側でPHPを動かさない

PHPのサイトは、閲覧者がページを開くたびにサーバー上でPHPのプログラムが動き、ページを生成して返します。今回の脆弱性が「Webリクエストを処理するすべてのPHP」を対象としているのは、この仕組みによるものです。

Next.jsでは、コーポレートサイトやLPのような多くのページを、公開時に静的なHTMLファイルとして事前に生成し、CDNやホスティングサービスから配信するだけの構成が取れます。この構成では、閲覧者のリクエストを受けてサーバー側でプログラムを動かす部分がなくなるか、大きく減ります。サーバー側でPHPを動かさないため、PHP本体の脆弱性の影響をそもそも受けません。

ヘッドレスCMSで、管理画面を自社サーバーから切り離す

「担当者がお知らせや記事を更新できるようにしたい」という要件は、ヘッドレスCMSで満たせます。ヘッドレスCMSは、コンテンツの入力・管理の機能だけを提供するサービスで、サイトの表示は別に作ったNext.jsのサイトが担います。管理画面はCMSの事業者が運用・更新するため、自社のサーバー上で管理画面のプログラムを動かし、その更新を自社で追い続ける必要がなくなります。

ヘッドレスCMSを使ったサイトの考え方と導入の流れは、ヘッドレスCMS導入に強いWebシステム開発会社の選び方と依頼ステップで詳しく解説しています。

作り直しても残る運用：依存パッケージの更新

ReactやNext.js、サイトが依存するパッケージにも、セキュリティ修正を含む版が定期的に公開されます。作り直したサイトでも、依存パッケージの更新は続ける必要があります。

PHPサイトとの違いは、更新の対象と手順を最初から設計できることです。依存パッケージの更新を自動で検知する仕組み、更新後の動作確認とデプロイの自動化、公開後に誰がどの頻度で更新するかの取り決め。「更新を追える体制で作る」というのは、これらを構築の段階で決めておくことです。

作り直しは、今のサイトを公開したまま進めます。流れは次の5段階です。

GinTrickの開発の進め方は、無料相談から始まり、要件定義・お見積もり、設計・実装、テスト・レビュー、リリース・運用保守の順で進みます。詳しくはシステム開発のページをご覧ください。

作り直しを相談する前に、次の点を社内で整理しておくと、相談がスムーズに進みます。すべてが決まっていなくても構いません。

• 今のサイトの契約の所在：ドメイン、サーバー、CMSやプラグインの有料契約が、誰の名義で、どこにあるか
• サイトの目的と優先順位：問い合わせを増やしたいのか、採用に使いたいのか、会社案内があればよいのか
• 更新する内容と担当者：お知らせ・記事・採用情報など、何を誰がどの頻度で更新するか
• 残したい機能：問い合わせフォーム、資料請求、検索、会員機能などのうち、本当に使われているもの
• 今のサイトの脆弱性への当面の対処：作り直しの完了まで、更新するのか、公開範囲を限定するのか
• 公開後の運用体制：依存パッケージの更新や動作確認を、自社で行うのか、保守として依頼するのか

開発会社の選び方や初回相談の準備については、アプリ開発の委託を成功させる開発会社の見極め方と相談準備の全体像も参考になります。