CloudflareのWAF更新で、PHPの5つのルールは検知が更新されてもBlockのままで、Nuxt Image / IPXの新しいルールは既定で無効だった ── 更新の表を動作・既定の状態・説明の文で読み分ける13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 同じ日に、動作が変わらない更新と、既定で無効の新ルールが並んだ
   1. 通常の更新 — PHPの5つのルールは、検知の中身が更新され、動作はBlockのまま
   2. 緊急の更新 — Nuxt Image / IPXの新しいルールは、既定で無効
   3. 読み分ける3つの列
2. 02 なぜ・背景 — 「更新された」だけでは、自分のサイトに何が起きたかが分からない
   1. 動作がBlockのままでも、止める中身は変わる
   2. 更新は、7日のサイクルで入る
   3. 緊急の更新は、サイクルを待たない
   4. WAFの更新は、PHPの更新の代わりにならない
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「部分的な対応」の意味
   2. 既定で無効のルールは、いつでも有効にできる
4. 04 型別 — 対象のルール、書かれていないこと、読む手順
   1. 🅰 適用範囲 — 2件の更新を、表で並べる
   2. 🅱 この変更履歴が書いていないこと
   3. 🅲 手順1 — 動作の列を、行ごとに読む
   4. 🅲 手順2 — 既定の状態を、新しい動作の列で読む
   5. 🅲 手順3 — 説明の文の「部分的」を、台帳に写す
   6. 🅲 手順4 — 自社の使っているものと照らす
   7. 🅲 手順5 — 新しいルールが出た週に、一致の数を見る
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — ルールを読む以外の、追い方と備え方
   1. 動作の列ごとに、次の一手を決めておく
   2. 更新の知らせを、自分で追う
   3. ルールの動作を、自分で変えるときの注意
   4. 誤検知が増えたときの備え
7. 07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない
8. 08 このテーマは、ここまで — CloudflareのWAFと、PHPの更新を追った記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — 同じ日に、動作が変わらない更新と、既定で無効の新ルールが並んだ

Cloudflareは2026年10月30日、WAF（ウェブアプリケーションファイアウォール）のルールの更新を、同じ日に2件、変更履歴に載せた。1件目は通常の更新で、2件目は「緊急」と付いた更新である。2つを並べて読むと、「更新が出た」という同じ知らせの中に、動作がまったく変わらないものと、入っただけでは効かないものが混ざっていることが分かる。この記事は、その読み分けを、13項目のチェックにまとめる。

通常の更新 — PHPの5つのルールは、検知の中身が更新され、動作はBlockのまま

1件目の要旨は次のとおりである。PHPの、メモリが足りなくなる種類の脆弱性（OOM）に関するルールの内部の式を更新した。対象のCVEは、CVE-2026-109618、CVE-2026-109619、CVE-2026-115560の3件である。変更は、同社が開いたPHPの攻略の催し（CTF）で、外部のセキュリティ研究者から寄せられた報告を基にした、少しずつの改善だと書かれている。

表には5行が並ぶ。Cloudflare ManagedとFreeの2つのルールセットに、それぞれ「PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619) #3」と「#4」の2行、Responseのルールセットに「Default block for High confidence Signatures」の1行である。5行とも、前の動作（Previous Action）も新しい動作（New Action）もBlockで、コメントは「検知を更新した」という意味の短い文だけである。つまり、止める設定のまま、何を止めるかの中身が更新された。

なお、原文は、冒頭の文では対象の脆弱性を「メモリ不足（OOM）」の種類と書き、表のルール名では「Remote Code Execution Attack」（遠隔でのコード実行）と書いている。2通りの書き方が並んでいて、どちらが正確かは、変更履歴からは分からない。この記事は、冒頭の説明では前者、表と図ではルール名をそのまま使う。

緊急の更新 — Nuxt Image / IPXの新しいルールは、既定で無効

2件目の要旨は次のとおりである。Cloudflare Managedのルールセットに、Nuxt ImageとIPXの脆弱性に対する新しいルールを1つ足した。ルールの名前は「Nuxt Image / IPX - Explicit GIF or Animation Modifier Exposure」である。表では、前の動作が「N/A」（該当なし）、新しい動作がDisabled（無効）で、コメントは新しい検知だという意味になっている。さらに、公式は、このルールが部分的な対応（原文の言い方は「partial coverage」）にとどまると書き、利用者には、注意情報（アドバイザリ）に従って、最新版へ更新するよう求めている。

