Cloudflareは2026年11月3日、Cloudflare Radarのセキュリティ部門で、重大な脆弱性の解説を集約した「Zero Wire」を公開した。影響を受ける製品や環境、推奨される対処、判断の根拠、更新履歴をまとめ、AIによる脆弱性評価を支援するプロンプトも提供する。Cloudflareの顧客以外も無料で利用でき、公開された脆弱性情報を自社環境の調査につなげるための新たな情報源となる。
ただし、Zero Wireの掲載区分は情報の整理状況を示すものであり、実際の悪用の有無や、自社環境で修正が完了したかどうかとは異なる。これらを混同すると、対応の優先順位や修正完了の判断を誤るおそれがある。Zero Wireを実務に生かすには、公開情報を実際に稼働しているソフトウェアと照合することが重要だ。
重大な脆弱性の情報を集約し、具体的な対応につなげる
Cloudflareの発表によると、Zero Wireはインターネットに公開されたWebアプリや実行環境をはじめ、ライブラリや各種サービスに関わる重要な脆弱性を取り上げる。掲載対象は、CloudflareのWAF（Webアプリケーションファイアウォール）で防御できるものに限られない。WAFはWebアプリへの通信を検査して攻撃を防ぐ仕組みだが、Zero Wireはこうした防御機能の適用範囲にかかわらず、重要と判断した脆弱性を扱う。
Zero Wireの公開ページでは、各脆弱性のカードから詳細な解説を確認できる。CVE（脆弱性識別番号）や名称、技術分野のタグによる検索にも対応しており、問題の概要から影響範囲、推奨される対処まで調べられる。解説には判断の根拠や更新履歴も記載され、担当者が情報の出典や変更内容を追跡できる仕組みになっている。
一方、Zero WireはすべてのCVEを網羅するデータベースではない。掲載されていない脆弱性についても、自社のシステムが安全だと判断することはできず、ベンダーのセキュリティ勧告と自社資産の照合は引き続き必要となる。Zero Wireの役割は、重要な脆弱性について情報を整理し、調査や対応の手掛かりを一か所にまとめることにある。
「要対応」「悪用確認」「修正済み」は別の情報
Zero Wireでは、脆弱性を「Needs attention（要対応）」と「Reference（参考情報）」に分類している。前者は積極的な調査や対応が必要な項目、後者は対応指針が安定した項目を指す。Cloudflareは、Referenceに移行しても、影響を受けるすべてのシステムで修正が完了したことを意味しないと説明している。つまり、情報を提供する側の分類と、利用者側の対応状況は区別する必要がある。
攻撃の観測データについても同様だ。例えば、WAFルールに一致したHTTPリクエストの件数は、攻撃が成功した回数や侵害されたシステムの台数を示すものではない。また、Cloudflareの観測範囲で悪用が確認されなかったとしても、それ以外の環境で攻撃が発生していないとは限らない。
Zero Wireの掲載区分、実際の悪用を裏付ける証拠、ソフトウェアの修正状況は、それぞれ独立して確認する必要がある。以下の表は、2026年11月5日に取得した公開資料を基に、Cloudflareの分類、米国サイバーセキュリティ・インフラセキュリティ庁（CISA）の悪用情報、PHP公式の修正情報を整理したものだ。php2shellの評価プロンプトで扱われる脆弱性を例に、それぞれの情報から判断できることと、判断できないことを比較している。
| 表示・証拠 | 分かること | それだけでは分からないこと |
|---|---|---|
| Needs attention／Reference | Cloudflareが判断した調査・対応の必要性や、指針の安定度 | 自社への影響や修正の完了状況 |
| WAFルールに一致したリクエスト | Cloudflareが観測した、該当ルールに一致する通信 | 侵害台数、攻撃成功件数、観測範囲外での悪用 |
| CISAのKEV掲載 | 悪用が確認された脆弱性のカタログに、CVE-2026-109618とCVE-2026-109619が10月26日に追加されたこと | 自社が侵害されたか、後続のCVE-2026-115560にも同様の悪用証拠があるか |
| PHPの修正版と適用条件 | PHP公式の公開情報に記載された、先行2件の修正版と後続1件の発生条件 | 自社で稼働するPHPに修正が適用され、プロセスの更新まで完了したか |
修正版が公開され、Zero WireでReferenceに分類されていても、自社では古いソフトウェアが動き続けている可能性がある。反対に、観測された攻撃件数が少ないことも、修正を見送る理由にはならない。公開情報だけで個々の組織における侵害の有無や修正状況を判断することはできず、実際の稼働環境を確認する必要がある。
PHPの評価プロンプトは、実際の稼働環境まで確認する
Zero Wireのphp2shellに掲載されたAI用評価プロンプトは、関連する3件のCVEについて、影響の有無、修正状況、悪用の証拠を個別に調査するよう指示している。調査は許可されたアクセス権限の範囲内で、読み取り専用の操作に限定される。攻撃用ペイロードの送信、メモリを枯渇させる操作、設定変更などは禁止されており、プロンプトをコピーするだけで自動的に走査や修正が始まるわけではない。評価の精度と範囲は、AIに与えられたアクセス権限や取得できる証拠に左右される。
PHPは、WordPressなどのWebアプリケーションを動かす実行環境であり、アプリケーションを更新してもPHP自体の脆弱性が修正されるとは限らない。PHP公式は10月21日、CVE-2026-109618とCVE-2026-109619を修正したPHP 8.5.12、8.4.27、8.3.36、8.2.35を公開した。CISAは10月26日にこの2件をKEV（Known Exploited Vulnerabilities）カタログへ追加しており、実際の悪用が確認された脆弱性として扱っている。
一方、後続のCVE-2026-115560は発生条件が異なる。10月23日のPHP公式勧告によると、この問題はアップロード進捗機能が有効で、アプリケーションが実行時にセッションのシリアライザーを切り替えるという特殊な条件下で発生する。したがって、先行2件の脆弱性に対応しただけで、関連するすべての問題が解決したと判断することはできない。設定とアプリケーションの動作を個別に確認する必要がある。
また、先行2件がKEVに掲載されたことを根拠に、後続のCVE-2026-115560も悪用されていると判断することはできない。11月5日時点で取得した資料からは後続の脆弱性の悪用を確認できないが、これは悪用が存在しないことを証明するものでもない。脆弱性の存在、悪用の証拠、修正の適用状況は、それぞれ別の根拠に基づいて評価しなければならない。
php2shellの評価プロンプトで特に重視されているのは、実際にWebリクエストを処理しているPHPの状態を確認することだ。コマンドラインで実行するCLI版のバージョン表示や、ソースコードのリポジトリに記載された設定、使用されていないコンテナイメージだけでは、稼働環境の安全性を判断できない。更新後には、実際の稼働プロセスに加え、複製された実行環境についても確認するよう指示している。ファイルやイメージの更新記録と、リクエストを処理するプロセスが修正版へ切り替わった証拠を区別するためだ。
ただし、古いバージョン番号が見つかっても、直ちに脆弱だと判断するわけではない。Linuxディストリビューションなどのベンダーが、既存バージョンにセキュリティ修正を取り込む「バックポート」を実施している場合もある。そのため、単純なバージョン比較ではなく、ベンダーの修正情報と実際の稼働環境を照合することが求められる。
WAFによる防御だけでなく、修正と更新状況の追跡が必要
WAFによる防御を確認する場合も、対応するルールが存在するだけでは十分ではない。php2shellの評価プロンプトでは、対象の通信がCloudflareのプロキシを経由しているか、WAFルールが「Block」に設定されているか、例外設定や迂回経路が存在しないかを個別に確認するよう指示している。設定画面へのリンクが用意されていても、それだけでルールの有効化や防御の確認が完了するわけではない。
WAFは対象トラフィックへの攻撃を防ぐ補完的な対策であり、脆弱なソフトウェアそのものを修正するものではない。すでに侵害された可能性がある場合には、その調査も別途必要になる。WAFの設定確認と並行してPHPの修正を適用し、更新後のプロセスが実際に修正版へ切り替わっているかまで確認することが重要だ。
Zero Wireには、脆弱性情報の更新を追跡する仕組みも用意されている。サイト全体またはタグ単位のRSSを利用できるほか、Cloudflare Radarの公式変更履歴によると、ホーム画面の「Caught on Radar」からも更新情報を確認できる。各脆弱性の更新履歴と組み合わせれば、推奨される対処や影響条件が当初の案内から変更されたかを把握できる。
Zero Wireの価値は、単に重大な脆弱性を一覧できることだけではない。新たな勧告や悪用情報を、自社で稼働するソフトウェアや設定と結び付け、必要な調査と修正につなげられる点にある。最終的に重要なのは、公開情報の更新を追うだけでなく、実際の稼働環境で対策が完了したことまで確認できる運用体制を整えることだ。
