PHP2Shellの対策は?対象バージョンとWordPress運営者の確認手順

PHP2Shellへの対応は、サイトを動かしているPHPの版と、その提供元が修正を適用したかを確認するところから始めます。WordPressを最新にしていても、PHP側の対応状況は別に確認が必要です。

2026年10月21日、PHP GroupはCVE-2026-109618とCVE-2026-109619の修正版を公開しました。本記事はPHP公式告知と公式リポジトリの情報を、2026年10月22日時点で確認して整理しています。

目次

最初に確認する対象と修正版

公式告知は、Webリクエストを処理するPHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどに注意を求めています。認証されていない相手からのリクエストにより、PHPの実行権限で任意のコードを実行されるおそれがあります。

使用系列PHPプロジェクトの修正版
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

修正版はCVE-2026-109618の公式アドバイザリとCVE-2026-109619の公式アドバイザリでも確認できます。旧系列やOSベンダーのパッケージは、表示される数字だけで判断せず、提供元の修正情報と照合してください。

Webで使うPHPを確認し、修正版または提供元の対応情報と照合する流れ。
PHPの表示バージョンと、提供元の修正情報を組み合わせて確認します。

WordPressでは「サイトヘルス」とサーバーの告知を確認

WordPress公式のサイトヘルスの説明では、「情報」の「サーバー」にPHPの情報が表示されます。管理画面の「ツール」→「サイトヘルス」→「情報」から対象項目を確認し、PHPバージョンを控えます。画面の名称は翻訳や構成によって異なる場合があります。

  1. 対象サイトのURL、確認したPHPバージョン、確認日時を記録する。
  2. 契約しているサーバーの障害・セキュリティ告知を開き、この2件のCVEへの対応状況を確認する。
  3. 自分でPHPを切り替えられる契約か、事業者による更新を待つ構成かを確認する。
  4. 不明なら対象サイトと利用プランを添えて、修正済みか、利用者側の操作が必要かを問い合わせる。

複数ドメインを運用している場合は、一つのサイトの結果を全サイトに当てはめないでください。同じ契約でも、サイトごとにPHPの設定や実行環境が違う可能性があります。設定画面の確認結果をサイト一覧に対応付けると、見落としを減らせます。

レンタルサーバーとVPSでは作業の担当が異なる

運用形態確認する相手・場所残す証拠
事業者管理のレンタルサーバー事業者の告知・管理画面・サポート対象プランの対応状況と確認日時
自分で管理するVPS・専用サーバーOSやパッケージの提供元、運用担当修正パッケージと稼働中の版
コンテナーで稼働イメージと稼働環境の管理担当更新イメージと入れ替え完了記録

バックポートとは、旧系列のパッケージに修正を取り込む対応です。上流PHPの修正版と数字が異なる場合でも、提供元のアドバイザリで修正済みと確認できることがあります。一方、端末で表示したPHPとWebサイトが使うPHPが同じとは限りません。実際にWeb処理に使われる環境まで確認してください。

更新は「変更前・適用・確認」の順に進める

以下は作業記録を残すための確認手順です。PHPの更新方法や再起動対象は構成によって違うため、契約サーバー・OS・コンテナーの公式手順に従ってください。

  1. 変更前:設定、利用版、主要プラグイン、復旧方法を確認する。バックアップの取得日時と戻し方も記録する。
  2. 適用:提供元が指定する修正版または修正パッケージへ更新する。必要なプロセス再起動やコンテナー入れ替えまで行う。
  3. 確認:Web側で稼働する版を再確認し、トップページ、管理画面、問い合わせ、アップロードなど利用中の主要機能を確認する。
  4. 記録:対象サイト、適用日時、担当者、適用した版、動作確認結果を残す。
変更前の記録、修正適用、必要な再起動、稼働版と主要機能の確認の順に進める。
適用ボタンを押した時点で終えず、実際に稼働している環境と主要機能を確認します。

機能に問題が出た場合、脆弱な旧版へ戻してそのまま運用するのではなく、影響する機能の制限や修正版の別系列への移行などを担当者と検討します。復旧後も修正が有効な状態を維持できるかを確認することが必要です。

WAFや一時設定の変更だけで完了にしない

PHP公式は、一時緩和は特定の攻撃経路への露出を減らすものであり、完全な解決は更新としています。設定例をそのままコピーすると、メモリ使用量やアップロード機能など運用面への影響もあり得ます。一般のサイト運営者はまず提供元の対策状況を確認し、独自の設定変更は管理担当者と判断してください。

侵害が疑われる場合はログを残す

JPCERTの注意喚起は、異常なCookie、リクエストとエラー、PHPワーカーの異常終了などを調査の手がかりとして示しています。ただし、痕跡が見当たらないだけで侵害がなかったとは断定できません。

不審なファイルや外部通信などを見つけたら、観測日時と状況を記録し、ログを保全したうえで運用担当やサーバー事業者へ連絡します。調査前に関連ファイルを一括削除すると、原因や影響範囲の確認が難しくなります。ログや診断情報には秘密情報が含まれることがあるため、公開掲示板へ貼り付けないでください。

よくある質問

WordPressの更新だけで対応は終わりますか?

PHPの修正状況まで確認してください。WordPress本体の更新と、サーバーのPHP更新は管理する場所や担当者が異なる場合があります。

PHP 8.1以前ならどうしますか?

PHPプロジェクトによる通常の更新対象外です。利用しているOSや長期サポート事業者の修正提供を確認し、対応がない場合はサポートされる系列への移行を進めます。

攻撃されたかを本記事だけで判定できますか?

できません。ここで扱う対象判定と更新確認は、侵害調査の代わりにはなりません。また、本記事が参照した資料だけからPHP2Shellの実攻撃を確認済みとは断定していません。

公式情報

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次