脆弱性の公開から悪用までが短くなった、更新の速さで守れる条件

なぜ「約10時間」なのか

セキュリティ企業ZeroFoxの2026年の分析（外部サイト）では、脆弱性の公開から実際の悪用が始まるまでの猶予は、2018年の756日から2026年には約10時間まで縮まったと報告されています。

WordPress専業のPatchstackも2026年の調査（外部サイト）で近い値を挙げています。悪用活動の多いWordPressの脆弱性群について、最初の悪用試行までの時間を観測された攻撃量で重み付けした中央値が5時間でした（2025年時点）。全脆弱性の平均ではなく、実際に攻撃が集中した脆弱性群の値です。

猶予が短くなった背景として、両社とも攻撃側で自動化できる工程が増えていることを挙げています。脆弱性情報の収集、攻撃コードの作成、対象サイトの探索は、以前より人手を要さなくなりました。公開された内容を落ち着いて確認し、影響を調べてから更新する、という進め方は通用しにくくなっています。

公開された修正から悪用が組み上がるまでの時間は、実測されています。Anthropicは2026年6月の報告（外部サイト）で、Firefoxの148と149で修正された18件について、回帰テストを除いた公開差分と深刻度、修正前後のビルドだけを与える条件で計測しました。14件で修正前のビルドをクラッシュさせる実証コード（脆弱性が成立することを示す最小の攻撃用コード）ができ、うち8件は約12時間でコードの実行まで到達しています。最初の1件にかかったのは約1時間でした。対応するFirefoxの公開までは中央値で19日あり、修正が利用者へ届くより先に、悪用の準備が整う時間差があります。

脆弱性を見つける側でも自動化が進んでいます。2026年4月、AnthropicはClaude Mythos Previewを発表しました（外部サイト）。防御と研究を目的とした取り組みで、Mythos自体は攻撃者に公開されず、Project Glasswingという防御側の連合にのみ提供されています。

2026年6月には、研究者がOpenAIのコーディングエージェント「Codex」にコードを読ませ、10年前から公開されていた2つの挙動を組み合わせると攻撃が成り立つことを見つけました（CVE-2026-49975（外部サイト））。Mythosの発表とCodexによる発見が、約10時間という数字を作ったわけではありません。ただし、見つかる脆弱性の数が減る材料でもありません。

小さいサイトも試行の対象になり得る

公開された脆弱性の悪用は、多くが自動化された一斉試行として進みます。使われているプラグインの名称や版数は、公開ページの出力などから推定できる場合があります。そのため、条件に合うサイトをまとめて探し、見つかった順に試す形になります。ここで手掛かりになるのは、該当する版が外部から到達できる状態にあるかどうかです。

「自社は小さいから狙われない」という見立ては、猶予の長さを判断する材料になりません。約10時間という数字は、特定の企業が個別に選ばれるまでの時間ではなく、公開された脆弱性の悪用が始まるまでの時間です。狙いを定めた攻撃が別にないという意味でもありません。ただし、露出を手掛かりに探索する一斉試行では、小規模なサイトも対象になり得ます。

WordPressではこの探し方がとくに効きます。同じプラグインが多数のサイトで使われているため、一つの脆弱性で多くのサイトが同時に条件に合致します。冒頭に挙げた2つの数字は測定対象も集計方法も違うため、どちらが短いかを比べる意味はありません。ただしどちらの調査でも、悪用が始まるまでの単位は時間で観測されています。

対象になるのはプラグインだけではありません。2026年7月、セキュリティ企業のSearchlight CyberがWordPress本体の脆弱性（外部サイト）を公表しました。プラグインを何も入れていない標準の構成で、ログインしていない相手から任意のプログラムを実行できる状態でした。修正はWordPress 7.0.2と6.9.5で配布されています。使うプラグインを絞り込んでいても、本体の側が条件に合うことがあります。

侵害されたサイトがその後どう使われるかは、偽CAPTCHAで閲覧者が被害を受ける流れを確認するで具体的に説明しています。

特別な事情がなくても間に合わなくなる

自社のプラグイン更新が週単位や月単位になっている場合、あるいはサイトの担当者が他の業務を兼務している場合を考えます。この運用は、それ自体が怠慢というわけではなく、更新に数日の猶予があった時期には十分に機能していました。

更新に慎重になる理由もあります。プラグインを更新すると表示が崩れたり、フォームなどの機能が動かなくなったりすることがあるため、本番に適用する前に確認する運用をとっている場合です。この確認の時間は、猶予が数日あった時期には妥当な手順でしたが、猶予が短くなった現在は、それ自体が露出時間になります。

ZeroFoxが2026年について掲げた約10時間は、個々の脆弱性に共通する期限ではありません。原文は母集団も算出方法も示していないため、自社が直面する脆弱性の猶予を測る目盛りとしては使えません。読み取れるのは、公開から悪用までの間隔が2018年と比べて大きく縮んだ、という傾向までです。そのうえで、更新の速さに頼れるかどうかは、自社の側の時間で判定できます。脆弱性の公表を知るまでの遅れ、影響を判断する時間、検証の時間、適用の時間を足すと、実際に使っている時間が出ます。営業時間内だけ確認する運用では、公表を知るまでの遅れがそこに加わります。

