脆弱性のニュースを見て、「何が起きて、うちは何をすればいいのか」と迷ったことはありませんか。重大なものについて、それを1か所で確かめられるページを Cloudflare が用意しました。発表は、2026年11月3日（日本時間23時）の公式ブログです。ページの名前は「Zero Wire」で、Cloudflare Radar 上にあります。WordPress や PHP でサイトを動かしている人、社内のセキュリティを見ている人に関係する話です。
結論から言うと、Zero Wire は、重大な脆弱性を問題ごとのカード（ブリーフィング）にまとめた、誰でも見られる公開ページです。 カードには、平易な説明、誰が調べるべきか、推奨する対応、根拠とベンダーの案内へのリンクが入ります。この情報は Cloudflare の顧客かどうかに関係なく役立つ、と Cloudflare は書いています。ページは英語です。
実際のページは、Zero Wire（Cloudflare Radar 公式）で見られます。発表の出典は、Cloudflare の発表記事（Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities）です。
脆弱性を重大なものに絞ってまとめる Zero Wire
発表の背景
Cloudflare は、AI が重大な脆弱性の発見の量と速さを変えている、と書いています。AI は、大きなコードベースを大規模に解析し得ます。人のレビューでは何年も見つからずにいた可能性のある深い欠陥も、見つけ得るという説明です。
その勢いで、セキュリティチームへの圧力は増していく、としています。発表 1 件ごとに、自分たちのインフラへの影響を理解しなければならない、という圧力です。
こうしたチームの備えを助けるために用意されたのが、Zero Wire です。Cloudflare は「public vulnerability intelligence feed」（脆弱性の公開インテリジェンスフィード）と位置付けています。通信社のニュース配信のような分かりやすさを、重大なセキュリティの動きにもたらす、という狙いです。
1件ごとのカードに入っていること
各ブリーフィングにまとめられるのは、次の4つです。形式は、意図的にシンプルな索引カード（index card）にした、と書かれています。
| 項目 | 中身 |
|---|---|
| 平易な説明 | 脆弱性で何が起きるのか |
| 誰が調べるべきか | どのチーム・どの環境が確認の対象か |
| 推奨する対応 | 次に取るべき対応 |
| 根拠へのリンク | CVE レコード、研究、CISA の Known Exploited Vulnerabilities カタログ、ベンダーの案内など |
脆弱性が載る範囲
Zero Wire は、すべての CVE を網羅するカタログではありません。ベンダーの勧告や、脆弱性データベースを補うもの、と Cloudflare は説明しています。
対象は、インターネットに公開されたソフトウェアの重大な CVE に絞られます。具体的には、Web アプリ、それが依存するランタイムやライブラリ、インターネットに公開されたサービスなどです。どれも、プロキシが悪用の緩和に役立ち得る領域とされています。
ここで大事な点があります。WAF ルールのような Cloudflare 専用の防御があることは、掲載の条件ではありません。Cloudflare が検査できる通信の外で、ベンダーの更新などが必要な問題もある、と書かれています。
脆弱性のカードの読み方
「Needs attention」と「Reference」の2区分
トップページは、2つの区分に分かれています。
- Needs attention: 積極的な評価や対応が必要なもの。悪用が知られているもの、案内がまだ動いているものを含みます
- Reference: 案内が落ち着いたもの
注意したいのは、Reference に移っても、影響するすべてのシステムが修正済みという意味ではないことです。
脆弱性が古くても、対応を終えていない組織には関係し得る、と Cloudflare は書いています。
状態と最終確認日は「自分の環境の判定」ではない
各カードには、状態と最終確認日（last-checked date）が付きます。悪用の確認、調査中、ベンダーの修正の提供は、それぞれ別のことを表しています。Cloudflare は、これを自分の環境への判定として扱わないよう求めています。ブリーフィングの根拠と合わせて読む、という使い方です。
探し方と、前回からの変化の追い方
- トップページでは、CVE 番号や問題名で検索でき、技術タグで関連する項目をたどれます
- 1つのブリーフィングが、関連する複数の CVE をまとめることもあります
- 更新履歴（update chronology）に、新しい勧告や、根拠・対応の案内の変化が記録されます。最終確認日と合わせて、前回見たときからの変化を確かめられる、としています
AI エージェント用のプロンプトも用意されている
脆弱性の影響を評価するための、用意済みのプロンプトも Cloudflare は提供しています（php2shell のブリーフィングにも掲載）。自分の AI エージェントに渡して、インフラへの影響を調べる使い方です。
プロンプトが求めるのは、読み取り専用の評価です。評価の対象は、導入されているソフト、該当するベンダーの修正、露出、補完的な対策です。資産ごとに、根拠・分からない点・次の対応をまとめるよう頼む文面になっています。なお、プロンプトをコピーするだけでは、システムをスキャンも変更もしないと書かれています。
脆弱性の一覧（2026年11月5日時点）
脆弱性のカードは、2026年11月5日時点で、Zero Wire のトップページに次のように並んでいました。掲載内容は今後変わり得ます。
| 区分 | 項目 | CVE |
|---|---|---|
| Needs attention | Linux IPv4 TCP use-after-free | CVE-2026-98432 |
| Needs attention | php2shell | CVE-2026-109618、CVE-2026-109619、CVE-2026-115560 |
| Needs attention | eMudhra certificate compromise（eMudhra の証明書の侵害） | カードに CVE 番号の表示なし |
| Needs attention | node2shell（Brotli デコーダーの欠陥） | CVE-2026-111497 |
| Needs attention | Citrix NetScaler command execution（コマンド実行） | CVE-2026-88771 |
| Reference | WordPress SQL injection and RCE | CVE-2026-60137、CVE-2026-63030 |
脆弱性の例: php2shell と WordPress のサイト
プラグインの更新だけでは直らない
Cloudflare は発表の中で、php2shell を例に挙げています。php2shell は PHP のランタイムの欠陥です。WordPress や Magento を動かすチームにとって、アプリのコードやプラグインの更新だけでは、土台のランタイムは直らない、という説明です。
どんぶりで言えば、上に載った具（プラグイン）を替えても、下のごはん（PHP 本体）が傷んでいたら直らない、という話ですね。
脆弱性の悪用の状況は、ブリーフィングによると次のとおりです。CISA は、CVE-2026-109618 と CVE-2026-109619 を KEV（悪用が確認された脆弱性のカタログ）に登録しています（2026年10月26日に追加）。関連する CVE-2026-115560 は、ブリーフィングが参照した出典では悪用が確認されていない、としています。PHP 5.4 以降を動かすチームは、元の2件を確認すべきだ、と書かれています。
この件の経緯は、PHP の緊急の脆弱性 2 件の予告を扱った記事でも取り上げています。
ブリーフィングが示す5つの手順
php2shell のブリーフィングには、次の5つの手順が並んでいます。
- インターネットに公開された PHP アプリを洗い出し、ランタイムの版を把握する
- PHP プロジェクトのセキュリティ更新を適用する（マネージドホスティング経由の場合も含む）
- CVE-2026-115560 は、セッションのアップロード進捗に関する勧告を、アプリのシリアライザーの変更も含めて別に確認する
- 不審な PHP リクエストについて、ログと対応の手順を確認する
- 更新を展開している間は、エッジの緩和策を有効のままにする
WAF があっても、脆弱性の修正は省けない
WAF のリンクは「設定を見に行く入口」
脆弱性（CVE）のうち WAF ルールで対処できるものは、ブリーフィングにその有無と設定の要件が書かれます。該当する場合は、有料プラン向け・無料プラン向けに、ダッシュボードの該当設定へのリンクが置かれます。ただし、このリンクはルールを自動で有効にしたり、導入を検証したりはしません。自分で設定を確かめる必要があります。
修正の代わりにはならない
WAF による緩和は、対象の通信に対する補完的な対策です。Cloudflare 自身が、脆弱なソフトの修正の代わりではない、と書いています。リクエストを止めても、オリジン（サーバー側）で既に行われた動作は元に戻せません。セキュリティチームは、常にベンダーの修正案内に従うべきだ、としています。
グラフの数字は「被害の数」ではない
php2shell のブリーフィングには、HTTP リクエストの量のグラフがあります。Cloudflare の WAF のマネージドルールに合致したリクエストの量です。この数は侵害されたシステムの数や、成功した攻撃の数ではない、と Cloudflare は発表記事で注意しています。攻撃の試みを観測しても、特定の組織が侵害されたことにはなりません。逆に、Cloudflare 上で試みが見えないことも、他所で悪用がないことの証明にはならない、とも書かれています。
脆弱性のニュースを見たら、やっておきたいこと
おすすめは次の5つです。
- 脆弱性のニュース、特に重大なものを見たら、Zero Wire の「Needs attention」に載っているかを確かめる
- カードの「誰が調べるべきか」と「What to do now」を読み、自分のサイトや社内のシステムが対象かを確かめる
- WordPress などの PHP のサイトは、プラグインだけでなく PHP 本体の版も確かめる。マネージドホスティングなら、事業者に版と対応状況を確認する
- WAF を使っていても、ベンダーの修正の適用は省かない
- 一度見たカードは、最終確認日と更新履歴で、前回からの変化を確かめる
なお、Zero Wire のページは英語で、日本語のページについては今回の発表には書かれていません。更新の知らせは、Cloudflare Radar の X（@CloudflareRadar）と Bluesky（@radar.cloudflare.com）のアカウントで行う、とされています。
2026年11月6日時点の情報です（Zero Wire の掲載内容は2026年11月5日時点）。ほかの IT の話題は、技術ネタカテゴリーからどうぞ。
ITもごはんも、腹八分目が長続きのコツ！
コメント