なぜ「約10時間」なのか
セキュリティ企業ZeroFoxの2026年の分析（外部サイト）では、脆弱性の公開から実際の悪用が始まるまでの猶予は、2018年の756日から2026年には約10時間まで縮まったと報告されています。
WordPress専業のPatchstackも2026年の調査（外部サイト）で近い値を挙げています。悪用活動の多いWordPressの脆弱性群について、最初の悪用試行までの時間を観測された攻撃量で重み付けした中央値が5時間でした（2025年時点）。全脆弱性の平均ではなく、実際に攻撃が集中した脆弱性群の値です。
猶予が短くなった背景として、両社とも攻撃側で自動化できる工程が増えていることを挙げています。脆弱性情報の収集、攻撃コードの作成、対象サイトの探索は、以前より人手を要さなくなりました。公開された内容を落ち着いて確認し、影響を調べてから更新する、という進め方は通用しにくくなっています。
脆弱性を見つける側でも自動化が進んでいます。2026年4月、AnthropicはClaude Mythos Previewを発表しました（外部サイト）。防御と研究を目的とした取り組みで、Mythos自体は攻撃者に公開されず、Project Glasswingという防御側の連合にのみ提供されています。
2026年6月には、OpenAIのコーディングエージェント「Codex」が、nginxとApache httpdに共通する未知の欠陥を自動で見つけ、CVE-2026-49975として公表されました（外部サイト）。この2件が約10時間という数字を作ったわけではありません。ただし、見つかる脆弱性の数が減る材料でもありません。
攻撃の段階
- 1
脆弱性情報の自動監視
公表された脆弱性情報やコードリポジトリの変更を自動プログラムで常時監視します。
- 2
悪用の準備
公表された内容をもとに、悪用の手順が用意されます。この工程で自動化できる範囲が広がっています。
- 3
公表直後の試行
早い場合は公表から数時間のうちに、条件に合うサイトへの試行が観測されます。
- 4
侵入後の居座り
運営者が更新を当てる前に侵入が成立すると、そのあとも入り直せる状態を作られることがあります。
小さいサイトでも同じ速さで狙われる
攻撃の対象は、個別に選ばれるわけではありません。使われているプラグインの名称や版数は、公開ページの出力などから推定できる場合があります。そのため、条件に合うサイトをまとめて探し、見つかった順に試行する形で進みます。企業の規模や知名度は、この選別の条件になりません。
「自社は小さいから狙われない」という見立ては、猶予の長さを判断する材料になりません。約10時間という数字は、特定の企業が個別に選ばれるまでの時間ではなく、公開された脆弱性の悪用が始まるまでの時間です。試行の対象になるかどうかを左右するのは、該当する版のプラグインが外部から到達できる状態にあるかどうかです。
WordPressではこの探し方がとくに効きます。同じプラグインが多数のサイトで使われているため、一つの脆弱性で多くのサイトが同時に条件に合致します。冒頭に挙げた2つの数字は測定対象も集計方法も違うため、どちらが短いかを比べる意味はありません。ただしどちらの調査でも、悪用が始まるまでの単位は時間で観測されています。
侵害されたサイトがその後どう使われるかは、偽CAPTCHAで閲覧者が被害を受ける流れを確認するで具体的に説明しています。
特別な事情がなくても間に合わなくなる
自社のプラグイン更新が週単位や月単位になっている場合、あるいはサイトの担当者が他の業務を兼務している場合を考えます。この運用は、それ自体が怠慢というわけではなく、更新に数日の猶予があった時期には十分に機能していました。
更新に慎重になる理由もあります。プラグインを更新すると表示が崩れたり、フォームなどの機能が動かなくなったりすることがあるため、本番に適用する前に確認する運用をとっている場合です。この確認の時間は、猶予が数日あった時期には妥当な手順でしたが、10時間の猶予に対しては、それ自体が露出時間になります。
この10時間は経過時間です。営業時間ではないため、実際に手を動かせる時間は公開の時刻によって変わります。平日の朝に公開された脆弱性なら、その日のうちに尽きます。金曜の夕方であれば、月曜の始業を待つ時点ですでに超えています。営業時間内だけ確認する運用では、公開の時刻しだいで、着手する前に猶予が終わります。
つまり、更新が間に合わないのは特別な事情がある場合ではありません。通常どおりに運用していても、公開のタイミングによって間に合わなくなります。更新をこまめに行っているかどうかとは別の問題として、この状態が起きます。
間に合わなかったサイトで何が起きるのか
侵害の現れ方は手口によって違います。データの持ち出しや管理画面の乗っ取り、サイトの停止に至る場合もあります。一方、閲覧者へ不正な内容を配信する形では、サイトはそのまま動き続けます。表示は変わらず、書き換えられるのは閲覧者に届く中身だけです。
後者では、運営担当者が侵害に気づきにくくなります。表示できない、注文が入らないといった業務上の異常が出ないため、社内で問題として扱われるきっかけがありません。攻撃を受けた事実は、外部からの指摘や警告表示で初めて表に出ることが多くなります。
この状態が続くと、影響は自社サイトの復旧では終わりません。改ざんされた内容が表示された期間の閲覧者にも影響が及び、取引先や顧客からの指摘で発覚することもあります。損失がどこまで及ぶかは侵害時に自社が負う負担の範囲を確認するにまとめています。
検索エンジンやブラウザが警告表示を出す、サーバー会社から利用停止の予告が届く、といった形で外部から知らされることもあります。この時点では、いつから続いていたのかが分かりません。記録が不足していると、影響を受けた期間や閲覧者の範囲を後から特定できないことがあります。
更新が間に合わなかったこと自体より、間に合わないまま運用が続くことのほうが損失を大きくします。
更新の速さで守れているかを見分ける
更新の速さで守るには、2つの条件がそろっている必要があります。悪用が始まる前に更新を当て終えられること。そして、間に合わなかったときに早く気づけることです。間に合わない条件のほうは数え切れませんが、そろえるべき条件は限られます。どれも技術的な調査は不要ですが、そろっていれば安全というものでもありません。プラグインの種類や公開範囲によっても実際の露出は変わります。
- 重大な脆弱性の公表を、数時間以内に知る手段がある：手段がなければ、気づくのは更新通知が届いたときになる。
- 知ってから適用まで、影響の確認と検証を含めて猶予内に終えられる：定期更新の間隔ではなく、緊急のときに何時間で当てられるかを見る。
- 夜間・休日でも、更新を判断して適用できる：担当者が不在の時間帯は、その空白がそのまま露出時間になる。
- 改ざんや不審な処理を、外部から指摘される前に検知できる：上の3つが「当て終える」ための条件で、これが「早く気づく」ための条件にあたる。
- 上記の作業を誰が行うかが決まっている：サイトを外部に制作してもらった場合、双方が相手側の作業だと考えたまま止まっていることがある。
速さで追う以外に方向がある
前節の条件に欠けがあるなら、緊急更新の運用だけで足りるかを検討し直す段階です。脆弱性情報の監視、緊急更新の手順、WAFによる暫定的な遮断を組み合わせて満たせるなら、その方向で進められます。満たせない場合は、公開側の構成を変える方向も比較の対象になります。
自動更新を有効にすれば適用は速くなりますが、確認を省くことになるため、表示や機能が壊れたことに気づくのが利用者からの連絡になる場合があります。人手で確認すれば猶予を超え、確認を省けば別のリスクが出る、という構造は、更新の運用だけでは解けません。
別の方向として、更新の遅れが侵害に直結しない構成にする方法があります。WordPressのページを事前に作り置きし、公開側でプログラムを動かさないWordPress静的移行にすれば、公開側のWordPress本体・PHP・データベースを攻撃の対象から外せます。どの機能をそのまま移せるかはサイトの構成によって変わるため、適用できるかどうかは個別の確認が必要です。
参考情報（外部サイト）
本文で参照した外部の公開情報です。