PHP脆弱性を狙う攻撃通信をCloudflareが観測｜WAFと調査範囲を点検する

Cloudflareは2026年10月21日、PHPの重大脆弱性CVE-2026-109618とCVE-2026-109619を狙う攻撃通信を顧客環境で観測し、防御を回避するためにペイロードを変形する動きも確認したと公表しました。同社はphp2shellと呼ばれるこの問題へのWAF保護を配備し、PHP本体の更新を並行して進めるよう求めています。

今回の新しい判断材料は、修正版の存在に加えて、攻撃試行の観測とWAF側の防御内容が明らかになったことです。本サイトの修正版公開時の記事では、確認したPHP公式資料から実環境での悪用状況を断定していませんでした。本稿では2026年10月22日に直接確認したCloudflare deploys protections against php2shell vulnerability（Cloudflare・2026年10月21日）を根拠に、WAFの適用確認と調査の進め方を追加します。

ただし、攻撃通信を観測したという発表から、顧客サイトでコード実行や情報流出が成功したとまでは読み取れません。観測された試行、WAFの処理結果、オリジンサーバーへの到達、侵害の成立を分けて記録してください。攻撃にAIが使われたという根拠も、この観測だけからは確認できません。

要求と応答を組み合わせる防御が加わった

Cloudflareは、無料・有料のWAF利用環境に対して、10月21日03:02 UTCから既定の保護を提供したと説明しています。日本時間では同日12:02です。これは同社の保護開始時刻であり、PHPの修正版公開時刻でも、各利用サイトでの更新完了時刻でもありません。

新しいfull transaction detectionは、同じHTTP取引の要求とオリジン応答の情報を組み合わせて判断します。一致した応答を要求元へ返す前に遮断できる仕組みです。要求だけでは正規通信と区別しにくいケースに、応答側の情報を加えるのが今回の特徴です。

ここで運営者が押さえたいのは、応答の遮断とサーバー側の処理停止は別だという点です。応答を検査する時点では、オリジンがすでに要求を処理している場合があります。出力を止められたとしても、その事実だけでコード実行や状態変更を巻き戻せるとは判断できません。WAFを有効にしたうえで、脆弱なPHPを更新する必要があります。

無料プランと有料プランで設定を確かめる

Cloudflareの今回の案内では、Freeの保護は自動配備され、有料のProfessional・Business・EnterpriseではManaged Rulesetの展開とBlockモードを確認するよう求めています。契約があることだけで判断せず、対象ドメインとアプリケーションへ実際に適用されているかを確認します。

Cloudflare Managed Rules公式資料によると、マネージドルールの動作は個別に変更でき、例外や上書きも設定できます。過去の誤検知対応でルールを無効化した、特定パスを除外した、ログ記録だけにした、といった変更が今回の保護と重なっていないかを調べてください。

本サイトの点検案は、まずドメインとルールセットの対応を記録し、次に適用範囲、動作、除外条件を順に確認する方法です。画面で保護が有効と表示されるだけでなく、変更履歴と実際のイベントを照合します。緊急対応中に変更した条件には担当者と見直し期限を付けます。

Cloudflare Create WAF exceptions公式資料は、例外により全ルール、特定ルールセット、個別ルールをスキップできると説明しています。また、アカウント階層とゾーン階層では影響する範囲が異なります。一つの例外を見つけて全体の状態を推定せず、組織共通設定とサイト別設定を両方調べる必要があります。

オリジンへの直通経路を残さない

CDNやWAFを通る公開URLが保護されていても、オリジンのIPアドレスや別ホスト名へ直接接続できるなら、同じ検査を通らない経路が残る可能性があります。これは今回の攻撃で直通が使われたと確認したという話ではなく、自社構成を点検する際の運用上の論点です。

Cloudflare Protect your origin server公式資料は、プロキシ対象のDNS設定、DNS-onlyのレコード、オリジンへの接続制御を確認する方法を示しています。Cloudflare Tunnel、Authenticated Origin Pulls、送信元の制限など、構成に応じた選択肢があります。IPを隠すことと、直通要求を拒否することは分けて検証します。

点検では、wwwの有無、旧ドメイン、API専用ドメイン、管理用ホスト、IPv4とIPv6、別ポートを一覧にします。ロードバランサーやホスティング事業者が発行した既定のURLも確認してください。通常の業務で必要な監視や連携まで切断しないよう、正規経路と例外の理由を整理してから制限します。

変更後は、許可された経路でページ、フォーム、APIが動くことと、許可していない直通経路で同じPHP処理へ到達できないことを確かめます。TLS証明書の設定だけ、Hostヘッダーの確認だけなど、一層の設定を全体の証明にしないことが大切です。設定例をそのまま転用せず、保守担当と自社のネットワーク境界を照合します。

