2026年10月21日の朝、いつも通りXを見ていると、PHP開発チームの「極めて深刻な脆弱性が2件見つかった」というポストを発見しました。
セキュリティ企業などが報告しているCVE番号は、CVE-2026-109618 / CVE-2026-109619。通称「php2shell」と呼ばれている問題です。
深刻度は2件ともCVSS v4.0で9.2（Critical）。PHP公式は、日本時間10月21日23時に修正版を公開すると予告しています。
そもそもPHPは、WordPressをはじめ、多くのWebサイトで利用されているプログラミング言語です。
つまり、企業の公式サイトだけでなく、個人でWordPressブログを運営している場合も無関係ではありません。
私も実際に、エックスサーバービジネスとConoHa WINGの2環境でWordPressを運用しています。
今回は、何がそれほど危険なのかを整理しながら、実際に確認したPHPバージョン、レンタルサーバー各社の動き、WordPress運営者が取るべき対策を記録します。
※この記事は2026年10月21日21時台時点の情報です。脆弱性の詳細、影響バージョン、修正版についてはPHP公式の発表後に更新する予定です。
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.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
https://www.php.net/
- RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
- RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
そもそもPHPってなに？
PHPと聞くと、1947年に松下幸之助氏によって創刊されたPHP活動の機関誌を思い浮かべる方もいるかもしれませんが、こちらではありません。
PHPはWebサーバーで動かすオープンソースのプログラミング言語
例えばWordPressでは、記事を表示したり、ログインを処理したり、データベースから情報を取得したりするためにPHPが使われています。
普段、ブログを書いているだけなら意識することはほとんどありません。
PHPの重大な脆弱性「php2shell」とは？
今回の問題は、PHPという実行環境に存在する可能性がある脆弱性です。
セキュリティ企業などの先行報告では、攻撃に成功すると、外部からサーバー上で任意のコードを実行できる「リモートコード実行（RCE）」につながる可能性が指摘されています。
RCEとは、簡単にいえば、攻撃者が遠隔地からサーバーに意図しないプログラムを実行させられる問題です。
何がそんなにヤバいのか？
今回の脆弱性が危険視される理由は、主に3つあります。
1. WordPressのログイン画面を突破する必要がない可能性
一般的なWordPressへの攻撃には、管理者パスワードの窃取や、テーマ・プラグインの脆弱性を悪用するものがあります。
しかし、今回問題になっているのは、WordPressより下の階層にあるPHPです。
攻撃が成立する条件によっては、WordPressの管理者アカウントを取得しなくても、PHPの処理そのものが侵入口になる可能性があります。
ただし、すべてのWordPressサイトで認証不要の攻撃が成立するかは、現時点で公式に確定していません。
2. 最悪の場合、Webサイトの改ざんや情報漏えいにつながる
RCEが成立すると、PHPを実行しているユーザーの権限などに応じて、次のような被害が発生する可能性があります。
- WordPressのファイル改ざんや不正なプログラムの設置
- 設定ファイルやデータベース内の情報の窃取
- Webサイトへの不正なリダイレクトやマルウェアの埋め込み
- サーバー内部への侵入や、他のシステムへの攻撃の足掛かり
例えばWordPressには、データベースへの接続情報を記録したwp-config.phpがあります。
攻撃者がこのような重要ファイルを読み取れる状態になれば、被害は単なるホームページの改ざんでは済まなくなる可能性があります。
もちろん、脆弱性が存在するだけでこれらの被害が必ず発生するわけではありません。
3. WordPress本体を最新版にしていても解決しない
ここがWordPress利用者にとって特に重要な点です。
WordPress本体、テーマ、プラグインをすべて最新に更新していても、PHPそのものに脆弱性が残っていれば、今回の問題への対策にはなりません。
セキュリティプラグインやWAFについても、今回の攻撃を確実に遮断できるとは限りません。
根本的な対策は、PHP開発元が提供する修正版を適用することです。
技術的には何が起きるのか？
今回の脆弱性について、セキュリティ企業や研究者からは、PHPのSession Upload Progressという機能が関係しているとの情報が出ています。
この機能は、ファイルアップロードの進行状況をPHPのセッション情報として記録するものです。
例えば、大きなファイルをアップロードするとき、どれくらい処理が進んでいるかを管理するために利用できます。
そして問題として指摘されているのが、メモリの取り扱いです。
Use-After-Free（UAF）とは？
Use-After-Freeとは、一度解放したメモリ領域を、その後もプログラムが使用してしまう不具合です。
本来、使い終わったメモリは適切に解放され、その領域を指していた情報を使わないようにする必要があります。
ところが、解放済みの領域を再び参照してしまうと、プログラムが想定しないデータを処理してしまう可能性があります。
条件によっては、クラッシュだけでなく、メモリ内容の操作を通じた任意コード実行につながることがあります。
今回の研究者による説明では、ext/session/session.c内のphp_session_rfc1867_callbackに関係する、ヒープ領域のUse-After-Freeが指摘されています。
ただし、これは研究者による先行情報です。PHP開発チームが正式に技術的詳細を発表するまでは、確定した原因として扱わない方が適切です。
攻撃の検証コードまで出回っている？
研究者の公開ページでは、PHPの脆弱性に関する検証や、実証コードの作成に成功したと主張されています。
ただし、掲載内容がすべて正確であることを筆者が確認したわけではありません。
一方、GMO Flatt Securityも10月21日の追記で、脆弱性の悪用を主張するコードがインターネット上に流通し始めていると報告しています。
記事執筆時点では、IPAなどの公的機関は今回の脆弱性を悪用した攻撃を確認したとは発表していません。
PHPのどのバージョンが危険なのか？
2026年10月21日21時台時点では、PHP開発チームから影響バージョンの詳細は発表されていません。
CERT-EUなどからは、PHP 5以降の広い範囲が影響を受ける可能性が指摘されていますが、正式な影響範囲は修正版公開時に確認する必要があります。
PHP公式が明らかにしているのは、次の内容です。
| 項目 | 内容 |
|---|---|
| 重大な脆弱性 | 2件 |
| 深刻度 | CVSS v4.0 9.2（Critical）各件 |
| CVE番号 | CVE-2026-109618 / 109619との先行報告 |
| 影響するPHP | 詳細は公式発表待ち |
| 修正版公開予定 | 2026年10月21日23:00（日本時間） |
| 根本的な対策 | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 への更新 |
単純にPHP 8.5へ変更すれば安全、という話ではありません。
同じPHP 8.5でも、8.5.6と8.5.11では異なる修正状態にあります。
また、8.5.11であっても、今回の緊急セキュリティリリースより前のバージョンです。
WordPressで使用しているPHPバージョンを調べる方法
まずは、自分のWordPressサイトがどのPHPバージョンで動いているか確認します。
WordPress管理画面にログインし、次の順番で操作します。
- 「ツール」を開く
- 「サイトヘルス」を選択する
- 「情報」タブを開く
- 「サーバー」を展開する
- 「PHPバージョン」を確認する
WordPress管理画面の「ツール」→「サイトヘルス」→「情報」からPHPバージョンを確認できる。
ここに表示されるのは、実際にそのWordPressサイトを実行しているPHPのバージョンです。
レンタルサーバーの管理画面で表示されるバージョンと、WordPress側で実際に使用しているバージョンが一致するか確認しておくことが重要です。
エックスサーバービジネスで確認した状況
私が管理しているWordPressサイトの一つは、エックスサーバービジネスで運用しています。
まず、WordPressのサイトヘルスからPHPの状態を確認しました。
エックスサーバービジネス上のWordPressサイト。確認時のPHPは8.5.11、PHP SAPIはfpm-fcgiだった。
確認できた環境は次のとおりです。
| 項目 | 内容 |
|---|---|
| サーバー | エックスサーバービジネス |
| Webサーバー | Apache |
| PHP | 8.5.11 |
| PHP SAPI | fpm-fcgi |
PHP 8.5.11を利用していましたが、今回の重大脆弱性について正式な修正版が公開される前のため、安全と判断することはできません。
10月21日16時から管理画面が一時停止
緊急対応のためサーバーパネルを確認しようとしたところ、エックスサーバーの公式サイトや管理画面にアクセスできなくなっていました。
代わりに表示されたのが、以下の案内です。
エックスサーバーの案内によると、システムで使用しているソフトウェアの脆弱性に関する情報と修正版が当日公開される予定であり、予防的な安全対策として公式サイトや管理画面などを停止しているとのことでした。
今回の停止は、同社サービスに対する不正アクセスの発生に伴うものではないと明記されています。
また、利用者が契約しているサーバーについては、Webサイトの表示やメールの送受信を通常どおり利用できると案内されていました。
21時を過ぎても管理画面は利用できない状態
つまり、この時点では利用者側でサーバーパネルからPHPの設定を変更することができません。
エックスサーバー側が顧客サーバーに対して安全対策を進めているとの案内もあり、管理画面が再開するまでは、その対応状況を確認する必要があります。
実施したこと
管理画面は利用できませんが、WordPress自体にはアクセスできたため、All-in-One WP Migrationでサイトのバックアップを取得しました。
バックアップはPHPの脆弱性そのものを修正するものではありません。
しかし、更新後にWordPressの動作に不具合が発生した場合や、サイトの復旧が必要になった場合に備えることができます。
なお、プラグインで取得したバックアップには、通常PHP本体やサーバーOSの設定までは含まれません。
現時点では、エックスサーバー側の修正対応と管理画面の再開を待つ状況です。
ConoHa WINGで確認した状況
次に、個人ブログを運用しているConoHa WINGでもPHPバージョンを確認しました。
こちらはエックスサーバーとは異なる状況でした。
最初はPHP 8.3.31だった
PHP 8.3系は2026年10月時点でもセキュリティサポート期間内ですが、利用していた8.3.31は系列内の最新パッチバージョンではありませんでした。
そこで、ConoHa WINGの管理画面からPHPを8.5系へ変更することにしました。
ConoHa WINGでPHPを変更する方法
操作手順は以下のとおりです。
- ConoHaのコントロールパネルにログイン
- 「WING」を選択
- 「サイト管理」→「サイト設定」を開く
- 「応用設定」を選択
- 「PHP設定」を開く
- PHPバージョンを変更して保存
ConoHa WINGではPHP 8.3、8.4、8.5などの系列を選択できます。
ただし、ここで指定できるのは8.5などの系列であり、8.5.11といった細かなパッチバージョンを直接選択する形式ではありません。
PHP 8.5に変更しても8.5.11にはならなかった
PHPの系列を8.5に変更した後、WordPressのサイトヘルスを再確認しました。
結果は、PHP 8.5.6でした。
エックスサーバーでは8.5.11が提供されていましたが、ConoHa WINGでは今回の環境で8.5.6が動作していることが確認できました。
このことから、同じPHP 8.5を選んでも、レンタルサーバー事業者や提供環境によって実際のパッチバージョンが異なることが分かります。
また、PHP 8.5.6は今回の緊急修正版ではありません。
PHPの系列を変更しただけで、今回の脆弱性が解消されたと判断してはいけません。
WAFの状態も確認する
ConoHa WINGでは、管理画面の以下の場所からWAFを確認できます。
「サイト管理」→「サイトセキュリティ」→「WAF」
私の環境では、WAFはすでにONになっていました。
ログにはSQLインジェクションとして検知されたアクセスが多数表示されています。
ただし、これらは今回のPHP脆弱性を悪用した攻撃だと確認されたものではありません。
WAFが有効であることは重要ですが、WAFが今回の脆弱性を完全に防げるという根拠にはなりません。
ConoHa WINGも緊急メンテナンスを告知
ConoHa WINGからも、以下の日程で緊急メンテナンスが案内されていました。
| 項目 | 内容 |
|---|---|
| 開始 | 2026年10月21日19:00 |
| 終了予定 | 2026年10月22日10:00 |
| 対象 | ConoHa WING利用者 |
| 作業内容 | システムの保守作業 |
| 影響 | 一時的に接続やサービス利用ができなくなる可能性 |
ただし、案内には今回のPHP脆弱性への対応であるとは明記されていません。
同じ日に実施される緊急メンテナンスではありますが、両者の関係を断定することはできません。
php.iniで対策できるのか？
今回の問題に関連して、次のPHP設定が注目されています。
session.upload_progress.enabled = 0これはPHPのSession Upload Progress機能を無効化する設定です。
当初、GMO Flatt Securityは、この設定が脆弱性の緩和に役立つ可能性があるとしていました。
しかし、10月21日14時の追記では、この設定を無効化しても攻撃自体は回避できない見込みとの評価に変更しています。
つまり、設定を追加しても今回の脆弱性への完全な対策にはなりません。
私もConoHa WINGのphp.ini編集画面とuser.ini編集画面を確認しましたが、設定を追加する前に情報を再確認することにしました。
現時点では、上記の設定を安全性の保証として扱うことはできず、修正版PHPの適用が最も重要です。
WordPress運営者が今すぐ確認したいこと
ここまで確認した内容から、WordPressを運営している場合は、次の順番で対応するのが現実的だと考えます。
1. PHPのバージョンを確認する
WordPressのサイトヘルスで、実際に動いているPHPバージョンを確認します。
また、複数のWordPressサイトを運用している場合は、サイトごとに確認が必要です。
2. バックアップを確保する
PHPの修正版が公開された際に更新できるよう、事前にWordPressのファイルとデータベースをバックアップします。
バックアップファイルは、可能であればサーバー外にも保存してください。
3. WAFを確認する
レンタルサーバーのWAFが有効になっているか確認します。
ただし、WAFやWordfenceなどのセキュリティプラグインは、PHPそのものの脆弱性を修正するものではありません。
4. レンタルサーバー事業者の対応状況を確認する
共用レンタルサーバーでは、利用者がPHP本体を自由に更新できるとは限りません。
管理画面でPHPの系列を変更できても、その系列に含まれるパッチバージョンは事業者側が管理している場合があります。
そのため、公式の修正状況と、ホスティング事業者の対応状況を両方確認する必要があります。
5. 修正版の適用後に動作を確認する
修正版PHPへの更新後は、少なくとも次の機能を確認します。
- WordPressのトップページ、記事ページ
- 管理画面へのログインと投稿編集
- 画像アップロード
- お問い合わせフォーム
- 利用中の主要テーマ・プラグイン
もしPHPの更新によって不具合が発生した場合でも、脆弱なバージョンへ安易に戻すのではなく、互換性のある修正版やホスティング事業者の対応方針を確認してください。
まとめ：PHPを最新版にするだけでなく、修正済みかを確認する
2026年10月21日に予告されたPHPの重大な脆弱性は、WordPress利用者にとっても注意が必要な問題です。
今回の危険性は、WordPressのテーマやプラグインではなく、PHPの実行環境自体が攻撃対象になりうる点にあります。
私が管理する2環境では、以下の状況を確認しました。
| 項目 | XServer Business | ConoHa WING |
|---|---|---|
| 確認したPHP | 8.5.11 | 8.3.31 → 8.5.6 |
| 10月21日の状況 | 管理画面などを予防的に停止 | 緊急メンテナンスを告知 |
| WAF | 未確認 | ON |
| バックアップ | 取得済み | 別途確認が必要 |
| 今後の対応 | 事業者の修正対応を確認 | PHP修正版の提供状況を確認 |
現時点で重要なのは、PHPのバージョン番号が大きいことと、今回の脆弱性が修正されていることは同じではないという点です。
また、公開されている攻撃情報や緊急メンテナンスの案内だけで、自分のサイトが既に侵害されたと判断することもできません。
まずPHPの使用状況を把握し、バックアップを確保し、修正版が公開されたら速やかに適用する。
WordPress運営者としては、この順番で対応していくことが重要だと考えます。
本記事は、PHP公式のセキュリティリリース、およびXServer・ConoHa WINGの対応状況に応じて追記する予定です。
参考情報・一次情報
- PHP公式：News Archive 2026
- IPA：PHPのセキュリティリリース公開予定について
- piyolog：修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた
- GMO Flatt Security：PHPの重大な脆弱性「php2shell」の概要と対応指針
- PHP公式マニュアル：セッションのアップロード状況
- ConoHa WING：PHPの設定をする
※記載した技術的詳細の一部には、PHP開発元の正式な技術情報公開前の研究者・セキュリティ企業による報告が含まれています。
感謝
エンジニアの皆様，遅くまで対応いただきありがとうございます。
コメントはこちら