ここで、筆者が確かめられたのは、変更履歴のページに書かれた範囲だけである。Nuxt ImageとIPXの元の脆弱性情報（番号や詳しい内容）は、この変更履歴には出てこない。この記事は、Nuxt ImageとIPXについては、この1行にとどめる。

読み分ける3つの列

2つの更新を、表の中の3つの手がかりで読み分ける。1つ目は動作の列（前と新しいのBlock、Disabledなど）、2つ目は既定の状態（有効か無効か）、3つ目は説明の文（表のコメント欄ではなく、更新の冒頭の文にある「部分的な対応」など）である。図にすると、次のようになる。

02 なぜ・背景 — 「更新された」だけでは、自分のサイトに何が起きたかが分からない

動作がBlockのままでも、止める中身は変わる

WAFのルールは、通信の特徴を式で書いて、当てはまったら決められた動作（ブロック、記録だけ、など）を取る。今回の通常の更新で変わったのは、式の中身である。動作の列がBlockのままでも、何がBlockされるかは変わる。変更履歴は、それを「検知の更新」という言い方で伝えている。担当者から見れば、画面の表示は変わらず、止める範囲だけが少し変わる。

この変化は、普通は利用者には見えない。変更履歴を読んでいなければ、更新があったことを知らないまま、守りが少し変わる。読んで分かるのは、「前と同じ」ではなく「前と同じ動作で、中身が更新された」ということである。ただし、今回の変更履歴は、どの通信が新しく止まるか、あるいは止まらなくなるかは書いていない。そこは、この記事では分からない。

更新は、7日のサイクルで入る

Cloudflareの変更履歴の説明のページは、管理されたルールの更新が、7日のサイクルで、ふつうは月曜か火曜に行われると書く。要旨は次のとおりである。

• 1週目は、新しいルールや更新したルールを、記録だけ行う動作（Log）で入れる。一致した通信は記録されるが、止まらない。新しいルールの多くには、betaとnewの印が付く。
• 2週目は、次のリリース日に、記録だけの動作から、表に書かれた既定の動作へ切り替わる。betaとnewの印は外れる。
• 既存のルールを更新するときは、更新した版を、別のbetaのルールとして先に入れ、次のサイクルで元のルールを更新する。

ページには、betaの印が7日を過ぎても残ることがあるとも書かれている。古いルールを廃止していない場合などである。そのため、ルールの段階を判断するときは、印だけに頼らず、変更履歴の「last_updated」の欄を見るよう勧めている。

緊急の更新は、サイクルを待たない

同じページは、新しい脆弱性への対応では、通常の7日のサイクルを待たずにルールを出すことがあり、それを緊急のリリースと呼ぶと説明している。10月30日の2件目が、その緊急のリリースである。通常の更新とは、出し方が違う。通常の更新は、記録から始まる段階を踏む。緊急の更新は、段階を省く場合がある。ただし、今回の緊急のルールが、記録から始まる段階を踏んだかどうかは、変更履歴の表からは分からない。

WAFの更新は、PHPの更新の代わりにならない

今回の通常の更新が対象にしたPHPの3件の脆弱性について、当サイトは以前から取り上げている。WAFの保護が入っても、PHPの更新は要る、というのが、公式の書き方である。PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）と、CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）に書いた。今回の更新の知らせも、その考え方の延長で読む。ルールが更新された日は、自分のPHPが更新済みかを確かめる日でもある。

03 用語 — 出てくる言葉を、先にそろえる

「部分的な対応」の意味

緊急の更新は、ルールが部分的な対応にとどまると書く。筆者の読みでは、「このルールが当てはまる通信を止めても、脆弱性そのものは直らない場合がある」という意味である。この読みは、公式がその後に、アドバイザリに従って最新版へ更新するよう求めていることと合う。ただし、「部分的」の範囲が具体的にどこまでかは、変更履歴には書かれていない。

既定で無効のルールは、いつでも有効にできる

変更履歴の読み方のページは、同じリリースの中で、無効のモードのルールが足されることがあると書く。そうしたルールは、トラフィックに影響を与えずに、対策の仕組みを使えるようにしておくもので、必要なときに、いつでも有効にできる。betaやnewの印は付かない。無効のルールは、入っただけでは、何もしない。有効にするかどうかは、利用者が決める。

04 型別 — 対象のルール、書かれていないこと、読む手順

🅰 適用範囲 — 2件の更新を、表で並べる

変更履歴の2件を、表にした。ルールの識別の番号は、この記事では書かない。

最後の行のコメント欄に書かれているのは「新しい検知」だけである。「部分的な対応」という言葉は、表のコメント欄ではなく、緊急の更新の冒頭の文にある。

