Zero Wireで重大な脆弱性の告知を読む手順

本記事はプロモーションを含みます。

はじめに: 告知のたびに、同じ材料を集め直している

重大な脆弱性の告知が出ると、確かめることは毎回同じだ。ベンダーの告知で対象の版を見て、研究者の報告で攻撃の条件を読み、悪用が始まっているかを探し、どのシステムが該当するかを洗い出す。その途中で次の告知が来る。

2026-11-03、Cloudflare がこの材料を 1 枚にまとめる Zero Wire を公開した。結論から書くと、Zero Wire は判断の出発点として使い、判断そのものはリンク先の一次情報で下す。読むときは次の 5 か所を順に見る。

以下、Zero Wire の要点を紹介し、公開時の例に挙げられた PHP の脆弱性 php2shell で、5 か所をどう読むかを書く。

何の話か: 重大な脆弱性ごとに「1 枚の説明」を出す

Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities

Zero Wire on Cloudflare Radar pairs plain-language briefings with global attack telemetry and remediation steps. Triage critical CVEs faster and decide how to protect your infrastructure.

Cloudflare Blog

• Zero Wire は Cloudflare Radar のセキュリティ欄にある、重大な脆弱性の説明の一覧だ。Cloudflare の利用者でなくても読める
• 対象は CVE の全部ではなく、インターネットに公開されたソフトウェア (Web アプリ、それが依存するランタイムとライブラリ、公開サービス) の重大な CVE に絞っている。ベンダーの告知や脆弱性データベースを置き換えるものでなく、補うものと位置付けている
• 1 枚の説明には、何が起きたか、誰が調べるべきか、今やること、根拠 (CVE の記録、研究、悪用の証拠) へのリンク、変更の時系列が載る
• 自分の環境への影響を AI エージェントに調べさせるためのプロンプトも付く
• WAF のルールがあることは掲載の条件ではない。ルールがある場合は、その範囲と設定の条件を書く

1. ホームで「状態」と「最終確認日」を見る

ホームは 2 つに分かれている。

読み違えやすいのは Reference だ。Reference に移ったことは、影響を受けるシステムが全部直ったことを意味しない。古い脆弱性でも、自分の組織が直し終えていなければ重要なままだ。

もう 1 つは最終確認日だ。カードの状態 (悪用が知られている、調査中、ベンダーの修正がある) は、それぞれ別のことを表していて、自分の環境が安全かどうかの判定ではない。最終確認日と時系列を見て、前に読んだときから何が変わったかを確かめる。

2. 重大度と悪用の有無を別々に読む

Zero Wire は、重大度と、実際に悪用されている証拠を別のものとして両方示す。判断にはどちらも要る。

php2shell では、2 つが次のように並ぶ。

PHP の告知は 2026-10-21 に出た。修正版は 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 で、mod_php ではアプリのコードが動く前に、認証なしの 1 リクエストで攻撃が始まる例が示されたため、mod_php の危険が最も高いとされた。8.1 以前は PHP の開発元からは更新が出ない。

重大度が同じ Critical でも、悪用の証拠が出たものは順番を上げる。逆に、悪用の証拠がまだ無いことは、悪用されていないことの証明ではない (4 で書く)。

KEV に載ったかを自分で引く

Zero Wire の説明は KEV にリンクしている。KEV は JSON でも配られているので、気になる製品が載ったかを手元で引ける。

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[] | select(.product=="PHP") | [.cveID, .dateAdded, .dueDate] | @tsv'

2026-11-06 版のカタログでは、先頭の 2 行が php2shell の 2 件だった。

CVE-2026-109618	2026-10-26	2026-10-29
CVE-2026-109619	2026-10-26	2026-10-29

dateAdded は KEV に載った日、dueDate は CISA が米国の連邦機関に求める対応期限だ。告知の 5 日後に載り、期限はその 3 日後に置かれた。連邦機関でなくても、悪用の証拠が出たことを確かめる手がかりになる。

3. どの層を直すかで、調べる人を決める

1 枚の説明の Overview は、何が起きたかに加えて、どのチームが調べるべきかを書く。ここで「どの層の穴か」を読む。

php2shell は PHP のランタイムそのものの穴だ。WordPress や Magento を使っていても、アプリのコードやプラグインを更新するだけでは直らない。直すのは PHP 本体で、PHP をホスティング業者が管理しているなら、業者に更新を頼む。

What to do now には、次の会話を具体的にするための問いが並ぶ。php2shell なら次の 3 つだ。

• 実際に動いているランタイムはどの版か
• ベンダーの修正は当たっているか
• 更新するのは誰か

1 つ目は、コマンドラインの php -v で見た版を答えにしない。Web のリクエストを処理しているのは PHP-FPM や mod_php で、コマンドラインの PHP と同じ版とは限らない。

告知が「ライブラリ」「ランタイム」「アプリ」のどれの穴を言っているかで、直す場所の数え方が変わる。数え方は「脆弱性の告知から影響範囲を見積もる3つの問い」に書いた。

