2026.10.24

Cloudflare無料WAFでできること：PHP脆弱性対策【2026年版】

claude

Cloudflare の無料プランでサイトを公開していると、「無料の WAF でどこまで守られているのか」は気になるところです。

2026年10月21日、PHP 本体の重大な脆弱性「php2shell」（CVE-2026-109618 / CVE-2026-109619）が公開されました。Cloudflare は同じ日に、無料プランを含む WAF の利用者を、設定不要で自動的に保護したと発表しています。

あわせて、リクエストだけでなくオリジン（自分のサーバー）が返したレスポンスも見て攻撃を止める「レスポンスルール」を、無料プランを含む全プランに提供しました。

Introducing full transaction detection for Cloudflare WAF

この記事では、無料プランの WAF で使える機能と有料プランとの違い、今回の php2shell で何が自動で入ったのか、そしてWAF だけでは防げない点を整理します。無料 WAF は「入れておけば安心」ではなく、PHP の更新までの時間を稼ぐ防御の1枚——という位置づけです。

この記事はこんな人向けです

WordPress などの PHP で動くサイトを、Cloudflare の無料プラン経由で公開している
無料プランの WAF で何が守られ、何が守られないのかを知りたい
2026年10月の PHP 脆弱性「php2shell」に対して、Cloudflare 側で確認すべきことを知りたい

Cloudflareの無料WAFとは？一言でまとめると
無料プランと有料プランの違い：使えるルールの数
2026年10月の動き：PHPの脆弱性「php2shell」を無料でも自動で防御
新機能「レスポンスルール」とは？攻撃の結果を見て止める
無料プランで確認・設定したい4つのこと
WAFだけでは防げないこと：PHPの更新は必須
有料プラン（Pro）を検討したいケース
開発者の反応
よくある質問
まとめ

Cloudflareの無料WAFとは？一言でまとめると

Cloudflare の WAF（Web アプリケーションファイアウォール）は、サイトへの通信を Cloudflare のネットワーク上で検査し、攻撃とみられるものを止める仕組みです。無料プランでも、Cloudflare が用意したルールと、自分で作るルールの両方が使えます。

項目	無料プランの内容
マネージドルール	Free Managed Ruleset（影響が大きく、広く悪用される脆弱性が対象）
カスタムルール	5つまで（正規表現は使えない）
レート制限ルール	1つまで（パス単位・IP ごとに 10 秒で判定）
レスポンスルール	2026年10月から利用可。マネージドの既定ルールセット＋カスタム3つまで
ログの確認	Security Events（サンプリングされたログのみ）
料金	$0/月

※ 2026年10月24日時点（Cloudflare の公式ドキュメント・ブログ・料金ページ）。

前提として、WAF が働くのは Cloudflare を経由（プロキシ）している通信だけです。DNS だけを Cloudflare に置き、通信を経由させていない設定では WAF は働きません（後述）。

無料プランと有料プランの違い：使えるルールの数

有料プランとの違いは、主にルールの数・使える条件・ログの詳しさです。公式ドキュメントで確認できた範囲で比べます。

項目	Free	Pro	Business
月額（年払い）	$0	$20	$200
月額（月払い）	$0	$25	$250
マネージドルール	Free Managed Ruleset のみ	Cloudflare Managed Ruleset・OWASP Core Ruleset も	Pro と同じ
カスタムルール	5	20	100
正規表現	不可	不可	可
レート制限ルール	1	2	5
Security Events	サンプリングのみ	利用可	利用可（アラートも）

※ 2026年10月24日時点、料金は米ドル表記（Cloudflare の料金ページ・WAF ドキュメント）。

無料プランの大きな制約は、マネージドルールが Free Managed Ruleset に限られることです。有料プランの Cloudflare Managed Ruleset や OWASP Core Ruleset は、より幅広い攻撃パターンを対象にしています。

カスタムルールのアクションは、Free〜Business では「Log（記録のみ）」以外が使えます。つまり、無料プランでもブロックやチャレンジ（確認画面）は設定できますが、「まず記録だけして様子を見る」使い方は Enterprise 向けです。

2026年10月の動き：PHPの脆弱性「php2shell」を無料でも自動で防御

php2shell は、PHP 本体（ランタイム）のメモリの扱いに関する脆弱性です。Cloudflare のブログによると、PHP 5.4 以降を動かすすべての Web サーバーが影響を受け、細工したリクエストでサービス停止・リモートでのコード実行・データ漏えいが起こる恐れがあります。