表を見て、筆者が気づいた点が1つある。冒頭の説明は、3件のCVE（109618、109619、115560）を挙げているが、表の説明欄に書かれた番号は、109618と109619の2件だけで、115560は、表の行には出てこない。Responseの行の説明にも、番号は書かれていない。3件目がどのルールに当たるのかは、この変更履歴の表からは読み取れない（筆者の読み）。表と冒頭の説明で、番号の数が違うことは、読み違いのもとになるので、台帳には、冒頭の文と表の両方を写しておく。

🅱 この変更履歴が書いていないこと

• 更新の前後で、止まる通信がどう変わるか（どんな通信が新しく止まるか、止まらなくなるか）は書かれていない。
• 通常の更新の5つのルールが、何の通信を、何回止めたかという数字は書かれていない。
• 緊急のルールが対象にしているNuxt ImageとIPXの脆弱性の番号や、直った版の名前は書かれていない。注意情報への案内があるだけである。
• 緊急のルールの「部分的」が具体的にどこまでかは書かれていない。
• 表のPrevious Actionの列が何を指すかは、読み方の公式のページには書かれていない。

書かれていないことは、知らないままにしないのが、この手の更新を読むときの原則である。分からない点は、台帳の備考に「書かれていない」と書いて残す。推測で埋めない。

🅲 手順1 — 動作の列を、行ごとに読む

最初の作業は、表の行ごとに、前の動作と新しい動作を見ることである。通常の更新の5行は、どれもBlockからBlockで、動作は変わっていない。台帳には、「動作の変更なし、検知の中身の更新」と書く。ここで、「更新があったから、設定を変える必要がある」と読みかけたら、動作の列をもう一度見る。変更が無いのに、手を動かす理由は、通常は無い。

🅲 手順2 — 既定の状態を、新しい動作の列で読む

次の作業は、新しい動作の列に、Disabledが無いかを探すことである。緊急の更新の1行が、これに当たる。台帳には、「新規・既定で無効」と書く。このルールが、自社のサイトを守るために要るかは、次の手順で決める。有効にするかの判断は、自社のサイトがNuxt ImageかIPXを使っているかで変わる。

🅲 手順3 — 説明の文の「部分的」を、台帳に写す

緊急の更新の冒頭の文にある、「部分的な対応」という文を、台帳の備考にそのまま写す。この文は、「このルールを有効にしても、更新は必要」という意味を持つ。注意情報へのリンクが変更履歴にあるなら、そこも写す。

🅲 手順4 — 自社の使っているものと照らす

更新の知らせを読んで、最後にするのは、「自社のサイトに関係があるか」を確かめることである。PHPの3件は、自社のサイトがPHPで動いているなら関係がある。Nuxt ImageとIPXは、自社のサイトがそれらを使っているかを、制作会社や開発者に聞いて確かめる。使っていないなら、「対象外・確認日」を台帳に1行書く。使っているかどうかが分からないまま、有効にする・しないを決めない。

🅲 手順5 — 新しいルールが出た週に、一致の数を見る

通常の更新の仕組みでは、新しいルールや更新したルールは、1週目は記録だけで入り、2週目に既定の動作へ切り替わる。2週目に切り替わる前の、新しいルールが出た週に、セキュリティイベントの画面で、そのルールの一致の数を見ておく。想定外の一致（正しい通信が当てはまっている）があれば、動作が切り替わる前に気づける。公式のページも、1週目に、想定外の一致がないか、セキュリティイベントを確認するよう案内している。

05 明日、担当サイトで確認できることチェックリスト

以下は、WAFのルールの更新を読み、動作と既定の状態を台帳に書き分ける13項目である。1〜4番目は変更履歴の読み取り、5〜6番目は自社の画面の確認、7〜8番目は制作会社への質問と記録、9〜10番目は自社の設定の確認、11番目は一致の数の確認、12〜13番目は習慣と記録である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• CloudflareのWAFの変更履歴を開き、2026年10月30日の2件（通常と緊急）の表を、メモ帳に表のまま書き写す
• 通常の更新の5行を上から見て、前の動作と新しい動作の両方がBlockの行の数を数え、台帳に「5行中◯行が動作の変更なし」と書く
• 緊急の更新の1行を見て、新しい動作がDisabledであることを確かめ、台帳に「新規・既定で無効」と書く
• 緊急の更新の冒頭の文にある「部分的な対応」の文と、注意情報への案内を、台帳の備考に写す
• Cloudflareを使っている担当サイトで、WAFのマネージドルールの画面を開き、PHPのルールを名前で探して、表示された本数を数える
• Nuxt ImageとIPXの緊急のルールを画面で探し、有効か無効かを台帳に書く
• 担当サイトのうち、Nuxt ImageまたはIPXを使っているものがあるかを、制作会社に1通のメッセージで聞き、返事を台帳に書く
• Nuxt ImageもIPXも使っていないサイトについては、「対象外・確認した日」を台帳の1行に書く
• ルールの動作を既定から変えているものがないかを、画面の一覧で上から見て、変えている本数を数える
• ルールセット全体やタグ単位で動作を変える設定（上書き）があるかを画面で見て、あれば台帳に1行書く
• 新しいルールが出た週に、セキュリティイベントの画面で、そのルールの一致の数を見て、想定外の一致がないかを5分で確認する
• WAFの変更履歴を開く曜日を、週に1回に決めて、台帳の見出しに書く
• PHPの版の一覧の隣に、「WAFのルールの更新は、PHPの更新の代わりにならない」と1行書く

