2026年10月21日、PHP本体に存在する2件の重大な脆弱性、CVE-2026-109618とCVE-2026-109619の修正版が公開されました。通称「PHP2Shell」です。

どちらも、条件が揃うと認証なしでリモートコード実行（RCE）につながる可能性があります。

WordPressやEC-CUBEなど、PHPで動くWebサイトを管理している場合は、早急な確認が必要です。

ただし、対応にあたって注意したい点があります。

WordPress本体やプラグインを更新しても、PHPの脆弱性が修正されるわけではありません。

今回の問題は、アプリケーションの下で動くPHP本体にあります。

この記事では、PHP2Shellへの対応を次の順番で整理します。

稼働中のPHPを特定する
修正プログラムの適用状況を確認する
更新後の動作を確認する
アクセスログとエラーログを確認する
更新が難しい場合の暫定対策を検討する
WAFによる検知の範囲と限界を理解する

1. まず、どのPHPが動いているのか確認する

最初に確認するのは、サーバー上にインストールされているPHPではなく、実際にWebリクエストを処理しているPHPです。

Linuxサーバーでは、次のコマンドでPHPのバージョンを確認できます。

php -v

ただし、これはコマンドライン版（CLI）の情報です。

Apacheのmod_php、PHP-FPM、Dockerコンテナなどを使用している場合、CLIとWebサーバー側で異なるPHPが動いていることがあります。

そのため、実際の構成に合わせて確認する必要があります。

PHP-FPM：稼働中のFPMサービスやプール、使用するPHPバイナリを確認する
Docker：PHPを実行しているコンテナのイメージとバージョンを確認する
WordPress：管理画面の「ツール → サイトヘルス → 情報 → サーバー」でPHPの情報を確認する
共用レンタルサーバー：ホスティング事業者の管理画面とセキュリティ告知を確認する

Docker環境であれば、対象のPHPコンテナ内で次のように確認できます。

docker exec <PHPコンテナ名> php -v

これもコンテナ内のCLIバージョンを示すため、実際のWeb処理系との対応を確認してください。

2. 修正済みバージョンを確認する

PHP公式が2026年10月21日に公開した修正版は以下のとおりです。

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

これらは今回の2件の脆弱性に対する修正版です。

ただし、Linuxディストリビューションやホスティング事業者がセキュリティ修正をバックポートしている場合、表示上のバージョン番号だけでは判断できません。

その場合は、パッケージの更新履歴やベンダーのセキュリティアドバイザリで、CVE-2026-109618とCVE-2026-109619への対応状況を確認してください。

PHP 8.1以前のサポート終了系統を使用している場合は、個別のバックポートの有無を確認するとともに、サポート中のPHPへの移行を計画する必要があります。

3. PHPの更新後に確認すること

PHPを更新したら、それで作業完了とは限りません。

稼働中のPHPワーカーが古いまま残っていないか確認し、利用しているWebサーバーやPHP-FPMの構成に応じて、必要な再起動・再生成を行います。

Dockerの場合は、修正版を含むイメージへの更新とコンテナの再作成が必要になることがあります。

その後、最低限、次の動作を確認します。

WordPressのトップページと記事ページが表示できるか
管理画面にログインできるか
お問い合わせフォームが送信できるか
画像・ファイルのアップロードが正常に動作するか
PHPエラーログに新しい異常が出ていないか

更新前にバックアップと復旧手順を用意しておくことも重要です。

4. ログを確認する

修正プログラムの適用と並行して、WebサーバーやPHPのログを確認します。

特に、普段と異なるリクエストやエラーがないかを見ておきます。

確認する対象は、例えば次のとおりです。

短時間に集中している不自然なPOSTリクエスト
通常の利用パターンから外れたmultipart/form-dataリクエスト
PHPのメモリ不足や異常終了に関するエラー
Webサーバーの5xx応答やPHPワーカーの予期しない再起動
既存のWAFが記録した不審なアクセス

もちろん、これらが見つかっただけでPHP2Shellの悪用が成功したとは判断できません。

逆に、異常なログが見つからなくても、攻撃を受けていない証明にはなりません。

ログ確認は侵害調査の入口であって、脆弱性の有無を判定する方法ではない、という点は押さえておきたいところです。

侵害が疑われる場合は、ログの保全に加え、不審なファイル変更やプロセス、外部通信なども調査対象になります。

5. すぐにPHPを更新できない場合

共用レンタルサーバーや古い業務システムでは、PHPをすぐに更新できない場合があります。

その場合でも、更新を待つ間に取り得る対策はあります。

ホスティング事業者に修正状況と適用予定を確認する
不要な公開エンドポイントや機能を一時的に制限する
HTTPリクエストのサイズや形式について、必要な制限を検討する
利用環境に応じてPHP公式アドバイザリに記載された暫定対策を評価する
WAFによるアクセス監視や既知の攻撃パターンの制御を追加する

いずれも環境に応じた検証が必要です。

特にファイルアップロードを利用しているサイトでは、広範囲にmultipartリクエストを拒否すると、正常な投稿やフォームまで影響を受ける可能性があります。

PHP公式は、今回の脆弱性に完全な代替緩和策はないと明記しています。更新できない期間の対策と、脆弱性の修正は分けて考える必要があります。

6. WAFでは何を検知できるのか

WAF（Web Application Firewall）は、Webアプリケーションに届くHTTP/HTTPS通信を監視・制御する仕組みです。

今回のPHP2Shellに対しても、既知の攻撃手法に関連するリクエストの特徴を検知できる場合があります。

例えば、セルフホスト型WAFのSafeLineでは、PHP2Shellに関連する一部の既知のリクエストパターンについて、カスタムルールが公開されています。

このルールでは、PHP_SESSION_UPLOAD_PROGRESSなどのパラメータや、multipart/form-dataの特徴を利用します。

また、SafeLine 9.4.3以降では、DenyルールをMonitor Modeで動作させることができます。

Monitor Modeでは、条件に一致したリクエストを攻撃イベントとして記録しますが、そのリクエストをブロックしません。

まず通常の通信に影響がないかを確認し、その後の制御方針を判断するための機能です。

注意したいのは、このカスタムルールがPHP2Shellのすべての攻撃経路をカバーするものではないという点です。

WAFにはPHPプロセス内部のメモリ状態は見えません。あくまでHTTPリクエスト上に現れる特定の特徴を監視しています。

SafeLineのルール条件、設定画面、JSON設定例は以下で公開されています。

SafeLine：PHP Core RCEへの対応と検知ルール

まとめ

PHP2Shell対応で優先したいのは、以下の順番です。

実際に稼働しているPHPのバージョンと構成を把握する
修正済みのPHP、または対応済みのベンダーパッケージを適用する
PHPワーカーを更新し、アプリケーションの動作を確認する
ログを確認し、必要に応じて侵害の有無を調査する
更新までの暫定対策として、アクセス制限やWAFを検討する

WAFは有用な追加防御ですが、PHP本体の修正を代替するものではありません。

特に今回のように、アプリケーションより下のレイヤーで発生する脆弱性では、この違いを理解しておくことが重要です。

参考資料

*本記事は、SafeLineを提供するCyberServalチームが公開情報をもとに整理したものです。特定の環境での攻撃再現や検知結果を示すものではありません。