WAFイベントを侵害件数として数えない

Cloudflare Security Events公式資料によると、Security Eventsはセキュリティ機能が処理した、またはフラグを付けたイベントを確認する画面です。すべての通信を一覧にするものではなく、一つのHTTP要求から複数のイベントが生じる場合もあります。画面の件数を、そのまま攻撃要求数や侵害件数に置き換えないでください。

さらにSampled logsではすべてのイベントが表示されるとは限りません。対象の時間帯、ホスト、パス、アクション、ルールIDを記録し、サンプリングや保持範囲も確認します。イベントが見当たらないときは、対象期間が違うのか、検査されていないのか、表示対象から外れているのかを切り分けます。

確認した事実	言えること	別途調べること
要求をWAFで遮断	その要求に遮断処理が働いた	別経路や別時刻の通信
応答を遮断	一致した応答の返送を止めた	オリジン側ですでに起きた処理
イベント表示なし	表示条件内で見つからなかった	対象範囲とサンプリングとログ欠損
PHPを更新	修正を適用する作業を実施した	全ワーカーの切り替えと過去の影響

この表は本サイトの調査整理案です。WAFの記録と、Webアクセス、PHP-FPM、Apache、プロセス、外向き通信、管理操作の記録を同じタイムゾーンへそろえます。時刻のずれやログ転送の遅延も残しておくと、前後関係を誤認しにくくなります。

メモリー漏えいも調査の範囲に含める

PHP公式 RCE via stale global state（CVE-2026-109619）は、認証不要のメモリー開示とWebワーカー権限でのRCEを確認済みの影響として挙げています。したがって、不審なPHPファイルが見つからないことだけを根拠に、影響がなかったと閉じることはできません。ファイルの改ざん確認と、処理中データへの影響評価を分けて進めます。

自社のPHPプロセスが扱う秘密を、用途と権限で棚卸ししてください。DB接続情報、外部APIの認証情報、メール送信用の資格情報、利用者のセッションなど、実際にプロセスから扱えるものを確認します。これは今回それらが流出したという断定ではなく、調査や失効判断で対象を見落とさないための準備です。

不審な応答や通信、プロセス、管理操作が確認された場合は、記録を保存して担当者へ引き継ぎます。新しい秘密を疑わしい環境へ先に入れると、交換後の安全性も説明しにくくなります。失効、隔離、環境の再構築、再設定の順序を、サービスの依存関係と影響に合わせて決めます。

更新作業と調査記録を同じ時系列へまとめる

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。PHP公式セキュリティ勧告と修正版の配布情報が示す修正を適用し、配布元のパッケージ情報と稼働ワーカーの切り替えを確認します。すでに更新した場合も、WAFが有効になった時刻、外部公開を制限した時刻、PHPを更新した時刻、全ワーカーを切り替えた時刻を別々に記録します。

例えば、一部のノードだけ先に更新し、残りを後で切り替えたなら、全体の完了時刻だけでなく各ノードの露出期間が必要です。オートスケールや待機系が古いイメージを使っていれば、作業後に未修正の環境が戻る可能性もあります。今回の記録には、稼働ノードだけでなく増設元と復旧用テンプレートを含めてください。

更新前のログを消してから調査を始めることがないよう、保持期限を先に確認します。証拠の採取と被害拡大の抑止は、状況に合わせて並行して進めます。クラッシュや異常がある場合も、本番へ攻撃コードを投入して確かめるのではなく、既存記録と構成を調査担当が評価します。

今回追加したい確認事項

• PHPの修正適用を進めながら、WAFのルールセット、Block動作、適用ホスト、例外を確認する
• 正規URL以外のオリジン直通、旧ホスト名、IPv6、別ポートを点検する
• 要求の遮断と応答の遮断を区別し、オリジン側の記録を同じ時刻で照合する
• メモリー開示の影響も踏まえ、プロセスが扱う認証情報とデータを棚卸しする
• 全ノードと増設元の更新を確認し、調査で未確定の点と次の判断担当を記録する

WAFの保護が追加されたことは、更新までの防御を厚くする材料です。同時に、攻撃通信の観測が公表された今は、設定したつもりの保護が実際の公開経路に効いているかを確かめる必要があります。侵害を決めつけず、検出がないことも過大評価せず、修正適用と根拠を残す調査を進めてください。

関連記事

• PHPが重大RCEの修正版を公開！8.5.12など4系統へ緊急更新（修正版公開時点の確認内容。CVE別の条件と暫定策の限界）
• WordPressの改ざんが疑われたときの初動対応（証拠保全と復旧判断の恒久対策ガイド）