穴がアプリのどの層で起き、どの対策がどこまで効くかを体系的に押さえておくと、告知を読んだときに調べる場所をすぐ決められる。

画像: 楽天市場

体系的に学ぶ 安全なWebアプリケーションの作り方 第3版 (徳丸浩 著、SBクリエイティブ)

楽天市場で見る

4. 攻撃の観測グラフを、被害の数と読まない

説明によっては、Cloudflare のネットワークで観測した通信のグラフが付く。php2shell の説明には、Cloudflare WAF のマネージドルールに一致した HTTP リクエストの量の推移が載っている。

このグラフは、侵害されたシステムの数でも、成功した攻撃の数でもない。攻撃者がその脆弱性をどれだけ狙っているかの目安だ。読むときは次の 2 つを分ける。

• 攻撃の試行が観測されたことは、特定の組織が侵害されたことの証明ではない
• Cloudflare のネットワークで試行が観測されないことは、ほかの場所で悪用されていないことの証明ではない

自分のシステムが侵害されたかは、自分のログで確かめるしかない。グラフは「急いで直すべきか」の判断に使い、「被害があったか」の判断には使わない。

5. WAF は修正の代わりにならない

説明の最後に、Cloudflare の WAF で緩和できるかと、その設定の条件が載る。リンクはダッシュボードの確認画面に飛ぶだけで、ルールを自動で有効にしたり、守られていることを確かめたりはしない。

php2shell では、Cloudflare は公開の約 9 時間前に WAF のルールを配り、無料プランを含む WAF の利用者は既定で守られた。有料プランは、Managed Ruleset が block で配置されているかを自分で確かめる必要がある。

それでも WAF は修正の代わりにならない。php2shell の後に、そのことを示す件が続いた。

• 2026-10-23、PHP は関連する脆弱性 CVE-2026-115560 を告知した。セッションのアップロード進捗の機能の穴で、修正版の 8.5.12 も対象に含み、次の通常リリースで直る
• Cloudflare の WAF が守るのは、アップロード進捗のフィールド名が既定のままのサイトだけだ。session.upload_progress.name を変えたサイトは、このルールでは守られない

WAF は、それが見る通信に対する補償的な対策だ。リクエストを止めても、すでにオリジンで実行された処理は戻らない。ベンダーの修正を当て、当てるまでの間を WAF で埋める。

PHP の告知が挙げる応急の設定も同じ位置付けだ。告知は、完全な解決は更新だけで、応急の設定は特定の攻撃経路を減らすが、それで安全にはならないと書いている。例えば CVE-2026-109619 には session.upload_progress.enabled=0 を挙げているが、ini_set() や FPM の .user.ini では足りず、リクエストの解析より前に効く php.ini や FPM のプールの設定に書き、ワーカーを全部再起動する必要がある。

6. AI エージェントで自分の環境を調べる

各説明には、自分の環境への影響を AI エージェントに調べさせるためのプロンプトが付く。頼む内容は次のとおりだ。

• 読み取り専用で評価する
• 動いているソフトウェア、該当するベンダーの修正、外への公開の有無、補償的な対策を調べる
• 資産ごとの証拠、分からないこと、次の対応を出す

プロンプトをコピーしただけでは、何もスキャンも変更もされない。エージェントに渡して初めて調べ始める。

使うときは、プロンプトに書かれた「読み取り専用」を、エージェントの権限でも守らせる。プロンプトに書いただけでは、エージェントが設定を書き換えたりサービスを再起動したりするのは止まらない。読み取りだけの権限で動かし、出てきた「分からないこと」は 3 の問い (誰が更新するか) に回す。

まとめ

• Zero Wire は、重大な脆弱性ごとに、何が起きたか・誰が調べるか・今やること・根拠を 1 枚にまとめる。判断の出発点にして、判断はリンク先のベンダーの告知と KEV で確かめる
• Reference は「直った」ではない。最終確認日と時系列で、前に読んだときからの変化を見る
• 重大度と悪用の有無は別に読む。KEV は JSON を jq で引ける。php2shell は告知の 5 日後に載った
• どの層の穴かで、直す人と直す場所が決まる。ランタイムの穴はアプリやプラグインの更新では直らない
• 攻撃の観測グラフは、狙われている度合いの目安で、被害の数ではない
• WAF は修正の代わりにならない。php2shell では、修正版にも残る関連の穴と、ルールが守れない設定が後から出た

ユーザーが上げた画像のように、信頼できない入力をライブラリに渡す処理をアプリサーバから外す手順は「ユーザーの画像をアプリサーバで変換しない理由と手順」に書いた。

参考

• Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities (Cloudflare Blog)
• Cloudflare deploys protections against php2shell vulnerability (Cloudflare Blog)
• PHP: News Archive - 2026 (2026-10-21 の Security advisory)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• CISA: Known Exploited Vulnerabilities Catalog
• NVD: CVE-2026-109618