PHP 本体の重大な脆弱性が公表された — WordPress もプラグインも最新でも防げない理由と、PHP のパッチ版の確認方法
この記事は 2026年10月28日時点 の公開情報に基づく。状況は変わり続けるため、版番号や悪用状況は末尾の出典で最新の情報を確認してほしい。
何が起きたか
2026年10月下旬、PHP 本体に重大な脆弱性が2件見つかり、修正版が公開された。報道やセキュリティ各社の解説では、通称「PHP2Shell」と呼ばれている。
- 修正版は、PHP 8.2 系が 8.2.35、8.3 系が 8.3.36、8.4 系が 8.4.27、8.5 系が 8.5.12。これより古い版は影響を受けるとされる
- セキュリティ各社は、2件に CVE-2026-109618 と CVE-2026-109619 の番号を付け、深刻度（CVSS v4.0）を 9.2 としている。なお、php.net の変更履歴には GitHub のアドバイザリ番号で修正が記載されており、CVE 番号の表記は確認できなかった。番号は各社の表記として読んでほしい
- 公開日は、各社の解説では 10月21日（UTC）、php.net の変更履歴では 10月22日付の記載で、日付が1日ずれて見える
補足: CVE（Common Vulnerabilities and Exposures）は、脆弱性に付ける共通の識別番号。CVSS は深刻度を 0〜10 で表す指標で、9.0 以上は最上位の「緊急（Critical）」に分類される。
今回が「アプリを更新するだけでは防げない」理由
WordPress の保守では、本体・プラグイン・テーマの更新に意識が向きやすい。今回の脆弱性が厄介なのは、問題が WordPress やプラグインの中ではなく、それらを動かす PHP という実行基盤そのもの にある点だ。
家に例えると、玄関の鍵（WordPress 本体）や各部屋の鍵（プラグイン）をすべて最新にしても、建物の基礎（PHP）に欠陥があれば、そこは別の話になる。セキュリティ各社の解説では、PHP のメモリ処理に起因する欠陥で、研究者が WordPress などを対象に、認証なしで任意のコードを実行できることを実証したと報告されている（実証は研究結果であり、実際の被害の確認ではない）。
つまり、WordPress・プラグイン・テーマをすべて最新にしていても、PHP が修正版でなければ、この件に限っては対策が済んでいないことになる。
PHP のバージョン表記の読み方
8.3.36 という表記は、3つの数字からなる。
| 位置 | 例 | 意味 |
|---|---|---|
| 8 | メジャー | 大きな変更。互換性が壊れることがある |
| 3 | マイナー | 機能の追加。8.3 → 8.4 のように系統が変わる |
| 36 | パッチ | 同じ系統の中での不具合・セキュリティの修正 |
今回の対応は、同じ系統の中でパッチ番号を上げる作業にあたる。例えば 8.3.35 を使っているなら、8.3.36 に上げる。系統を 8.3 から 8.4 へ移す作業とは性質が違う。
以前の記事「PHP のバージョンアップで何が壊れるのか — 非推奨（deprecated）と削除（removed）の違い」で扱ったのは、系統をまたぐ移行で互換性が壊れる話だった。今回のパッチ更新は、機能を変えずに修正を取り込む更新で、互換性のリスクは系統の移行より小さいのが一般的だ。「PHP の更新は壊れるから後回し」という判断が、セキュリティ修正のパッチ更新にまで及ぶと、危険になる。
自分の環境の PHP バージョンを確認する
確認方法は複数あり、どれを見るかで結果が変わることがある点に注意してほしい。
- レンタルサーバーの管理画面: ドメインごとの PHP バージョンが表示される。実際に Web サイトを動かしているのは、この設定であることが多い
- WordPress の管理画面: 「ツール」→「サイトヘルス」→「情報」→「サーバー」に、サイトが実際に動作している PHP のバージョンが出る
- SSH でログインしてのコマンド:
php -vで確認できる。ただし、これは SSH 上で使われる PHP（コマンドライン版） のバージョンで、Web サイトを動かしている PHP と別の版であることがある
php -v
補足: 共有サーバーでは、コマンドライン用の PHP と、Web サイト用の PHP が別々に管理されていることが多い。SSH で
php -vが修正版でも、Web 側が古い、あるいはその逆もありうる。Web サイトが対象なので、管理画面かサイトヘルスで確認するのが確実だ。
確認した版が、前述の修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）以上であれば、この件の修正は取り込まれている。
版が古かった場合
- レンタルサーバーの場合: 事業者側が PHP を更新する場合と、管理画面で利用者がバージョンを切り替える場合がある。事業者のお知らせと管理画面の表示を確認する。どちらの運用かは事業者によって異なるため、自分の契約で確認が必要だ
- サポートが終了した系統を使っている場合: 今回の修正は、サポート中の系統（8.2〜8.5）向けに出されている。それ以前の系統は、修正が提供されない可能性が高いと報じられている。その場合は、修正版のある系統への移行が必要になる。移行前には、以前の記事で触れた互換性の確認と、バックアップ、段階的な切り替えが欠かせない
- 更新した後: PHP を動かしているプロセスが、更新前の状態のまま動き続けていないかを確認する。事業者側で行われることが多いが、自前のサーバーなら、更新後に Web サーバーや PHP のプロセスの再起動が必要だ
更新の前後で、サイトが正常に表示されるか、管理画面にログインできるかも確認しておきたい。
「少し待ってから当てる」判断との関係
当ブログでは「WordPress のメジャーリリースは即日当てない」という判断軸を紹介した。新機能を含む大型の更新は、初期の不具合が落ち着くのを待つほうが安全、という考え方だ。
今回のケースはこの前提が当てはまらない。セキュリティ修正のパッチ更新は、待つ間の危険のほうが、更新による不具合のリスクより大きいことが多い。しかも今回は、公開前から攻撃の試行があったと報じられている。更新の種類（機能追加か、セキュリティ修正か）によって、待つか当てるかの判断は逆になりうる。
まだはっきりしていないこと
状況を正確に伝えるため、現時点で確認できていない点も書いておく。
- 悪用の範囲: AWS、Cloudflare、Patchstack などが攻撃の試行や、ホスティング事業者からの被害報告を伝えている。一方で、Huntress は自社のパートナー環境で悪用を確認していないと報告している（いずれも10月21日前後の時点）。試行が確認されていることと、侵害が成立したことは別で、後者の全体像は確定していない
- ログの見え方: 悪用はアプリケーションより下の層で起きるため、アプリケーションのログには痕跡がほとんど残らない可能性があると解説されている。「ログに異常がないから大丈夫」とは言い切れない
- 公開された攻撃手法の有効性: 検証コードが出回っているとされるが、特定の環境に依存し、そのまま他の環境で通用するとは限らないという指摘もある
報道は日々更新される。数字や日付を引用する場合は、必ず出典で最新の内容を確認してほしい。
保守の視点から
この件は、保守の仕事の範囲をあらためて示している。WordPress 本体・プラグイン・テーマだけでなく、その下の PHP、さらにその下のサーバー環境まで、更新状況を把握しておく必要がある。
複数のサイトを管理している場合は、サイトごとに PHP のバージョンがばらつく。「どのサイトが、どの版で動いているか」を一覧で把握できていないと、今回のような通知を受けても、対象を洗い出すだけで時間がかかる。更新の作業そのものより、対象の棚卸しと確認の手順をあらかじめ決めておくことが、次の緊急時に効いてくる。
出典（2026年10月28日確認）
- PHP: ChangeLog（php.net） — 8.5.12・8.4.27 の修正内容と日付
- PHP2Shell: Critical PHP RCE Vulnerabilities（Invicti） — CVE・修正版・時系列・緩和策の解説
- PHP2Shell Exploitation: Two Critical PHP Flaws Explained（Recorded Future） — 確認できている点と確認できていない点の整理