2026年10月21日、PHPに存在する2件の重大な脆弱性に対する緊急のセキュリティリリースが公開されました。通称「PHP2Shell」です。ニュースやSNSで目にした方も多いと思います。
この脆弱性は、WordPressのプラグインやテーマではなく、サイトを動かしている土台のPHPそのものにあります。そのため、WordPressや各プラグインを最新にしていても、それだけでは解消されません。
この記事では、WordPressの制作・保守に携わる立場から、何が起きたのか、何を確認すればよいのかを整理します。
何が起きたのか
- 10月21日（日本時間23時）：PHPの開発チームが緊急のセキュリティリリースを公開。事前に告知があり、公開前から多くのサービスがメンテナンスに入った
- 対象のCVE：CVE-2026-109618（メモリ不足時のエラー処理に起因）とCVE-2026-109619（リクエスト処理に関連）
- 深刻度：いずれもCVSS 4.0で9.2（Critical）
- 想定される影響：外部の第三者が、ログインなしでサーバー上の任意のコードを実行できてしまう可能性（リモートコード実行）
2件を組み合わせた攻撃が「PHP2Shell」と呼ばれています。
修正されたバージョン
IPA（情報処理推進機構）の注意喚起によると、次のバージョンより前のものが影響を受けます。
| PHPの系列 | 修正版 |
|---|---|
| 8.5系 | 8.5.12 |
| 8.4系 | 8.4.27 |
| 8.3系 | 8.3.36 |
| 8.2系 | 8.2.35 |
注意したいのは、サポートが終了している8.1以前です。これらには、PHPプロジェクトからの公式な修正版が出ていません。IPAによれば、調査に関わったWiz社は、PHP 5.4以降のバージョンが少なくとも片方の脆弱性の影響を受けると説明しています。古いPHPのまま動いているサイトは、特に注意が必要です。
また、開発元は、完全な回避策はなく、PHPの更新が唯一の確実な対策だと案内しています。ネット上では「Session Upload Progressを無効にすればよい」という暫定策も出回りましたが、それだけでは対策にならないことが、その後の調査で分かっています。
実際に悪用されているのか
時系列で見ると、状況は次のように進みました。
- 修正版の公開前から、攻撃を試みるアクセスが観測されていた。ただし当初は、動作しない攻撃コードによるものがほとんどだった
- 10月24日、研究者のおとり用サーバーで、実際にコマンドが実行された例が報告された。Apacheのmod_php環境で、35件の実行が確認されている
- 10月26日、米国のCISAが、悪用が確認された脆弱性として掲載するKEVカタログに2件を追加した
一方、IPAは10月27日の更新で、国内での攻撃被害の事例は把握していないとしています。ただし、これは「すでに安全」という意味ではありません。
なお、カナダのサイバーセキュリティ機関は、リスクが最も高いのはmod_php構成だと整理しています。認証なしのリクエストだけで、アプリケーションのコードが動く前に脆弱性を突ける実証があるためです。
制作・保守担当者が確認すること
1. サイトが動いているサーバーの種類を把握する
対応の担当が誰になるかは、サーバーの種類で変わります。
- 共用型のレンタルサーバー：PHPの更新は事業者が行う。たとえばエックスサーバーは、利用者が設定したPHPのバージョンを変えずに修正パッチを当て、8.2〜8.5は同じ系列の修正版へ更新したと案内している。ほかの事業者も、お知らせを確認する
- VPS・クラウド・自社サーバー：PHPの管理は利用者自身の責任。エックスサーバーのVPSも、事業者側ではPHPへのパッチ適用をしておらず、利用者が対応する必要がある
- FTP権限しかない案件：サーバー側の作業はできないため、先方のシステム担当者や、契約しているサーバー会社に、対応状況の確認を依頼する
2. PHPのバージョンを確認する
WordPressでは、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、使用中のPHPのバージョンを確認できます。phpinfoのファイルを設置して確認する方法もありますが、確認後は必ず削除してください。
ただし、バージョン番号だけで安全かどうかを判断できないことがあります。レンタルサーバーやLinuxのディストリビューションでは、バージョン番号を変えずに修正だけを取り込む（バックポート）対応があるためです。「8.3.30だから古い」と決めつけず、事業者の告知とあわせて判断してください。
3. 8.1以前は移行を計画する
公式の修正が出ないバージョンは、事業者の独自対応に頼ることになります。これを機に、8.3以上への移行を計画しましょう。移行時は、次の点を確認します。
- 使用中のテーマ・プラグインがPHP 8.3に対応しているか
- ステージング環境で、WP_DEBUGを有効にして警告を確認する（本番では画面に表示しない）
- 問い合わせフォームなど、主要な機能の動作確認
- 切り替え前のバックアップ
PHP 8.1以降では、nullを引数に渡したときのDeprecated警告など、7.4から8.xへ上げる際に出やすい問題があります。早めに洗い出しておくと安心です。
4. 侵害の有無を確認する
修正が当たるまでの間に侵入されていないか、念のため確認します。報告されている攻撃の例では、リクエストはアプリケーションのコードが動く前の段階で処理されます。そのため、WordPressの管理画面には痕跡が出ないこともあります。次のような点を見てください。
- 身に覚えのない管理者ユーザーが追加されていないか
- wp-content/uploads内に、PHPファイルが置かれていないか
- テーマ・プラグイン・コアのファイルが、不審なタイミングで更新されていないか
- アクセスログに、User-Agentのない不審なPOSTリクエストが連続していないか（公開されている観測例による）
ログや深い部分の調査が必要な場合は、サーバー側の権限が必要です。権限がない案件では、確認すべき観点を整理して、先方の担当者に依頼するとスムーズです。
WAFなどによる暫定対策
Cloudflare、Palo Alto Networks、Akamaiなどが、攻撃の通信を遮断する仮想パッチのルールを提供しています。修正版への更新が間に合わない場合の時間稼ぎにはなりますが、根本的な解決はPHPの更新です。あくまで補助的な対策と考えてください。
7月のwp2shellとの違い
7月には、WordPress本体の脆弱性「wp2shell」が話題になりました。名前が似ていますが、別のものです。
- wp2shell：WordPress本体の脆弱性。WordPressの更新で解消する
- PHP2Shell：PHPの脆弱性。WordPressを更新しても解消せず、PHPの更新が必要
クライアントに説明するときは、「どこを更新すれば直るのか」を明確に伝えると、混乱を避けられます。
まとめ
- PHP2Shellは、PHP本体にあるCVSS 9.2の脆弱性で、WordPressの更新だけでは直らない
- 修正版は、8.5.12・8.4.27・8.3.36・8.2.35。8.1以前には公式の修正がない
- すでに悪用が確認されており、CISAのKEVカタログにも掲載された
- まず、担当するサイトのサーバー種別とPHPのバージョンを棚卸しする
- 共用型のレンタルサーバーは事業者の対応状況を確認し、VPSや自社サーバーは自分で更新する
- 古いPHPのサイトは、移行を計画する
公開から攻撃の確認までの期間が短くなっている今、「次の定期メンテナンスでまとめて更新する」という運用では間に合わない場面が出てきます。担当サイトのPHPのバージョンを、日ごろから把握しておくことが、いちばんの備えになります。