06 代替・他の選択肢 — ルールを読む以外の、追い方と備え方

動作の列ごとに、次の一手を決めておく

表を読んだあと、何をするかを、動作の列ごとに先に決めておくと、毎回迷わない。筆者の案を、表にした。

更新の知らせを、自分で追う

変更履歴のページには、RSSの購読への導線がある。毎週開く曜日を決める代わりに、購読して、更新が出たときに気づく方法もある。ただし、知らせが届いても、読む人と、台帳に書く人が決まっていないと、知らせは積まれるだけになる。読む人と書く場所を先に決めるほうが、購読の手段より先である（筆者の案）。

ルールの動作を、自分で変えるときの注意

変更履歴の読み方のページは、動作を既定以外に変えると、Cloudflareは、そのルールの動作を後から上書きできなくなる、と書く。つまり、自社が動作を変えたルールは、更新があっても、自社の設定が優先されたままになる。今回の通常の更新のように、既定がBlockのルールを、自社がLogに変えていた場合、更新の後も、Logのままの可能性がある（筆者の読み）。確かめるには、画面で、自社が変えたルールを一覧にして、動作を見る。

誤検知が増えたときの備え

公式のページは、新しい・更新されたルールで、セキュリティイベントが急に増えたときは、そのルールを無効にするか、既定から別の動作へ変えられると書く。変える手順を、あらかじめ担当者と共有しておくと、夜間でも慌てない。変えたときは、いつ、誰が、なぜ変えたかを台帳に書く。動作を既定から変えたものは、更新の後も自分の設定が残るので、あとで戻す日付も書く。

07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない

当サイトは、Cloudflareを使っていない。そのため、この記事で読んだルールの更新は、当サイトのWAFには関係がない。当サイトの画面で、これらのルールの状態を見たり、動作を変えたりはしていない。第05章のチェックリストのうち、5・6・9・10・11番目は、Cloudflareを使っている担当サイトの画面での確認で、7・8番目は制作会社への質問と記録である。

通常の更新が対象にしたPHPの3件の脆弱性は、当サイトのPHPには関係があった。当サイトは、WAFの保護に頼らず、PHP自体の更新と、修正が入ったかの確認を済ませている。その記録は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録と、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。WAFのルールが更新された日の確認は、PHPの更新の確認と、別の作業として、同じ日に並べて行う。

08 このテーマは、ここまで — CloudflareのWAFと、PHPの更新を追った記事の流れ

これまでの記事

当サイトでは、2026年10月に入って、CloudflareのWAFと、PHPの更新の関係を、何度か取り上げた。時系列で並べる。

• PHPの重大な脆弱性が出た週は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録で書いた。
• WAFの保護と、PHPの更新の関係は、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）で書いた。
• 修正が入ったかを値で確かめる方法は、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。
• WAFの検知と応答の新しいルールは、CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）で書いた。
• WAFの守りが届かない所の確かめ方は、CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）で書いた。
• 期限の日の確認は、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いた。

今回の記事の位置

これまでの記事は、ルールがどう働くか、あるいはルールがどこで働かないかを扱っていた。今回は、ルールが更新されたとき、その知らせをどう読むかを扱った。動作が変わらない更新と、入っただけでは効かない更新を、表の列で読み分ける。担当サイトの一覧に、「WAFの更新を読んだ日」と「動作の変更の有無」の2列を足すと、読み分けの結果が、一覧の中で管理できる。一覧の作り方は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）にある。外から見える設定の状態をまとめて確かめるときは、🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するが入口になる。WAFのルールそのものは、このツールでは分からない。