2026年10月21日、PHPの重大な脆弱性を修正するセキュリティアップデートが公開されました。対象となるのは、CVE-2026-109618とCVE-2026-109619の2件で、「PHP2Shell」とも呼ばれています。
PHPは、WordPressをサーバー上で動かすために使われる言語です。今回の問題はPHP本体にあるため、WordPressやプラグインを最新版にしていても、PHPの修正状況を別に確認する必要があります。
この記事では、脆弱性によって起こり得る被害と、WordPress利用者ができる対応を説明します。
- 1. 参考資料
- 1.1. 英語
- 1.2. 日本語
- 2. PHPでどのような問題が見つかったのか
- 3. 攻撃されると、サイトにどのような影響があるのか
- 4. WordPressのログイン対策だけでは防げない理由
- 5. 修正されたPHPのバージョン
- 6. WordPress利用者ができる6つの対応
- 6.1. ① サイトごとにPHPのバージョンを確認する
- 6.1.1. 管理画面から「ツール＞サイトヘルス」を開く。
- 6.1.2. 「情報」タブを開く。
- 6.1.3. 「サーバー」をクリックし、「PHPバージョン」を確認する。
- 6.2. ② サーバー会社の対応状況を確認する
- 6.3. ③ バックアップと互換性を確認し、修正済みPHPを使う（PHP 8.1以前の場合）
- 6.4. ④ 更新後にバージョンと主要機能を確認する
- 6.5. ⑤ すぐに更新できない場合は、サーバー側の一時対策を相談する
- 6.6. ⑥ 不審な変更がないか確認する
- 7. 今後の運用で確認しておきたいこと
参考資料
英語
- PHP公式：CVE-2026-109618「RCE via OOM corruption」
- PHP公式：CVE-2026-109619「RCE via stale global state」
- Wiz：PHP2Shellの調査報告
- Cloudflare：PHP2ShellへのWAF対応と攻撃通信の観測
- PHP公式：2026年10月21日のセキュリティ告知
- PHP公式サイト：修正バージョンと対応情報
日本語
- PHP の重大なセキュリティリリース – WordPress.org 日本語
- Update PHP – サポートフォーラム – WordPress.org 日本語
- WordPress の安全性を高める – サポートフォーラム
PHPでどのような問題が見つかったのか
今回の2件は、PHPがメモリー上の情報を管理する仕組みに関する脆弱性です。
PHPは、ページ表示やフォーム送信などの通信を処理するとき、一時的な情報をメモリーに保存します。本来は、処理が正常に終わらなかった場合も、その情報を安全に整理して終了しなければなりません。
今回の問題は、この中断や後片付けの過程で、無効な情報を使ってしまうことにあります。
| 脆弱性 | 問題の内容 |
|---|---|
| CVE-2026-109618 | メモリー不足で処理が中断された際、準備途中の内部データを、終了時の後処理が正常なデータとして扱ってしまう |
| CVE-2026-109619 | 前の通信の処理で使ったメモリーへの参照が残り、同じPHPプロセスが次の通信を処理するときに、古い参照を使ってしまう |
後者のように、すでに使い終えて解放したメモリーを誤って使う問題を「解放後使用（Use After Free）」と呼びます。
どちらも深刻度はCVSS v4.0で9.2（Critical）と評価されています。CVSSは脆弱性の深刻さを数値で示す指標で、今回の2件は非常に重大な問題として扱われています。
攻撃されると、サイトにどのような影響があるのか
特に問題となるのは、ログインしていない攻撃者が、サーバー上で不正なプログラムを動かせる可能性があることです。これを「RCE（Remote Code Execution：リモートコード実行）」と呼びます。
加えて、PHPが処理中のメモリーに保存している情報を、外部から読み出せる経路も確認されています。発見者のWizは、WordPressなどの検証環境でのコード実行と、メモリーからの情報読み出しを報告しています。
次の表は、こうした攻撃が成立した場合に想定される被害です。すべてのサイトで発生した被害を示すものではありません。
| 想定される被害 | 具体例 |
|---|---|
| 情報の流出 | 処理中の認証情報や、アクセス可能な会員情報・非公開記事などを読み取られる |
| サイトの改ざん | 記事やリンクを書き換えられ、偽の案内や不正なページを表示される |
| 裏口の設置 | 攻撃者が後から再び操作するための、不正なファイルなどを置かれる |
| サーバーの悪用 | 攻撃者のプログラムを実行したり、不正な通信に利用されたりする |
| サービスの停止 | PHPの異常終了やデータの破壊によって、サイトが利用できなくなる |
実際の被害範囲は、PHPの実行権限やサーバーの構成によって変わります。コード実行が成立しても、直ちにサーバーの最高権限を得るという意味ではありません。しかし、PHPがサイトのファイルやデータベースを操作できる環境では、サイト運営に大きな被害を及ぼす可能性があります。
なお、Cloudflareは10月21日、今回の脆弱性を狙う攻撃通信を観測したと公表しました。攻撃通信の観測と個々のサイトでの侵入成功は別ですが、すでに攻撃が試みられていることは確認できます。
WordPressのログイン対策だけでは防げない理由
WordPressでは、強いパスワードや二段階認証などがアカウント保護に役立ちます。しかし、今回の脆弱性には、WordPressのプログラムが動き始める前に成立する攻撃経路があります。
この場合、WordPressがログイン状態を確認するより前に、PHP側で問題が起こります。WordPress内で動くセキュリティ機能だけに頼ることはできません。
PHP公式は、Apacheの「mod_php」という実行方式で、アプリケーションの実行前に成立する攻撃を確認しており、特にリスクが高いと評価しています。PHP-FPMなど、ほかの実行方式も確認対象です。ただし、成立する攻撃経路や必要な条件は環境によって異なります。
また、「訪問者向けのアップロードフォームを置いていない」ことだけでも、安全とは判断できません。画面上にフォームがあるかどうかと、PHPが外部から送られた通信を処理するかどうかは、別の問題だからです。
修正されたPHPのバージョン
今回の修正を含む正式版は、次の4つです。
| PHP系列 | 今回の修正バージョン |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
これら、または修正を引き継いだ後続バージョンを利用することが基本です。例えばPHP 8.3を使っている場合、今回の修正を適用するためだけに、必ず8.5へ切り替える必要はありません。
ただし、サーバー会社やOSベンダーが、古い系列に修正だけを取り込む場合もあります。これを「バックポート」と呼びます。その場合、表示される番号だけでは修正済みか判断できないため、提供元の案内を確認してください。
PHP 8.1以前は通常のサポートが終了しています。今回、PHP公式は7.4・8.0・8.1向けの最小限のソース修正も案内していますが、通常のサポートが再開したわけではありません。提供元の対応を確認するとともに、サポート中の系列への移行を進める必要があります。
WordPress利用者ができる6つの対応
① サイトごとにPHPのバージョンを確認する
WordPress管理画面で、次の順に開きます。
管理画面から「ツール＞サイトヘルス」を開く。
「情報」タブを開く。
「サーバー」をクリックし、「PHPバージョン」を確認する。
複数サイトを運営している場合は、各サイトを確認します。外部からアクセスできるテストサイトや、使わなくなったWordPressも忘れずに確認しましょう。
サイトヘルスに警告が出ていないことだけでは、今回の修正が適用済みとは判断できません。 バージョン番号と、サーバー会社の対応情報を照合することが大切です。
② サーバー会社の対応状況を確認する
共用レンタルサーバーでは、PHP本体の更新は基本的にサーバー会社が行います。WordPressの管理画面からPHP本体を更新することはできません。
公式のお知らせやサポート窓口などで、次の点を確認します。
- 今回の2件の脆弱性について、利用中のPHPに修正が適用されているか。
- まだ適用されていない場合、いつ対応する予定か。
- 利用者がPHPの系列を切り替える必要があるか。
サーバーパネルで「PHP 8.3」を選択できても、8.3.36まで更新されているとは限りません。系列の選択と、その系列内でのセキュリティ更新は分けて確認しましょう。
VPSなどで自分がサーバーを管理している場合は、PHPの更新と、実行中のプロセスへの反映まで自分で行う必要があります。管理を委託している場合は、その担当者へ確認してください。
各サーバー会社の対応（一例）
③ バックアップと互換性を確認し、修正済みPHPを使う（PHP 8.1以前の場合）
PHPの変更前には、WordPressのファイルとデータベースのバックアップ、復元方法を確認します。自動バックアップがある場合も、取得日時や保存対象を確認しておきましょう。
特に、PHP 7.4から8.3へ変更するような系列をまたぐ移行では、テーマやプラグインとの互換性確認が特に重要です。古いプログラムが新しいPHPで正常に動かない場合があるためです。WordPress公式も、PHP変更前のバックアップ、WordPress・テーマ・プラグインの更新、互換性確認を案内しています。
現在の系列で修正版を利用できる場合は、まずその修正を適用し、大きな系列変更は別に計画する方法もあります。動作確認に必要な準備は行いつつ、利用可能なセキュリティ修正を長期間見送らないようにしてください。
なお、バックアップには不正なファイルが含まれる可能性もあります。バックアップがあることと、侵入されていないことは別です。
④ 更新後にバージョンと主要機能を確認する
更新完了後は、サイトヘルスでPHPのバージョンを再確認します。サーバー会社が独自に修正を取り込んでいる場合は、その案内を確認します。
併せて、次の機能を実際に操作してください。
- トップページ、記事、固定ページの表示
- 管理画面へのログイン
- 記事の編集・保存
- 画像のアップロード
- 問い合わせフォームの送信とメール受信
- 会員登録、予約、購入など、サイト固有の重要な機能
ページが表示できても、フォーム送信などで問題が起きる場合があります。特に仕事の依頼や売上につながる機能は、表示だけでなく一連の操作を確認しましょう。
不具合が出た場合は、修正済みPHPで動作する構成を目指し、サーバー会社や開発元に相談します。脆弱性が残るPHPへ戻したまま放置しないことが重要です。
⑤ すぐに更新できない場合は、サーバー側の一時対策を相談する
PHP公式は一部の攻撃経路を減らす設定変更を案内していますが、設定変更だけで全体を解決することはできず、修正版の適用が必要としています。
一般のWordPress利用者は、自己判断でPHPのメモリー設定などを変更するより、サーバー会社に次のような対応を確認するのが適切です。
- 今回の脆弱性への対策事項が適用されているか。
- 必要に応じて、PHPに届く前の段階で通信を制限できるか。
- 修正版を使える環境へ移行する方法があるか（もしくは移行済みであるか）。
WAFは、不審なWeb通信を検査・遮断する仕組みです。ただし、今回の攻撃への対応状況や検査範囲は製品・設定によって異なります。Cloudflareも、WAFによる保護と併せてPHPの更新を求めています。
また、WordPressのメンテナンス画面を表示するだけでは、PHPに届く通信を止められません。公開制限を行う場合は、サーバー管理者と方法を確認してください。
⑥ 不審な変更がないか確認する
PHPを更新しても、すでに設置された不正なファイルやアカウントが自動的に消えるわけではありません。
WordPressでは、次のような変化がないか確認します。
- 見覚えのない管理者アカウントが増えている。
- 自分で追加していないプラグインがある。
- 記事やリンクが書き換えられている。
- 別のサイトへ勝手に転送される。
- セキュリティ機能から、不審なファイル変更の通知が届いている。
セキュリティプラグインのスキャンやログは調査の手掛かりになります。ただし、問題が検出されなかったことだけで、安全とは断定できません。公式の脆弱性情報でも、ログにエラーがないことは安全の証明にならないと説明されています。
疑わしい痕跡がある場合は、発見日時や画面の状態、取得できるログを保存して、サーバー会社や調査担当者へ相談してください。侵入経路と被害範囲を確認し、必要に応じて公開制限、不正ファイルの除去、復元、認証情報の変更まで進めます。
今後の運用で確認しておきたいこと
今回を機に、サイト名、使用中のPHP系列、更新担当者を一覧にしておくと、次の注意喚起にも対応しやすくなります。複数サイトを運営している場合は、テスト用や旧サイトも含めて記録しておくと、確認漏れを減らせます。
日常の保守では、WordPressの更新通知に加え、サーバー会社のセキュリティ情報も確認する習慣をつけましょう。バックアップの取得状況や復元方法、緊急時の連絡先を定期的に確認しておくことも、トラブル時の対応に役立ちます。
