2026年10月21日、PHP の開発チームが、外部から不正なプログラムを実行される可能性のある重大な脆弱性を公表し、修正版を公開しました。
PHP は、WordPress などの Web サイトをサーバー上で動かすためのソフトウェアです。普段のサイト更新では意識しにくい部分ですが、サイトの安全性を支える基盤のひとつです。
今回の発表を知っても、「うちは今まで問題が起きていない」「更新するとサイトが動かなくなるかもしれない」と、対応を決められない企業もあるかもしれません。
ただ、ここは少し厳しくお伝えしたいところです。
サポートが終了した PHP を使っているなら、被害が見えていないことだけを理由に、更新を先送りし続けるべきではありません。
必要なのは、現在の修正状況を確認し、更新の担当者と期限を決めることです。今回の事案をもとに、その理由を整理します。
※この記事は2026年10月22日時点の公式情報に基づいています。
今回は、WordPress の処理が始まる前に攻撃が成立する例も確認された
PHP 公式が発表したのは、CVE-2026-109618 と CVE-2026-109619 という2件の脆弱性です。CVE は、公開された脆弱性を区別するための識別番号です。
いずれも、ログインしていない第三者による「リモートコード実行」につながる可能性があります。外部からサーバー上で、本来許可していないプログラムを動かされるおそれがある、ということです。
特に、Apache という Web サーバーに PHP を組み込んで動かす mod_php 構成では、アプリケーションのプログラムが実行される前に、攻撃が成立する例が確認されています。
WordPress を利用していれば、その WordPress の処理に入る前の段階です。WordPress のログイン対策だけで、この問題に対応できるとは考えられません。
PHP 公式は、ほかの実行方式も含め、Web からのリクエストを処理する PHP 環境をリスクの対象として挙げています。「うちは mod_php ではないから確認不要」と判断しないでください。
10月21日に公開された修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。利用者には、速やかな更新が強く推奨されています。
ここで分かるのは、WordPress 本体やプラグインの更新と、PHP の更新は、それぞれ確認が必要だということです。
サポート終了とは、問題が見つかったときの修正提供が終わること
「サポート終了」と聞くと、問い合わせができなくなる程度の話に感じるかもしれません。
しかし、PHP の公式サポート終了は、セキュリティ上の問題に関わります。その系列に新しい脆弱性が見つかっても、PHP 開発元による継続的な修正提供を受けられなくなるためです。
2026年10月22日時点の主な系列の状況は、次のとおりです。
| PHP の系列 | 公式サポートの状況 | セキュリティサポート終了日 |
|---|---|---|
| 8.5 | 通常サポート中 | 2029年12月31日 |
| 8.4 | 通常サポート中 | 2028年12月31日 |
| 8.3 | 重大なセキュリティ問題の修正のみ | 2027年12月31日 |
| 8.2 | 重大なセキュリティ問題の修正のみ | 2026年12月31日 |
| 8.1 | 終了 | 2025年12月31日 |
| 8.0 | 終了 | 2023年11月26日 |
| 7.4 | 終了 | 2022年11月28日 |
サポート終了日に、突然サイトが動かなくなるわけではありません。表示も更新も、以前と同じようにできる場合があります。
だからこそ、画面を見ているだけでは、対応が必要な状態を見落とします。
「動いていること」と「問題が見つかったときに修正を受けられること」は、別の確認事項です。
今回の特例を、使い続けてよい理由にしない
今回、PHP セキュリティチームは、サポート終了済みの PHP 7.4、8.0、8.1 にも、最小限の修正をソースコードの形で特別に提供しています。また、OS の提供元や長期サポート事業者が、古い系列に修正を組み込んで提供する場合もあります。
そのため、古いバージョン番号だけを見て「今回の問題が必ず未修正だ」と断定することはできません。
一方で、今回の特例によって、古い系列の通常サポートが再開したわけでもありません。 利用中の環境に修正が適用されたか、今後は誰がいつまで修正を提供するのかを、サーバー会社などに確認する必要があります。PHP 公式の更新案内
「うちは大丈夫」を、何で確認していますか
「今まで被害がなかった」という認識は、更新を見送る根拠として十分でしょうか。
少なくとも、今回公表された攻撃条件に自社の環境が当てはまるか、修正が適用されているかは、その認識からは分かりません。
「小さな会社だから」「有名なサイトではないから」という説明でも、PHP の構成や修正状況は確認できません。
サーバー会社に任せている場合も同じです。委託していること自体は問題ありません。ただし、契約している環境について、今回の修正が適用済みなのか、利用者側で操作が必要なのかを確認してください。
ここで必要なのは、漠然とした安心感を、確認できる情報に置き換えることです。
- 実際にサイトで使っている PHP のバージョン
- 今回の2件の脆弱性に対する修正の適用状況
- 現在の系列に対する修正提供元と提供期限
- サポート内の系列へ移行する予定
これらに答えられない状態なら、「大丈夫」と判断するための材料が、まだそろっていません。
被害が出たとき、企業が対応するのは PHP の更新だけではない
仮に脆弱性が悪用され、不正なプログラムの実行を許してしまった場合、影響はその処理に与えられた権限や、アクセスできる情報によって変わります。
WordPress の公式資料では、侵害されたサイトで起こり得る被害として、テーマファイルの改変、不正なリンクやプログラムの埋め込み、データの改ざん・漏えい・破壊、不正ファイルの追加などを挙げています。
これらは、今回の2件による被害が確認されたという説明ではありません。サイトが侵害された場合に考えるべき影響です。
企業としては、その後の対応も含めて考える必要があります。
どこまで変更されたのかを調べる。復元に使えるバックアップを確認する。認証情報の変更が必要か判断する。公開を続けてよいか検討する。
更新費用の判断では、更新しない間に問題が起きた場合の調査・復旧・業務への影響も、比較の対象に入れるべきだと僕は考えています。
被害額を一律に示すことはできません。それでも、更新を見送れば費用も対応も発生しない、と扱うのは適切ではありません。
「更新すると壊れる」は、検証と改修が必要だというサイン
PHP を上げると、古いテーマやプラグイン、独自に追加したプログラムが動かなくなる可能性はあります。
この懸念は、軽く扱うべきではありません。WordPress 公式も、PHP 更新前のバックアップ取得や、テーマ・プラグインの互換性確認を案内しています。
ただ、その懸念を理由に、期限を決めずに使い続けると、更新を妨げている原因も残り続けます。
古いプラグインが原因なら、更新や代替手段を検討する。独自のプログラムが原因なら、改修する範囲を調べる。サーバーが対応できないなら、移転も検討する。
「更新できない」で話を終えるのではなく、何が更新を妨げていて、それを誰がいつ解消するのかまで決める必要があります。
なお、WordPress が示す推奨環境は PHP 8.3 以上です。古い PHP で WordPress が動作することと、継続運用に適した環境であることも、分けて判断してください。
企業が今、決めるべきこと
今回の対応では、目の前の脆弱性への対処と、サポート終了版からの移行を、両方進めてください。
まず、今回の修正が適用されているか確認する
WordPress では、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で PHP のバージョンを確認できます。ただし、提供元が独自に修正している場合もあるため、番号だけで判断せず、サーバー会社の案内や回答と照合してください。
修正状況が分からなければ、サーバー会社へ2件の CVE 番号を伝え、自社の環境が対応済みかを問い合わせます。
すぐに更新できない場合は、サーバー管理者と、更新までの公開継続の可否やアクセス制限などを検討してください。PHP 公式は、一時的な緩和策だけでは安全を確保できず、更新が完全な解決策だと説明しています。
次に、サポート内の系列への移行日を決める
更新先は、サーバーが提供している系列、WordPress・テーマ・プラグインとの互換性、残りのサポート期間を踏まえて選びます。
例えば PHP 8.2 は、執筆時点では公式サポート内ですが、2026年末にセキュリティサポートが終了します。移行先を決める際には、次の更新までどれだけ期間があるかも確認したいところです。
作業は、次の内容を担当者と共有して進めます。
- ファイルとデータベースを保存し、復元方法を確認する。
- 本番とは別の検証環境で、更新先の PHP に切り替える。
- 表示だけでなく、フォーム送信、ログイン、購入など、事業で使う機能を確認する。
- 問題のあるテーマ・プラグイン・独自プログラムを修正する。
- 本番環境を更新し、主要機能とエラーの記録を確認する。
不具合で古い PHP に戻す場合も、そのまま公開を続けてよいかは再判断が必要です。復旧のために戻せることと、修正前の環境を使い続けてよいことは同じではありません。
「検討します」を、担当者と期限のある対応に変える
すべてのサイトを、その日のうちに新しい PHP へ移行できるとは限りません。
それでも、現在の修正状況を問い合わせること、更新を妨げている原因の調査を依頼すること、対応責任者を決めることは、今から進められます。
今回の事案を知ったあとも「今は動いているから」と何も決めないのであれば、問題が見つかったときに対応できる体制を、いつ整えるのかが問われます。
まず決めていただきたいのは、誰が、いつまでに修正状況を確認し、更新計画を出すのかです。
自社でできる最初の確認は、PHP のバージョン、サーバー会社の告知、保守契約の担当範囲を整理するところまでです。更新先が分からない、過去に切り替えて不具合が出た、独自のテーマを誰も管理していない、といった場合は、制作・保守の担当者に調査を依頼してください。サーバー側の修正適用は、サーバー会社への確認が必要です。
相談前には、サイトの URL、サーバー会社名、PHP と WordPress のバージョン、過去の更新時の不具合を、分かる範囲でまとめておくと状況を伝えやすくなります。
WordPress 側で何が PHP 更新を妨げているのか分からない場合は、オレインデザインのお問い合わせフォームから、現在の状況をお知らせください。調査や改修が必要な範囲を整理するところから、ご相談いただけます。
