店のホームページも、会社の問い合わせ窓口も、昨日と変わらず開く。管理画面にも入れる。だが、それだけで安全を確かめたことにはならない。2026年10月21日に修正版が公開されたPHPの重大な脆弱性は、ウェブサイトの「見た目」と、その裏側の安全性が別物であることを突き付けている。
PHPは、サーバー側でページの生成などを担うプログラミング言語である。WordPressを利用する運営者にとっても無関係ではない。ただし、今回の問題をWordPress本体の不具合だと捉えると、対策する場所を取り違える。必要なのは、記事やプラグインの更新履歴だけでなく、それらを動かすPHPに修正が適用されたかを確認することだ。
1. 何が起きたのか――ログインの外側にある危険
今回の識別番号はCVE-2026-109618とCVE-2026-109619である。PHP開発チームの勧告によれば、ウェブからの要求を処理するPHP環境が対象であり、条件がそろうと、認証されていない外部の攻撃者にコードを実行されるおそれがある。対象にはPHP-FPMやApacheのmod_phpなどが含まれる。mod_phpでは、アプリケーションのコードが実行される前に攻撃が成立する実証があるという。PHP公式勧告
一つ目は、メモリー不足が起きた際の処理に関係する。内部データが初期化の途中で中断され、その後の後始末で不正な状態のデータを扱ってしまう問題である。二つ目は、ある処理で使い終えたメモリーへの参照が内部に残り、同じワーカーが次の要求を処理する際に、その古い参照を使ってしまう問題だ。どちらも、通常なら異常を処理して終わるはずの経路が、別の危険につながる。脆弱性1の公式詳細／脆弱性2の公式詳細
ここから分かるのは、管理者のパスワードを強くしただけでは、この問題そのものを解消できないということだ。ただし、脆弱性が存在することと、個々のサイトがすでに侵害されたことも同義ではない。自分の環境の修正状況と、侵害の有無は、分けて確認する必要がある。
2. 修正版の番号だけで判断し切れない理由
二つの脆弱性への修正を含む公式リリースは、系列ごとに次のとおりである。これは10月21日の修正が入った版であり、将来にわたって「この番号だけなら安全」と保証する一覧ではない。
| PHPの系列 | 10月21日の修正版 | 公式のセキュリティサポート期限 |
|---|---|---|
| 8.2 | 8.2.35 | 2026年12月31日 |
| 8.3 | 8.3.36 | 2027年12月31日 |
| 8.4 | 8.4.27 | 2028年12月31日 |
| 8.5 | 8.5.12 | 2029年12月31日 |
PHP公式のセキュリティ勧告とサポート期限表を基に作成。修正版は今回の2件についてのもの。後述する10月23日の追加注意喚起にも留意する。修正情報／サポート期限
ここで注意したいのは、サーバー会社やOSの提供元が、修正を既存のパッケージに取り込む「バックポート」で対応する場合があることだ。PHP公式も、Linuxディストリビューションや長期保守の提供元への確認を案内している。表示上の版が表と違うという理由だけで未修正と決めつけず、契約先の告知やパッケージの修正情報を確かめたい。
一方、PHP 8.1以前は、PHPプロジェクトによる通常のサポート対象ではない。今回、7.4、8.0、8.1向けには例外的に最小限の修正ソースも提供されたが、旧系列の継続的な公式サポートが再開されたわけではない。今回をしのぐ修正と、保守される系列へ移る計画は別の課題である。
3. WordPressの更新ボタンとは、対策する場所が違う
WordPress公式は10月21日、この問題はWordPress固有ではなく、今回の問題に対応するためのWordPress更新は必要なく、予定もしていないと説明した。更新対象は、その土台であるPHPだ。WordPress公式案内
PHPの版は、WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できる。ただし、そこに表示された情報だけでバックポートの有無までは断定できない。レンタルサーバーなら、提供会社に「このサイトで使われているPHPについて、二つのCVEへの修正が適用済みか」と問い合わせるほうが、単に「最新版ですか」と聞くより具体的である。
例えば、小さな店が制作会社にサイトを発注し、サーバー代もまとめて支払っている場面を考える。これは取材例ではなく、役割分担を考えるための設定だ。店主が管理画面で更新を続けていても、PHPの変更権限は制作会社やサーバー会社にあるかもしれない。誰が作業し、いつ適用し、何を確認したかが分からなければ、担当がいることと対応が終わったことを混同してしまう。
4. 追加の注意喚起が教える「更新後」の仕事
10月23日には、PHP公式からセッションのアップロード進捗機能について追加の注意喚起が出た。特定のシリアライズ設定を実行時に切り替えるなど、通常とは異なる条件が重なった場合の問題で、CVE-2026-115560として次回リリース時に詳しい勧告を出すとしている。公式は次の通常のバグ修正版まで、同機能を無効にする設定を提案する一方、実行時に該当設定を切り替えないアプリケーションは有効のままでもよいと説明した。PHP公式の追加注意喚起
したがって、21日の修正版を入れたという一事だけで、その後の案内を読む必要がなくなるわけではない。他方、すべての環境で同じ追加問題が成立するという意味でもない。一般の運営者が設定例をそのまま貼り付けるのではなく、自分の環境で条件が当てはまるか、管理担当者に確かめるべき場面である。
5. すぐ直せないとき、何を優先するか
EUのENISAなどの共同声明は、PHPを使うシステムの洗い出しと提供会社との連携を求め、インターネットに公開されたものを優先するよう促している。製品の内部でPHPを使っており、利用者からは見えない場合もある。直接管理するホームページだけを調べて、確認を終えないことが重要だ。EU機関などの共同声明
すぐに修正を適用できない場合、英国NCSCは提供元の暫定対策を確認し、それも実行できない、または時間がかかり過ぎるなら、十分に対処できるまでシステムを停止することの検討を求めている。停止は一律の命令ではなく、公開を続ける危険とサービスへの影響を踏まえた判断である。また、侵害の可能性がある場合は、修正とは別に不正な設置物などの調査が必要となる。英国NCSCの案内
編集部としては、まず管理担当と連絡を取り、修正適用の可否と時刻を確認し、難しければ公開範囲の制限や停止を相談する順番を勧める。これらは公式案内を基にした対応の整理であり、個別環境の安全を保証するものではない。WAFなどによる防御があっても、PHP側の修正が済んだ証拠には置き換えられない。
6. 独自の視点――足りないのは更新ボタンではなく、確認の引き継ぎだ
今回の公式資料を重ねて読むと、問題は技術の難しさだけではない。PHP側は修正版を示し、WordPress側は対処する層の違いを説明し、公的機関は管理範囲の洗い出しと提供会社への連絡を求めている。対策は一つの管理画面の中で完結せず、複数の担当者をまたいでいる。
ここからは編集部の分析である。小規模なサイトほど必要なのは、安心を約束する一般論より、対応を完了したと判断できる記録ではないか。「適用した修正」「作業日時」「実際の稼働環境」「適用後に確認した機能」を短く残す。これなら、店主がPHPの内部構造を説明できなくても、次の担当者へ何を引き継ぐべきかは見える。
さらに、今回の表では、同じ日に重大な修正を受けた系列でも、サポート期限は2026年末から2029年末まで異なる。今日の穴をふさぐ仕事と、次の穴に対応できる状態を保つ仕事は、同じではない。「表示できるサイト」を「保守し続けられるサイト」へ変える。その違いを契約や担当範囲に落とし込めるかが、今回の警告を一度きりで終わらせない分かれ目である。
出典とメモ
- PHP公式・2026年の告知：10月21日の修正対象・修正版・バックポート・暫定対策と、23日の追加注意喚起を照合した。
- CVE-2026-109618の公式詳細、CVE-2026-109619の公式詳細：概要と修正版を確認した。
- PHP公式サポート期限表：各系列の期限を確認した。
- WordPress公式の注意喚起：PHPとWordPress本体の対応範囲、稼働版の確認場所を確認した。
- ENISAなどの共同声明、英国NCSCの注意喚起：対象環境の把握、提供会社との連携、対処できない場合の判断を確認した。
- 情報は2026年10月24日時点。特定サイトの侵害や修正適用を調査した記事ではない。攻撃の再現試験、被害件数の推計、実際には行っていない取材は含めていない。設定変更や停止は、契約先・管理担当者と最新の公式情報を確認して判断する。
