WEBサイトCloudflareは、重大な脆弱性を概要・今すぐやること・証拠の順に読ませる公開のハブ「Zero Wire」を紹介した。攻撃データは侵害の数ではない ── ハブの情報を担当サイトの台帳に落として確かめる13項目（2026年11月時点）
Cloudflareは、重大な脆弱性を概要・今すぐやること・証拠の順に読ませる公開のハブ「Zero Wire」を紹介した。攻撃データは侵害の数ではない ── ハブの情報を担当サイトの台帳に落として確かめる13項目（2026年11月時点）
目次
01 何が書いてあるか — 重大な脆弱性を「速報」の形に整理した、公開の調査ハブ
引用について
この記事は、Cloudflareが2026年11月3日付けで公開したZero Wireの紹介ブログを、2026年11月6日に取り込んで読んだ内容を書いている。英文は一字ずつ引き写さず、記事の筆者が日本語に直した要旨で書く。画面や欄の名前（Needs attention、Reference、What to do nowなど）だけは原文のまま書く。ハブ本体（Cloudflare Radarの該当ページ）と、例として挙がるphp2shellの項目（該当ページ）は、筆者の取得ではアクセスを断られて開けなかった。この記事は、紹介ブログに書かれた範囲だけで書く。出典に書かれていない筆者の考えは、「筆者の読み」「筆者の案」と書いて分ける。
Cloudflareは、重大な脆弱性の情報を整理して公開するハブ「Zero Wire」を紹介した。Cloudflare Radarのセキュリティの欄の中にある、誰でも読める脆弱性情報のフィードである。原文は、通信社の速報のような明快さを、重大なセキュリティの動きに持ち込むことを狙いにしていると書く。この記事は、そこに書かれた限界を、担当サイトの優先順位づけにどう使うかを、13項目のチェックにまとめる。
公開の場所と、読む人の想定
Zero Wireは、Cloudflare Radarのセキュリティの欄にある。原文は、形式を意図して単純にしたと書き、必要なことだけをまとめた索引カードのようなものだと説明する。想定する読み手は2種類で、1つは、問題をすぐ理解して、適切な質問ができる経営側（原文はCISOと書く）、もう1つは、同じ項目から、調べて直すために必要な技術の案内にたどり着く技術者である。インフラへの影響を調べる、あらかじめ作られたプロンプトも用意されている。
対象になる脆弱性
対象は、インターネットに公開されたソフトウェアの、重大な脆弱性である。Webアプリケーション、それが動く土台のランタイム（プログラムを動かす基盤）やライブラリ、プロキシで悪用を減らせる公開サービスが含まれる。原文は2点を重ねて書く。1つは、Cloudflareが専用のWAFのルールを持っていることは、掲載の条件ではないこと。もう1つは、問題によっては、提供元の更新や、Cloudflareが検査できる通信の外側の変更が要ることである。さらに、Cloudflareの顧客かどうかに関係なく役立つ情報だと書いている。
1件のカードに載る項目
1件のカードには、次の項目が載る。問題の紹介（関連するCVEがあれば併記）、重要性と対応の要約、何が起きたかを書いた概要、「What to do now」（今すぐやること）、証拠（CVEの記録、研究、CISAの悪用確認リスト〈KEV〉などの悪用の情報）、Cloudflareの対策の欄（WAFのルールの有無と、設定の条件）、そして状態と最終確認日、変更の履歴である。1つの項目が、関連する複数のCVEを扱うこともある。筆者が読む順に並べると、次の図のようになる。
状態は2つに分かれる
ホームの画面は、Needs attention（要対応）とReference（参照）の2つに分かれる。前者は、能動的な評価や対応が要る問題を集める。既知の悪用がある問題や、案内が更新されている最中の問題が含まれる。後者は、案内が落ち着いたあとも、その項目を読めるように残す場所である。原文は、Referenceに移っても、影響を受けた全部のシステムが修正済みになったという意味ではないと書く。既知の悪用、調査の継続中、提供元の修正の公開は、それぞれ別のことを表す、とも書く。
例に出る脆弱性は、php2shellだけ
紹介ブログが名前を出して例にするのは、PHPの脆弱性（通称php2shell）である。PHPのランタイムの問題は、WordPressやMagentoのようなアプリケーションを運用するチームにも関わる。原文は、アプリケーションのコードやプラグインを更新しただけでは、土台のランタイムは直らないと書き、版と修正は、PHPの公式のセキュリティ情報で確かめるよう案内している。このほかの収録件数や、どの件が並んでいるかは、紹介ブログには書かれておらず、筆者はハブ本体を開けていないので、この記事では扱わない。
02 なぜ・背景 — 速報が続くと、基本の事実を集める手間が先に尽きる
原文が書く出発点
紹介ブログは、重大な脆弱性の発見が増え、速くなっていると書き出す（AIの影響にも触れている）。そして、担当者が朝に新しい通知を受け取り、提供元の告知と技術の資料を比べ、影響を受けるシステムを探している間に、その作業が終わる前に、次の公表が届くという状況を描く。Zero Wireは、この「基本の事実を集める時間」を減らし、対応に使う時間を増やすことを目的にしている。
担当サイトの側で起きること（筆者の読み）
これは、サイトの運営でもそのまま起きる。当サイトでも、PHPの重大な脆弱性が出た週は、公式の告知、EUの機関の注意喚起、国内の注意喚起、報道が、日をまたいで次々に出た。出典ごとに時刻の書き方が違うので、日本時間に直して並べた。その流れは、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に日付順に並べた。ハブのような束ね役は、情報を集める手間を減らす。ただし、自分のサイトの版を調べる手間は減らない。ここが、この記事の出発点である。
WEBディレクターの位置（筆者の読み）
原文が想定する経営側と技術者の間に、WEBディレクターが立つことは多い。経営側から「うちは大丈夫か」と聞かれ、制作会社や運用担当に「どの版か」を聞く役である。ハブのカードは、この2人に同じ項目を見せられる形になっている。ただし、カードの「今すぐやること」は、全部のサイトに共通の案内である。どの担当サイトに当たるかは、ディレクターの台帳が決める。台帳とは、担当サイトごとに、使っているソフトの版と、更新の担当者を書いた一覧である。
知らせの数と、侵入の数を分ける
攻撃の「試み」の数は、見出しになりやすい。当サイトでも、php2shellの公開の直後に、Cloudflareの網で数えた試みの数が報じられた。PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いたとおり、試みの数と、侵入された数は別のものである。Zero Wireの原文も、この区別を、カードの読み方の中心に置いている。次の章で用語をそろえ、その次の章で、原文が書く注意を表にする。
03 用語 — 出てくる言葉を、先にそろえる
用語
KEVは、アメリカのCISAが管理する、実際に悪用された脆弱性の一覧（Known Exploited Vulnerabilities）である。ハブのカードの「証拠」の欄には、このような悪用の情報へのリンクが載る。一覧の見方は、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いた。公式はカタログのページで公開している。
用語
補う対策（原文の言い方は、代わりの統制策）は、脆弱なソフトウェアを直す代わりではなく、直すまでの間に、危険を下げる別の守りである。原文が挙げる例は、CloudflareのWAFのルールである。WAFは、Webサイトの入口で、怪しい通信を止める仕組みである。
用語
オリジンは、WAFなどの入口の仕組みの後ろにある、Webサイト本体のサーバーである。原文は、入口で通信を止めても、オリジンですでに行われた操作は取り消せないと書く。ランタイムは、プログラムを動かす土台で、PHPならPHPそのものを指す。
「攻撃データ」の正体
カードには、攻撃データのグラフが付く。これは、CloudflareのWAFのマネージドルール（Cloudflareが用意するルール）に合致したHTTPリクエストの件数を、時間の順に並べたものである。原文は、これは侵害されたシステムの数でも、成功した悪用の数でもないと書く。筆者の読みでは、使い道は「攻撃者の関心がいま高いかどうか」の目安に限られる。
「証拠」の欄に並ぶものの違い
証拠の欄には、CVEの記録、研究、KEVのような悪用の情報が並ぶ。原文は、提供元の告知が、影響を受ける版と、直し方を決めると書く。つまり、版と修正の判断は提供元の告知が決め、悪用の有無はKEVなどが示し、ハブはそれらをつなぐ。3つは、同じものではない。
04 型別 — 対象、書かれていないこと、読む手順
🅰 適用範囲 — 載るのは重大なものだけ
原文の書き方では、ハブが扱うのは、インターネットに公開されたソフトウェアの重大な脆弱性である。筆者の読みでは、担当サイトの管理画面だけで使う道具や、社内の機器の話は、ここには載らない。ハブに載っていないことは、担当サイトに関係がないことを意味しない。ハブは、台帳の代わりにならない。
🅱 このハブが測っていないこと — 原文が書く8つの注意
原文が書く注意を、読み方と合わせて表にした。この表が、記事の中心である。
| 番号 | 原文が書く注意（要旨） | 担当サイトでの読み方（筆者の案） |
|---|---|---|
| 1 | 脆弱性の深刻度と、実際に悪用されている証拠は別のものである | 重大でも悪用の証拠がない件と、悪用の証拠がある件を、台帳の別の列に書く |
| 2 | WAFのルールに合致したリクエストの件数は、侵害されたシステムや成功した悪用の数ではない | グラフの山を、自分のサイトの被害の数として写さない |
| 3 | 攻撃の試みを観測しても、特定の組織が侵害されたとは分からない | 「試みが多い」を理由に、すぐ「うちは侵入された」と書かない |
| 4 | Cloudflareの網で試みが観測されなくても、ほかの場所で悪用がないとは言えない | グラフが静かな件でも、自分の版を確かめる |
| 5 | WAFによる緩和は、対象の通信に対する補う対策で、脆弱なソフトの修正の代わりにならない | 「ルールがある」を、「直した」の欄に書かない |
| 6 | 入口で通信を止めても、オリジンですでに行われた操作は取り消せない | 公開の前後のログを、別に確かめる日を決める |
| 7 | Referenceに移っても、影響を受けた全部のシステムが修正済みとは限らない | Referenceの件も、自分の版を一度確かめる |
| 8 | 設定の画面へのリンクは、ルールを自動で有効にせず、デプロイも確かめない | リンクを開いただけでは「有効」と書かず、画面でルールの状態を見る |
8つの注意は、1つの考えにまとまる。ハブの情報は、自分のサイトの状態を教えない。教えるのは、世の中で何が起きているかである。自分のサイトの状態は、自分の側の値（版、修正の有無、設定の状態）で確かめる。
🅲 読む手順 — 5つの順で1件を読む
1件を読む順番を、次のようにすると、読み落としが減る（筆者の案）。
- 状態と最終確認日を見る。Needs attentionか、Referenceか。いつ確かめた情報か。
- 概要で、影響を受けるソフトの名前を3つまで書き出す。
- 担当サイトの台帳で、同じ名前のソフトを探す。
- あれば、提供元の告知で、影響を受ける版と修正版を台帳に写す。
- 「今すぐやること」を、担当者と日付つきで台帳に写す。
ここまでは、ハブを開いた画面の中で終わらない。3番目以降は、自分の台帳を開く作業である。
読み取り専用のプロンプトも、同じ位置づけ
原文は、インストールされているソフトウェア、提供元の修正、露出、補う対策について、読み取り専用で評価させるプロンプトを用意したと書く。結果として、資産ごとの証拠、不明な点、次の行動が出る。同時に、プロンプトをコピーしただけでは、システムの検査も変更も行われないと書いている。筆者の読みでは、これも「世の中の情報を、自分の資産に当てはめる補助」で、結果は台帳に写す前に、自分の値で確かめる必要がある。
05 明日、担当サイトで確認できることチェックリスト
以下は、Zero Wireのような公開のハブの情報を、担当サイトの台帳に落とす13項目である。1〜3番目はハブの画面の確認、4〜7番目は台帳との照らし合わせ、8〜9番目は数字の読み方の記録、10〜11番目は対策の欄と古い項目の確認、12〜13番目は習慣と記録である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- Cloudflare RadarのZero Wireのホームを開き、Needs attentionに並ぶ項目の数を数えて、メモ帳に書く
- 先頭の1件を開き、概要、証拠、Cloudflareの欄、What to do nowの4つの欄がそろっているかを見て、無い欄を台帳に書く
- その1件の状態（Needs attentionかReference）と最終確認日を、台帳の1行に写す
- その1件が影響を受けるソフトの名前を3つまで書き出し、担当サイトの台帳に同じ名前があるかを探す
- 台帳に同じ名前が無ければ、「該当なし・確認した日」を台帳の1行に書く
- 台帳に同じ名前があれば、リンク先の提供元の告知を開き、影響を受ける版と修正版を、台帳の隣の列に写す
- 担当サイトで動いている版を、制作会社か運用担当に1通のメッセージで聞き、更新の担当者の名前も同じメッセージで聞いて、返事を台帳に書く
- 攻撃データのグラフを見たら、台帳の備考に「WAFのルールに合致したリクエストの推移で、侵害の数ではない」と1行書く
- 証拠の欄に、CISAの悪用確認リスト（KEV）へのリンクがあるかを見て、あるか無いかを、深刻度とは別の列に書く
- Cloudflareの欄にWAFのルールの案内があるとき、担当サイトがCloudflareを使っているかを台帳で確かめ、使っていれば管理画面でそのルールの有効か無効かを1か所見て、台帳に書く
- Referenceに移った項目を1件開き、担当サイトの版が修正版以上かを、台帳で確かめて書く
- What to do nowの項目を台帳に写し、担当者と、やる日付を1つずつ決めて書く
- ハブを開く曜日を週に1回に決めて台帳の見出しに書き、前回から変更履歴が動いた項目を1件読む
06 代替・他の選択肢 — ハブの代わりに、あるいはハブと一緒に読むもの
ハブは、情報の束ね役である。ほかの情報源と並べると、役割の違いが見える。
| 情報源 | 分かること | 分からないこと | 筆者の案 |
|---|---|---|---|
| Zero Wire | 重大な件の概要、今すぐやること、証拠へのリンク、状態 | 自分のサイトの版 | 最初の入口にして、台帳で照らす |
| 提供元の告知 | 影響を受ける版と、修正の手順（原文の言い方） | 悪用の広がり | 版と修正は、ここを正にする |
| CISAの悪用確認リスト | 実際に悪用された件であること | 自分のサイトに当たるか | 期限は、自分のサイトの期限に読み替える |
| 国内の注意喚起（JPCERT/CC） | 対象の版、推奨する対応、更新の履歴 | 自分のサイトの版 | 更新日を見て、前回から変わった点を読む |
| 自分のアクセスログ | 自分のサイトに実際に来た通信 | 来なかった通信、すでに起きた操作の中身 | ハブの「今すぐやること」にログの確認があれば、日を決めて見る |
国内の注意喚起は、更新される
JPCERT/CCのPHPの注意喚起（JPCERT-AT-2026-0033）は、2026年10月22日に公開され、10月29日に更新された。更新では、ファイアウォール製品の特定の版で、侵害を示す痕跡が確認されたという報告があること、一部の製品の提供元が、この脆弱性を悪用する攻撃を観測して告知を更新したことが追記された。同じ注意喚起は、痕跡が見つからなくても、攻撃を受けていないとは言い切れないと書いている。ハブの「観測がなくても悪用がないとは言えない」と同じ向きの注意である。
自分のログを、別の手で読む
ハブのグラフは、Cloudflareの網で数えたものである。自分のサイトに来た通信は、自分のアクセスログでしか読めない。ログから攻撃の兆候を探す道具として、🔧 【セキュリティ】IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール ★iLogツカウン — access.logを渡して、攻撃の兆候の検出結果を見やすく加工するというツールがある（利用には無料の会員登録が必要です）。兆候が出なかったことは、侵害が無いことの証明にならない。この点も、ハブの8つの注意と同じ向きである。
外から見える状態を、まとめて確かめる
ハブの項目とは別に、担当サイトが外からどう見えているかを一度確かめたいときは、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — URLを入れて、外から取れる情報で対策の状況を確認するというツールがある（利用には無料の会員登録が必要です）。外から見える範囲に限られるので、内部の版や設定は分からない。
プロンプトを使うときの筆者の案
読み取り専用のプロンプトを使うなら、結果を台帳に写す前に、その回答を、自分の値で確かめ直す。台帳に「確かめた方法」の列を作り、「AIの回答」と書いたまま残さず、確かめた日に書き直す。また、プロンプトにどの範囲の情報を入れてよいかは、担当サイトの契約と社内の決まりで先に決める。決まりが無ければ、台帳に「未決」と書いて、使わない。
07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない
当サイトは、Cloudflareを使っていない。そのため、ハブの「Cloudflareの欄」は、当サイトのWAFには関係がない。当サイトの画面で、ハブの項目を開いたり、ルールの状態を見たりもしていない。第05章のチェックリストのうち、10番目はCloudflareを使っている担当サイトの画面での確認で、そのほかは、Cloudflareを使っていなくても同じように行える。原文も、Cloudflareの顧客かどうかに関係なく役立つ情報だと書いている。
注意
この記事に書いた、ハブの項目と画面の中身は、紹介ブログに書かれていることの要旨である。ハブ本体は、筆者の取得では開けなかった。当サイトで動かして確かめた内容ではない。
当サイトで近い確認をした3つ
ハブの注意と同じ向きのことは、当サイトでも、別の件で確かめたことがある。1つは、攻撃の試みの数と、侵入された数は別だという区別で、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録に書いた。1つは、修正が入ったかを、版の表示ではなく、設定の値で確かめる方法で、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。もう1つは、数字を合計だけで読まず、日ごとに割って内訳を見る方法で、「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだったに書いた。ハブのグラフを読むときの注意と、考え方は重なる。
これから行うこと
実務のヒント
🔧 まだ行っていないこと: ハブ本体のphp2shellの項目を開けたら、状態、最終確認日、「What to do now」を、当サイトの記録（上の2本の記事）と並べて読み、違いがあれば、日付つきでこの章に書き足す。
08 このテーマは、ここまで — PHPの脆弱性と、WAFの知らせを追った記事の流れ
これまでの記事
当サイトでは、2026年10月から、PHPの脆弱性と、CloudflareのWAFの関係を、何度か取り上げた。時系列で並べる。
- PHPの重大な脆弱性が出た週は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録で書いた。
- WAFの保護と、PHPの更新の関係は、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）で書いた。
- WAFの検知と応答の新しいルールは、CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）で書いた。
- WAFの守りが届かない所は、CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）で書いた。
- 期限の日の読み替えは、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法で書いた。
- WAFの更新の表の読み方は、CloudflareのWAF更新で、PHPの5つのルールは検知が更新されてもBlockのままで、Nuxt Image / IPXの新しいルールは既定で無効だった ── 更新の表を動作・既定の状態・説明の文で読み分ける13項目（2026年11月時点）で書いた。
- 悪用確認リストに載った別の件は、WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日 ── 担当サイトの更新の窓と、前後の記録を確かめる13項目（2026年11月時点）で書いた。
今回の記事の位置
これまでの記事は、ルールがどう働くか、どこで働かないか、更新の表をどう読むかを扱っていた。今回は、情報源そのものをどう読むかを扱った。ハブは、世の中の動きを束ねて見せる。自分のサイトの状態は、自分の台帳が決める。ここから先は、ハブの項目を開いて、台帳の1行に写せたかを確かめる段階になる。ランタイムの中の部品について、当サイトで該当する場所を数えた記録は、圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方にある。
現在の貴方のIPアドレス
このサイトで書いている人
