公表45分で数万件、2時間で数十万件。窓は、思ったより前から開いていた

• 公表後45分で数万件、2時間で数十万件、その後数百万件
• 公表の前からすでに来ていた。情報が漏れていた
• 攻撃者は、防御をかわすために中身を変えていた

今朝、この脆弱性を見つけたのもAIだったという記事を書いた。発見から公表まで63日あり、OpenAIはそれを「防御側の窓」と呼んでいた。

そこに「ただし、窓は閉じる」と書いた。

その数字が出てきた。思っていたより早く、しかも思っていたより前から開いていた。

攻撃の増え方

Cloudflareの最高経営責任者が投稿した内容として、こう報じられている。

45分で数万件だ。

人が手で試している速さではない。公表と同時に、自動で回り始めている。

いちばん重いのは1行目

公表される前の10時間で、すでに数千件来ていた。

Cloudflareのブログにも、はっきり書かれている。

脆弱性が公式のリリース日より前に漏れ、当社の顧客を狙う攻撃トラフィックを観測した。

つまり「防御側の窓」は、閉じる前にすでに隙間が空いていたことになる。

63日間、守る側だけが知っている状態が続いた——という話ではなかった。最後の数時間は、両方が知っていた。

Cloudflareは、公表の9時間前に防御を配っていた

同社のブログによれば、WAF（通信を見て不正なものを弾く仕組み）の保護は日本時間の10月21日12時2分から既定で有効になっている。

修正版の公開は同日22時40分ごろだった。約9時間前になる。

これができたのは、事前に内容を知らされていたからだ。研究者が公表前にPHP側へ報告し、PHP側が修正を作り、その間に防御側も準備する。今朝の記事に書いた流れが、ここで効いている。

無料プランにも入れた

ブログに明記されている。有料も無料も、すべてのプランで既定で展開された。

ここは評価したい。金を払っていない利用者を外さなかった。守る側の人数が増えるほど、攻撃の成功率は下がる。

攻撃側は、かわそうとしていた

ブログにもう1つ、気になる記述があった。

攻撃のペイロード（送り込む中身）が変異していくのを追跡し、ルールの論理と突き合わせながら、保護を回避しようと試みる様子を観測した。

弾かれたら、形を変えて送り直している。

2日前に書いた攻撃側がAIを使っている話で、調査会社がこう指摘していた。

今回の一連の攻撃ではWAFをバイパスするテクニックが複数使われておりました。（中略）WAFのルールをよく研究した上で攻撃してきていると感じられる攻撃手法がいくつもありました。

同じことが、今回も起きている。

では、WAFがあれば安全か

ならない。ここは誤解されやすいので、はっきり書く。

PHP公式も「完全な緩和策は存在せず、更新だけが唯一の安全な選択」と書いている。JPCERTの注意喚起も「アップデートのみが本脆弱性に対する対策」としている。

2日前の記事で引用した指摘を、もう一度置く。

WAFを導入しているからパッチ適用は必要ない（または優先度を下げてもよい）と考えている方は要注意です。

WAFは時間を稼ぐもので、更新の代わりではない。

数字をどう受け取るか

「数百万件」と聞くと、もう手遅れに思える。だが試行の回数であって、成功の回数ではない。

分けて考えたほうがいい。

1. 試された数 — 数百万件。自動で回っているので、当然多くなる
2. 通った数 — 公表されていない
3. 自分のところに来た数 — 自分で調べるしかない

3番目については、JPCERTが着眼点を出している。不自然なPHPSESSIDのCookie、異常なmultipart形式のリクエスト、メモリ制限のエラー、ワーカープロセスの異常終了。

更新した後でも、ログは見ておく。試された形跡は残る。

いまやること

1. 更新する。8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 のいずれか
2. 借りているなら、提供元の告知を見る
3. すぐ動けないなら、止めることも選択肢。公的機関がそう言っている
4. 更新後にログを見る。通った形跡がないか

4番目は見落とされやすい。直したから終わり、ではない。直す前の期間に何か通っていれば、それは残っている。

書いていて思ったこと

今朝の記事で「見つける側が速くなったぶん、使う側も速い」と書いた。数字を見ると、そのとおりだった。

ただ今回は、守る側が先に動けた例でもある。

• 研究者が63日前に見つけて、報告した
• PHP側が修正を作り、提供元に事前に配った
• 防御側が公表の9時間前に、無料の利用者まで含めて守りを配った
• 公的機関が当日のうちに注意喚起を出した

それでも公表前から攻撃は来ていた。完全には守れていない。

完全にはならない、という前提で動いているかどうか。差が出るのはそこだと思う。

まとめ

• 攻撃の試行は公表45分で数万件、2時間で数十万件、その後数百万件
• 公表前の10時間でも数千件。情報は漏れていた
• CloudflareはWAFの保護を公表の約9時間前から既定で展開
• 無料プランも含めて適用された
• 攻撃側は中身を変えながら回避を試みていた
• WAFは時間を稼ぐもので、更新の代わりではない
• 数百万件は試行の数。成功の数は公表されていない
• 更新した後も、ログは見る

出典

• Cloudflare「Cloudflare deploys protections against php2shell vulnerability」（2026年10月21日。WAFの展開時刻と公表の何時間前か、無料プランを含む適用、公式リリース前に漏れていたこと、ペイロードの変異の観測、影響を受けるPHPのバージョン範囲。引用の日本語は筆者による訳）
• 攻撃試行の件数の推移は、Cloudflareの最高経営責任者が2026年10月22日にXへ投稿した内容として、アスキーが報じたもの
• JPCERT/CC の注意喚起（緩和策の位置づけ、侵害調査の着眼点）
• PHP「Security advisory」（修正版、緩和策は完全ではないこと）

本記事は2026年10月22日時点の公表内容に基づく。件数は攻撃の試行数であり、成功した件数ではない。観測はCloudflareの環境に限られる。最新の情報は各社の発表と公的機関の注意喚起で確認すること。本記事は法的な助言ではない。