php2shell の公開と Cloudflare の対応の流れを示す図 — Cloudflare ブログ・AWS セキュリティブログ・php.net（2026年10月24日確認）をもとに IT Picks 編集部が作成

日時（日本時間）	出来事
2026年10月17日	AWS が、公開前の段階で悪用の試みをハニーポットで観測（AWS セキュリティブログ）
2026年10月21日 12:02	Cloudflare が無料・有料の WAF 利用者を既定で保護（Cloudflare は「公開の約9時間前に展開」と説明）
2026年10月21日 23:00	PHP が修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開
2026年10月23日	PHP が関連する CVE-2026-115560 について告知。Cloudflare もブログに追記

※ 時刻は UTC で発表されたものを日本時間に換算。

無料プランでは、Free Managed Ruleset に php2shell 向けのルールが7つ追加され、利用者の操作なしで有効になりました。Cloudflare は「無料の利用者は保護を有効にするための操作は不要」としています。

一方、Pro・Business・Enterprise では、Cloudflare Managed Ruleset が「ブロック」で動いているかを確認するよう案内しています。有料プランの方が自分で確認すべきことがある、という点は意外かもしれません。

Cloudflare は、公開日より前に情報が漏れ、実際に攻撃の通信を観測したとも書いています。AWS も、公開4日前の 10月17日に悪用の試みを観測したと報告しており、公開前から狙われていた脆弱性だったことが分かります。

PHP 側の修正版と、更新までの間に PHP 公式が示している暫定策は、こちらの記事で詳しく整理しています。

新機能「レスポンスルール」とは？攻撃の結果を見て止める

今回、php2shell の防御とあわせて登場したのが、full transaction detection（リクエストとレスポンスをまとめた検知）とレスポンスルールです。

これまでの WAF は、サイトに届く前のリクエストだけを見て判断していました。新しい仕組みは、オリジンが返したレスポンスも合わせて評価し、攻撃が成功したとみられるときはレスポンスが相手に届く前にブロックします。

Cloudflare のブログ「Introducing full transaction detection for Cloudflare WAF」 — 出典: Cloudflare ブログ「Introducing full transaction detection for Cloudflare WAF」（2026年10月24日確認）

① マネージドの既定ルールセットは自動で動く

全プランに「Cloudflare Managed Response Firewall Default」というルールセットが用意され、既定ですべてのリクエストで動きます。php2shell 向けの防御は、この仕組みを使った最初のマネージドの検知です。誤検知が心配なときは、対象のパスを絞ることもできます。

② カスタムのレスポンスルールは3つまで

全プランで、カスタムのレスポンスルールを最大3つ作れます。アクションは Log（記録）と Block（ブロック）です。リクエストの条件とレスポンスの条件（ステータスコード・ヘッダーなど）を組み合わせられます。

Cloudflare のブログでは、例として「/admin への未認証のリクエストに、管理画面の HTML が 200 で返ってきたときだけブロックする」ルールを紹介しています。ログイン失敗やリダイレクトは止めず、本当に管理画面が漏れたときだけ止めるという考え方です。

③ まだできないこと

レスポンスの本文（中身）を条件にするルールは、まだ作れません。また、攻撃の検知結果を使う cf.waf.signature.response.* のフィールドは有料プラン向けです。そして、レスポンスを止めても、オリジンですでに実行された処理は取り消せません。

無料プランで確認・設定したい4つのこと

無料プランの WAF は多くが自動で動きますが、前提が崩れていると守られません。公式ドキュメントをもとに、確認したい点を4つにまとめます。

① DNS レコードが「プロキシ済み（オレンジの雲）」になっているか

WAF が働くのは、DNS レコードのプロキシ状態が「Proxied」（オレンジの雲）のときだけです。「DNS only」（灰色の雲）だと、Cloudflare はサーバーの実際の IP アドレスを返すだけで、通信は Cloudflare を通りません。

ダッシュボードから追加したドメインは既定でプロキシされますが、トラブル対応などで灰色に切り替えたまま、というケースもあるため確認しておきましょう。

② Security Rules の画面で、ルールが有効か

ダッシュボードの［Security］→［Security Rules］で、マネージドルールが有効になっているかを確認できます。レスポンスルールの設定は、同じページの下部にあります。

