CloudflareはPHPの緊急脆弱性にどう対応したか｜修正版の公開前に無料プランまでWAFを配布。自社サイトが守られているかの確かめ方と、WAFでは足りないこと
仕様確認・更新日: · 編集: 株式会社ウェステリア
2026年10月21日のPHPの緊急修正では、サーバー会社や制作会社だけでなく、サイトの前に立つサービスも動きました。Cloudflareは、10月21日3時02分(協定世界時。日本時間12時02分)から、WAF(Webアプリケーションファイアウォール。不正な通信を遮る仕組み)の保護を、無料プランを含むすべてのプランに自動で配りました。PHP公式の修正版の公開は同日14時(協定世界時)で、Cloudflareはこれを「公開の約9時間前」と説明しています。この記事は、Cloudflareが何をいつ配ったか、どういう仕組みか、自社のサイトがその保護を受けているかを確かめる方法、そしてWAFがあっても更新が要る理由を、Cloudflare公式の発表をもとに整理したものです。2026年10月22日10時30分(日本時間)時点の情報です。
結論から
- Cloudflareは2026年10月21日3時02分(UTC)、PHPの2件の脆弱性(CVE-2026-109618・CVE-2026-109619)への保護を、WAFを使うすべてのプランに既定で配りました。無料プランも対象で、利用者の操作は不要です。有料プランは、マネージドルールセットが「ブロック」になっているかの確認を求めています
- 今回の保護は、リクエストだけでなくサーバーからの応答も見て判断する新機能「full transaction detection」を使った最初のマネージド検知です。応答が利用者に届く前に止められるため、誤検知を抑えつつ高い確度で遮れる、とCloudflareは説明しています
- Cloudflareは、WAFは多層防御の一層であり、PHPの更新が必要だと明記しています。攻撃者がペイロードを変えて回避を試みる動きも観測されています。Cloudflareの後ろにあるサイトでも、修正版への更新は必要です
Cloudflareが何をいつ配ったか(公式発表の要旨)
Cloudflareは2026年10月21日、公式ブログで「php2shell」(今回の2件の脆弱性に付いた通称)への対応を発表しました。要点は次のとおりです。
| 項目 | 内容(Cloudflare公式、2026年10月21日) |
|---|---|
| 配布の開始 | 2026年10月21日3時02分(UTC)。PHP公式の修正版公開は同日14時(UTC)。Cloudflareは「公開の約9時間前」と説明 |
| 対象 | WAFを使うすべてのプラン。無料プラン(Free)を含み、自動で有効。利用者の操作は不要 |
| 無料プランのルール | 「Cloudflare Managed Free Ruleset」の「Generic Rules - Anomalous Execution」1〜7(7件) |
| 有料プラン(Pro以上)のルール | 「Cloudflare Managed Ruleset」の同名7件(ルールIDは別)。マネージドルールセットがブロックモードになっているかを確認するよう案内 |
| 全プラン共通 | 「Cloudflare Managed Response Firewall Default」の「Default block for High confidence Signatures」(応答側の高信頼シグネチャをブロック) |
| 準備の経緯 | 10月初旬から保護の開発と展開を進めていたと説明 |
| 攻撃の観測 | 顧客を狙う攻撃トラフィックと、ペイロードを変えて回避を試みる動きを観測。件数や開始時刻は未記載 |
Cloudflareのドキュメントによると、無料プランで使える「Cloudflare Managed Free Ruleset」は、影響が大きく広く悪用されている脆弱性を対象にしたもので、すべてのプランで使えます。Pro以上の「Cloudflare Managed Ruleset」はより広い範囲を覆い、頻繁に更新されます。今回は、この両方に同じ7件が入りました。
出典: Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」(2026-10-21) / Cloudflare Docs「WAF Managed Rules」
仕組み: リクエストだけでなく、応答も見る
従来のWAFは、外から来るリクエストだけを検査して、攻撃らしいものを止めていました。ただ、今回のような脆弱性では、リクエストの中身だけでは攻撃と正常な通信を区別しきれない場合がある、とCloudflareは説明しています。そこで使われたのが、同じ日に一般提供が発表された「full transaction detection」です。
この機能は、リクエストと、それに対するサーバーの応答を、同じ1回の通信(トランザクション)として合わせて評価します。応答の側に「攻撃が成功した形跡」(たとえば本来出てはいけない情報の露出)があれば、その応答が利用者に届く前に止めます。php2shell向けの保護は、この仕組みを使った最初のマネージド検知だとされています。
利用者の側から見ると、こうなります。攻撃のリクエストがCloudflareを通ってサーバーに届いても、サーバーが返した応答に攻撃成功の兆候があれば、その応答は外に出ません。リクエスト側の7件のルールと、応答側の1件のルールの二段構えです。ただし、サーバー側でコードが実行されてしまう可能性そのものを無くす仕組みではないので、更新の代わりにはなりません(次の節)。
出典: Cloudflare Blog「Introducing full transaction detection for Cloudflare WAF」(2026-10-21) / Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」(2026-10-21)
WAFがあっても、PHPの更新は必要
Cloudflare自身が、今回の発表の中でそう書いています。要点は4つです。
- WAFは多層防御の一層であり、PHPのランタイム(PHP本体)を修正版に更新することが必要
- WordPressなどサイト側のコードやプラグインを更新しても、PHP本体の脆弱性は直らない。サーバー会社がPHPを管理している場合は、サーバー会社に更新を依頼する
- 更新が終わるまで、WAFの保護は有効のままにしておく
- アップロードの制限やリクエストサイズの上限は露出を減らす補助策だが、PHPの修正の代わりにはならない
もう1つ、Cloudflareは「攻撃者がペイロードを変えて回避を試みる動きを観測し、ルールを追跡・更新している」と書いています。WAFのルールと攻撃は追いかけっこになるので、ルールがある状態を「安全になった」と受け取らないでください。PHP本体の修正版(8.5.12・8.4.27・8.3.36・8.2.35)への更新の手順は、当社のPHPの解説にまとめています。
出典: Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」(2026-10-21) / PHP「Security advisory: Critical remote code execution vulnerabilities, update now」(2026-10-21) / 当社の解説「PHPの緊急脆弱性(2026年10月21日)」
自社のサイトが保護されているかの確かめ方
「うちのサイトはCloudflareの後ろにあるのか」「保護は効いているのか」を、順に確かめます。
- Cloudflareを使っているか: サイトのドメインのDNS(名前の管理)がCloudflareに向いているかを、制作会社かサーバー会社に聞く。自社でドメインを管理しているなら、ネームサーバーが「*.ns.cloudflare.com」になっていればCloudflare経由。ただし、DNSだけ使っていて通信を通していない(プロキシが「DNSのみ」)場合は、WAFは効かない
- プラン: 無料プランでも今回の保護は入っている。有料プラン(Pro以上)は、ダッシュボードの「Security」で「Cloudflare Managed Ruleset」が有効で、アクションがブロックになっているかを確認する
- ブロックの記録: ダッシュボードの「Security > Security Analytics > Events」で、今回のルールID(Cloudflareの発表に記載)で絞ると、ブロックされたリクエストが見られる。記録があれば、攻撃が実際に来ていたことになる
- PHPの更新: 上の確認が全部「できている」でも、PHP本体の更新は別途必要。サーバー会社の告知か管理画面で、修正版に上がっているかを見る
Cloudflareのプランは、無料(0ドル)、Pro(月20ドル・年払い、月払いは25ドル)、Business(月200ドル・年払い、月払いは250ドル)、Contract(要問い合わせ)です(2026年10月22日に公式の料金ページで確認)。今回の保護は無料プランにも入ったので、「Cloudflareを通しているだけ」のサイトも対象でした。
出典: Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」(2026-10-21) / Cloudflare「Network & CDN pricing」(2026-10-22に確認)
今回の対応から、発注側が持ち帰れること
今回の件で分かったのは、サイトの前に立つサービスがあると、自社が何もしていない時間帯にも一層の守りが入る、ということです。23時の公開から翌朝の更新作業までの間、サーバー会社の修正を待つ間、制作会社と連絡が取れない間。その「間」を埋めるのがWAFの役割で、今回は修正版の公開前から効いていました。
一方で、WAFがあることで更新を後回しにしてよい理由にはなりません。Cloudflareが自ら「更新してください」と書いているとおりです。発注側として決めておくとよいのは次の2つです。自社のサイトの前にWAFがあるかを把握しておくこと。そして、WAFがあってもなくても、PHPやNode.jsのような基盤の更新を「誰がいつやるか」を決めておくことです。
自社のサイトをCloudflareの後ろに置く作業(DNSの移管、プロキシの設定、WAFの確認、Cloudflare Oneでの社内システムへの接続)の手順と費用の考え方は、当社の解説「Cloudflare導入支援」(この節の出典)にまとめました。
出典: Cloudflare Blog「Cloudflare deploys protections against php2shell vulnerability」(2026-10-21) / 当社の解説「Cloudflare導入支援｜自社サイトをCloudflareの後ろに置く」
この記事の更新履歴
Cloudflareがルールの説明文やブロック件数を公開したとき、他のCDN・WAF事業者の対応を公式の発表で確認できたときに追記します。
- 2026年10月22日10時30分: 初版を公開
よくあるご質問
- Cloudflareの無料プランでも、今回のPHPの脆弱性から守られますか
- Cloudflare公式は、WAFを使うすべてのプラン(無料を含む)に今回の保護を自動で配ったと発表しています。ただし、DNSだけ使っていて通信をCloudflare経由にしていない場合は効きません。また、WAFは一層の守りであって、PHP本体の修正版への更新は別途必要です。
- Cloudflareの後ろにあるサイトなら、PHPの更新は急がなくてよいですか
- いいえ。Cloudflare自身が、WAFは多層防御の一層であり、PHPのランタイムを更新する必要があると明記しています。攻撃者がペイロードを変えて回避を試みる動きも観測されています。更新が終わるまでWAFを有効にしておき、更新は進めてください。
- full transaction detectionとは何ですか
- Cloudflareが2026年10月21日に一般提供を発表したWAFの新機能で、リクエストと、それに対するサーバーの応答を同じ通信として合わせて評価します。応答に攻撃成功の形跡があれば、利用者に届く前に止めます。今回のphp2shell向けの保護は、この機能を使った最初のマネージド検知です。全プランで利用でき、カスタムの応答ルールは3件まで作れます(公式発表)。
- 自社のサイトがCloudflareを使っているか分かりません
- 制作会社かサーバー会社に「ドメインのDNSはCloudflareですか。通信はCloudflare経由(プロキシ有効)ですか」と聞くのが確実です。自社でドメインを管理しているなら、ネームサーバーが「*.ns.cloudflare.com」かどうかで分かります。分からない場合は、当社の相談窓口に状況を送ってください。