PHP2Shell とは — PHP本体を揺るがす重大なメモリ安全性の脆弱性
「PHP2Shell」は、WordPress の脆弱性ではなく、その土台であるPHPエンジン（言語ランタイム）本体に見つかった、
複数のメモリ安全性の脆弱性の総称です。アプリ側のコードが安全でも、脆弱なPHPで動いているだけで影響を受ける点が特徴で、
未認証のリモートコード実行（RCE）やプロセスメモリの漏えいにつながります。全Webサイトの約70%がPHPで動いているとされ、影響範囲は極めて広大です。
結論を先に：サーバーのPHP本体を修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上）へ更新し、
PHP-FPM／Webサーバーを再起動してください。WordPress本体やプラグインをいくら更新しても、PHPが古いままでは塞がりません。
これまでの脆弱性との位置づけの違い：
WP2Shell・XSS2Shell はWordPress本体の脆弱性でした。一方 PHP2Shell はPHPランタイム本体の問題で、
WordPress・Drupal・Joomla・Magento・Laravel など、PHPで動くあらゆるアプリが対象になり得ます。
WordPressは「PHPの上で動いているため巻き込まれる」側であり、対策の起点もPHPのバージョンになります。
1. PHP2Shell の概要
2026年10月21日、Wiz Research が OpenAI・Calif・PHPセキュリティチームと協調して「PHP2Shell」を公表しました。
CVE-2026-109618 と CVE-2026-109619 の2件にまとめられており、いずれも CVSS v4.0 で 9.2（Critical）と評価されています。
なお公表の直前、10月20日に情報が先行してリークされ、PHPチームが前倒しで注意喚起と修正版リリースを行う展開となりました。
これらはすべて、PHPがリクエスト処理中に致命的エラー（特にメモリ不足＝Out-of-Memory）に遭遇したときの状態管理に起因するメモリ安全性のバグです。
リクエストが予期せず終了すると、PHP内部に壊れた状態（解放済みメモリを指すポインタ等）が残り、
同じワーカープロセスが処理する後続のリクエストがそれを再利用してしまうことで、メモリの漏えいや破壊が発生します。
特筆すべきは、これらの脆弱なコードが10年以上前（PHP 5.4 の頃）から存在していたにもかかわらず、
悪用の実証（エクスプロイト化）が極めて複雑なために見過ごされてきた点です。研究チームは、
フロンティアAIモデルを活用することで、この「複雑さの壁」を越えて実際に動作するエクスプロイトを短期間で構築したと説明しています。
Heartbleed（2014年）や Log4Shell（2021年）になぞらえ、「AI時代の転換点」と位置づけられています。
2. どのような攻撃なのか（仕組み）
PHP2Shell は、2つのCVEの下に少なくとも4種類の悪用可能なバグがまとめられています。
共通する根本原因は「致命的エラーでリクエストが中断された際に、本来破棄されるべき内部状態が残り、
次のリクエストやワーカーがそれをクロスリクエストで再利用してしまう」ことです。
主なバグと到達できる被害
| CVE | バグの種類 | 攻撃者ができること（実証済み） |
|---|---|---|
| CVE-2026-109618 | アップロード進捗処理の unserializer における use-after-free／リモートのプロセスメモリ漏えい | WordPress・Drupal・Joomla に対する未認証RCE／アプリ非依存のメモリ漏えい |
| CVE-2026-109619 | 致命的エラーのバックトレースにおける use-after-free／OPcache の型混同（type confusion） | Drupal・WordPress に対する未認証RCE／共有PHP状態の破壊によるコード実行 |
代表的な攻撃経路の例
- メモリ漏えい（Heartbleed型） ― PHPはマルチパート（ファイルアップロード）リクエストをリクエスト開始の非常に早い段階で解析する。
ここでメモリ不足エラーを誘発すると、解放済みメモリを指したままのセッションID等が残り、後続のマルチパートリクエストで
その解放済みメモリの中身がPHPSESSIDクッキーにURLエンコードされて返されてしまう。
アプリがsession_start()を一度も呼んでいなくても成立するため、アプリ非依存。パスワード・トークン・APIキー・証明書などが漏れる恐れがある。 - use-after-free によるメモリ破壊 → RCE ― 解放済みの内部状態を、攻撃者が別のデータで「埋め戻す」ことで、
PHPにそれを正当なデータとして扱わせ、メモリ破壊を制御可能な形に発展させて最終的にコード実行へ至る。 - OPcache の型混同 ― コンパイル済みコードを共有メモリにキャッシュする OPcache の、永続化処理の途中でメモリ不足が起きると、
ワーカー間で参照のズレが生じ、別の型のオブジェクトとして解決されてしまう。これを悪用してWordPressへの未認証RCEチェーンが構築された。
重要：攻撃はアプリ層より下で起きる ― これらはPHPエンジン内部の問題であるため、
WordPressなどアプリ側のログにはほとんど痕跡が残りません。「アプリのコードが堅牢かどうか」は関係なく、
極端に言えば「Hello World」だけのPHPアプリでも、脆弱なPHPで動いていれば危険です。
3. 影響を受けるバージョンと修正版
研究チームによると、PHP 5.4 以降、過去10年に出たほぼ全てのPHPバージョンが、いずれかの脆弱性の影響を受けます。
修正は現在サポート中の4ブランチに提供され、サポート終了（EOL）ブランチには提供されません。
| PHPブランチ | 修正版 | 対応状況 |
|---|---|---|
| 8.5 系 | 8.5.12 以上 | 修正あり |
| 8.4 系 | 8.4.27 以上 | 修正あり |
| 8.3 系 | 8.3.36 以上 | 修正あり（セキュリティ修正のみ提供） |
| 8.2 系 | 8.2.35 以上 | 修正あり（セキュリティ修正のみ提供） |
| 8.1 / 8.0 / 7.x / 5.x | 公式の修正なし | EOL（サポート終了）。サポート中ブランチへの移行が唯一の恒久対策 |
※ Linuxディストリビューションやレンタルサーバーによっては、7.4 / 8.0 / 8.1 などへバックポート修正パッケージが提供される場合があります。
利用中のOS・ホスティング事業者の告知も併せて確認してください。
4. 対応策
根本対策：PHP本体を修正版へ更新する
PHPチームは「更新だけが唯一の安全な選択」としています。回避策（ワークアラウンド）は一部の攻撃経路しか塞がないためです。
サポート中のブランチを上記の修正版へ更新し、PHP-FPM またはWebサーバー（Apache／Nginx等）を再起動して新しいビルドを読み込ませてください。
インターネットに公開されているサーバーから優先的に対応します。
WordPressを複数運用している方へ：
対策の対象は「WordPressのバージョン」ではなく「サーバーのPHPバージョン」です。
各サイトがどのPHPで動いているか（共用サーバーのPHP設定、VPSのパッケージ、cPanel／Plesk等のコントロールパネル設定）を棚卸しし、
全環境で修正版になっているか確認してください。WordPress本体の更新（WP2Shell / XSS2Shell対策）とは別に、両方必要です。
すぐ更新できない場合
- 公開ネットワークから隔離する ― CERT-EUは、すぐにパッチを当てられない公開アプリは、
修正までVPNやWAFの背後に置く／公開を止めることを推奨。 - CDN／WAFの保護を利用する ― Cloudflare・Fastly・Akamai・Imperva などが、更新までの一時的な緩和ルールを提供している。ただし更新の代替にはならない。
- EOLのPHPは移行一択 ― 8.1以前など公式修正が出ないバージョンは、サポート中ブランチへ移行する以外に恒久的な解決策はない。
侵害の検知
攻撃はアプリ層より下で起きるため、検知は侵入後のふるまい（ポストエクスプロイト）に注目します。
php-fpm／php-cgi／httpd／apache2が、シェルやスクリプトインタプリタ、curl・wget等のダウンロードツールを起動したら警告する。- 異常なマルチパートリクエストの直後に、メモリ上限エラーや HTTP 500 が繰り返し発生していないか。
- 予想外に大きい、あるいは不正な形式の
PHPSESSIDレスポンスクッキーが返っていないか。 - PHPワーカープロセスの不自然な再起動・増減（worker churn）がないか。
- アラートが出たら、サーバーを隔離し、Web／PHPのログを保全。Webルートの新規ファイル、Webシェル、不審なcron／スケジュールタスク、見覚えのないアカウントを調査する。
悪用状況について（2026年10月時点）：
報道・調査会社の間で見解が分かれています。CISAのKEVカタログには未登載で、PHP公式は実環境での悪用を報告していません。
一方で watchTowr は honeypot での観測を主張、Patchstack も複数の悪用を確認したとしています（技術的証拠は未公開）。
修正版の公開によりバグの箇所が明らかになるため、公開後は短時間で悪用が始まる可能性があり、早急な更新が強く推奨されます。
5. まとめ
- PHP2Shell（CVE-2026-109618 / CVE-2026-109619、各CVSS 9.2）は、WordPressではなくPHPエンジン本体のメモリ安全性の脆弱性。
- 根本原因は、致命的エラー（メモリ不足）でリクエストが中断した際に壊れた内部状態が残り、後続リクエストが再利用してしまうこと。
- 未認証のリモートコード実行（RCE）や、Heartbleed型のプロセスメモリ漏えい（パスワード・トークン・APIキー等）につながる。
- 影響は PHP 5.4 以降のほぼ全バージョン。WordPress・Drupal・Joomla など、PHPで動くあらゆるアプリが対象になり得る。
- アプリ側のコードが安全でも関係なく、脆弱なPHPで動いているだけで危険。アプリ層にログが残りにくい点にも注意。
- 根本対策はPHP本体を 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以上へ更新し、PHP-FPM／Webサーバーを再起動すること。EOLのPHPはサポート中ブランチへ移行する。
- WordPress運用者は「どのPHPで動いているか」を全環境で棚卸しして更新を確認。WP2Shell / XSS2Shell（WordPress本体の更新）とは別件のため、両方の対応が必要。