③ Security Analytics でブロックの記録を見る

ブロックされた通信は、［Security］→［Security Analytics］→［Events］で確認できます。php2shell のルール ID で絞り込むと、自分のサイトが実際に狙われているかが分かります。無料プランではサンプリングされたログのみである点は押さえておきましょう。

④ オリジンのサーバーに直接アクセスされないようにする

見落としやすいのがここです。攻撃者がサーバーの IP アドレスを知っていれば、Cloudflare を通らずに直接攻撃できます。そうなると WAF は働きません。

Cloudflare の公式ドキュメントは、オリジンを守る方法として次を挙げています。

サーバー側で Cloudflare の IP アドレスからの通信だけを許可する
DNS only のレコード（TXT など）にサーバーの IP が載っていないか確認する
Web サイトと同じサーバーでメールを動かさない（エラーメールから IP が分かるため）
Cloudflare を導入した後にサーバーの IP を変える（過去の DNS 記録が残っているため）
Cloudflare Tunnel（全顧客が利用可）で、公開 IP を持たずに接続する

VPS でサイトを動かしている場合は、ファイアウォールの設定とあわせて見直すと効果的です。VPS で最初にやるべきセキュリティ対策は、こちらの記事でまとめています。

WAFだけでは防げないこと：PHPの更新は必須

Cloudflare 自身が、「WAF による保護があっても、PHP は更新すべき」と明言しています。WAF はあくまで多層防御の1枚です。

① 根本対策は PHP 本体の更新

php2shell は PHP 本体の脆弱性なので、サイトのコードやプラグインを更新しただけでは直りません。PHP を 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以降に更新する必要があります。レンタルサーバーなど事業者が PHP を管理している場合は、事業者に更新を依頼するよう Cloudflare は勧めています。

② 修正版でも残る関連の脆弱性（CVE-2026-115560）

10月23日、PHP はセッションのアップロード進捗機能に関する関連の脆弱性（CVE-2026-115560）を告知しました。Cloudflare によると、8.5.12 を含む修正済みの PHP にも影響し、修正は次の通常リリースになります。

PHP 公式によると、発生するのは設定とアプリのコードが珍しい組み合わせのときだけです。それでも、次のリリースまでは session.upload_progress.enabled=0 にしておくよう勧めています。10月21日の暫定策ですでに設定していれば、そのままで構いません。

③ WAF のルールが効かない設定もある

Cloudflare は、session.upload_progress.name を既定から変更しているサイトは、WAF のルールの対象外だとしています。既定のままなら、既存のルール（#6）で CVE-2026-115560 も防げるとのことです。

④ 直接アクセスと、すでに実行された処理

前の節のとおり、オリジンに直接届く通信は WAF を通りません。また、レスポンスルールで止めても、サーバー側ですでに動いた処理は元に戻りません。

有料プラン（Pro）を検討したいケース

個人ブログや小さなサイトなら、まずは無料プランの WAF を正しく動かすことが先決です。そのうえで、次に当てはまるなら Pro（年払いで $20/月）を検討する価値があります。

より幅広い攻撃パターンを防ぎたい（Cloudflare Managed Ruleset・OWASP Core Ruleset が使える）
カスタムルールが5つでは足りない（Pro は20）
ブロックの記録をサンプリングではなく確認したい

正規表現を使ったルールや Security Events のアラートは Business 以上です。必要な機能が Business にしかない場合は、$200/月（年払い）という価格差も踏まえて判断しましょう。

Cloudflare は、レスポンス側の検知についても、無料プランは注目度の高い脆弱性に絞り、有料プランにはより多くの検知を提供していく方針を示しています。

開発者の反応

Hacker News の Cloudflare の発表スレッドでは、対応の速さを評価する声が出ています。

ユーザーの sankalpmukim さんは、対応の速さが「とても印象的」だとコメントしています（出典）
ユーザーの CrimsonRain さんは、この対応が数多くのサイトを乗っ取りから救うだろうと、Cloudflare に感謝を述べています（出典）
一方、ユーザーの asar さんは、自分のサービスで同じような防御をするためのオープンソースのプロキシを尋ねており、Cloudflare に頼らない方法を探す声もあります（出典）

同じスレッドでは、AI による脆弱性の発見と悪用が速くなっていることへの懸念も議論されていました（出典）。