実際に観測された悪用も、同じ時間帯に集中しています。CrowdStrikeが2026年8月に公開した年次の報告（外部サイト）では、2026年1月から6月に同社が観測した悪用のうち、実証コードが公開されていた脆弱性については88%が公開から48時間以内でした。重要なWebアプリケーションの脆弱性では、公表から24時間以内に攻撃を始めた攻撃者も確認されています。

つまり、更新が間に合わないのは特別な事情がある場合ではありません。通常どおりに運用していても、公開のタイミングによって間に合わなくなります。更新をこまめに行っているかどうかとは別の問題として、この状態が起きます。

間に合わなかったサイトで何が起きるのか

侵害の現れ方は手口によって違います。データの持ち出しや管理画面の乗っ取り、サイトの停止に至る場合もあります。一方、閲覧者へ不正な内容を配信する形では、サイトはそのまま動き続けます。表示は変わらず、書き換えられるのは閲覧者に届く中身だけです。

後者では、運営担当者が侵害に気づきにくくなります。表示できない、注文が入らないといった業務上の異常が出ないため、社内で問題として扱われるきっかけがありません。攻撃を受けた事実は、外部からの指摘や警告表示で初めて表に出ることが多くなります。

この状態が続くと、影響は自社サイトの復旧では終わりません。改ざんされた内容が表示された期間の閲覧者にも影響が及び、取引先や顧客からの指摘で発覚することもあります。損失がどこまで及ぶかは侵害時に自社が負う負担の範囲を確認するにまとめています。

検索エンジンやブラウザが警告表示を出す、サーバー会社から利用停止の予告が届く、といった形で外部から知らされることもあります。この時点では、いつから続いていたのかが分かりません。記録が不足していると、影響を受けた期間や閲覧者の範囲を後から特定できないことがあります。

更新が間に合わなかったこと自体より、間に合わないまま運用が続くことのほうが損失を大きくします。

更新の速さで守れているかを見分ける

更新の速さで守るには、役割の違う3つがそろっている必要があります。悪用が始まる前に更新を当て終えること。間に合わなかったときに早く気づくこと。そして、どちらも誰が行うかが決まっていることです。次の5項目は、順に「当て終える」が3つ、「早く気づく」が1つ、「担当」が1つにあたります。間に合わない条件のほうは数え切れませんが、そろえるべき条件は限られます。どれも技術的な調査は不要ですが、そろっていれば安全というものでもありません。プラグインの種類や公開範囲によっても実際の露出は変わります。

• 重大な脆弱性の公表を、数時間以内に知る手段がある：手段がなければ、気づくのは更新通知が届いたときになる。
• 知ってから適用まで、影響の確認と検証を含めて猶予内に終えられる：定期更新の間隔ではなく、緊急のときに何時間で当てられるかを見る。
• 夜間・休日でも、更新を判断して適用できる：担当者が不在の時間帯は、その空白がそのまま露出時間になる。
• 改ざんや不審な処理を、外部から指摘される前に検知できる：先の3つが「当て終える」ための条件で、検知は「早く気づく」ための条件にあたる。
• ここまでの4つを誰が行うかが決まっている：決まっていなければ、他の4つは条件として成立しない。サイトを外部に制作してもらった場合、双方が相手側の作業だと考えたまま止まっていることがある。

異常に気づいたときの確認項目を見る →

速さで追う以外に方向がある

前節の条件に欠けがあるなら、緊急更新の運用だけで足りるかを検討し直す段階です。脆弱性情報の監視、緊急更新の手順、WAFによる暫定的な遮断を組み合わせて満たせるなら、その方向で進められます。満たせない場合は、公開側の構成を変える方向も比較の対象になります。

自動更新を有効にすれば適用は速くなりますが、確認を省くことになるため、表示や機能が壊れたことに気づくのが利用者からの連絡になる場合があります。人手で確認すれば猶予を超え、確認を省けば別のリスクが出る、という構造は、更新の運用だけでは解けません。

配布を自動にしても、行き渡るまでには日数がかかります。先に挙げたAnthropicの報告は、Microsoftの自動更新の仕組みで更新が9割の端末へ届くまでに7日、再起動を強制するまでに11日を要すると挙げています。自動化で縮むのは判断と適用にかかる手間であって、対象の全体へ行き渡るまでの時間ではありません。

別の方向として、更新の遅れが侵害に直結しない構成にする方法があります。WordPressのページを事前に作り置きし、公開側でプログラムを動かさないWordPress静的移行にすれば、公開側のWordPress本体・PHP・データベースを攻撃の対象から外せます。どの機能をそのまま移せるかはサイトの構成によって変わるため、適用できるかどうかは個別の確認が必要です。