脆弱性の公開から数時間で悪用の試行が始まることもある、更新が間に合うサイトの条件

攻撃が集中した脆弱性では、悪用の試行まで数時間のこともある

WordPressの脆弱性情報を集めているセキュリティ企業Patchstackは、2026年の調査（外部サイト）で悪用が始まるまでの時間を集計しています。同社によると、悪用活動の多いWordPressの脆弱性群について、公開（Patchstackが防御ルールを配信した時点）から最初の悪用試行までの時間を、観測された攻撃量で重み付けした中央値が5時間でした（2025年に公開された脆弱性についての観測）。全脆弱性の平均ではなく、実際に攻撃が集中した脆弱性群の値です。

Patchstackは同じ調査で、独自の優先度の区分の「高」を、すでに悪用されているか、一斉に悪用される見込みがある脆弱性としています。一斉攻撃では、条件に合うサイトを探して試す工程が、人手を待たずに進みます。公開された内容を落ち着いて確認し、影響を調べてから更新する、という進め方では間に合わない場面があります。

個別の脆弱性でも、公開の当日に試行が観測された例があります。WordPressが2026年9月22日に7.1.2（外部サイト）で直した本体の脆弱性は、条件がそろうと、ログインしていない相手がサーバー上でプログラムを実行できるものでした。

Patchstackは、7.1.2が公開されたのと同じ9月22日のうちに、この脆弱性を狙う試行を観測したとしています。試行はその後、サーバーへファイルを書き込もうとするものまで広がったと報告しています（外部サイト）。

米国の政府機関CISAは9月25日に、この脆弱性を悪用が確認された脆弱性の目録（CISA KEV）（外部サイト）に載せました。

CISAの基準（外部サイト）では、目録に載るのは、悪用（失敗に終わった試みを含む）の確かな証拠がある脆弱性で、探索されただけでは載りません。

悪用を組み立てる工程をAIでどこまで進められるかも、計測されています。2026年4月、AnthropicはAIのモデル「Claude Mythos Preview（外部サイト）」を発表しました。汎用の言語モデルですが、セキュリティの作業でとくに能力が高いため、Anthropicは発表の時点で、一般には公開せず、防御を目的としたProject Glasswingという連合に参加する組織やオープンソースの開発者に限って提供するとしていました。

Anthropicは2026年6月の報告（外部サイト）で、Firefoxで直された18件の脆弱性について、公開された修正をMythos Previewに渡し、コードの実行まで到達する攻撃用コードを、渡してから約12時間で8件作れたと報告しています（最初の1件は約1時間）。攻撃者による悪用ではなくAnthropic自身のFirefoxでの実験で、WordPressに同じ速さが当てはまるかは確かめられていません。

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

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

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

中小企業の侵害でも、入口として最も多いのは脆弱性の悪用です。Verizonが2026年5月に公開した年次の侵害調査（外部サイト）では、侵害の最初の入口として最も多かったのは脆弱性の悪用で、入口が分かっている侵害（人的ミスと内部の不正を除く）の31%でした。同社によると、中小企業の事案（7,256件、うち漏えいを確認したもの7,152件）に絞っても、侵害の入口の内訳で最多は変わらず、26%です。同社は、認証情報の悪用が13%、フィッシングが9%と続くと報告しています。同社の調査の対象は145か国の組織が関わる事案で、日本国内の統計ではありません。組織の侵害全体の集計で、Webサイトに限った数値でもありません。

WordPressでは、一斉試行がとくに効きます。同じプラグインが多数のサイトで使われているため、一つの脆弱性で多くのサイトが同時に条件に合致します。

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

最初の節で挙げた、2026年9月に本体で直された脆弱性も、珍しい構成だけが対象ではありませんでした。WordPressの開発者によると、成り立つには、有効なテーマの直下に名前が page- で始まるフォルダーがあることと、サーバー上の特定のPHPファイルを読み込めることの両方が要ります。WordPressの開発者は、テーマの側ではWordPressに付属していた古い標準テーマのうち2本（Twenty Twelve と Twenty Fourteen）と広く使われている一部のテーマ、サーバーの側ではPHP 8.5より前を使うcPanelの標準の構成が当てはまると公表しています（外部サイト）。当たるかどうかを決めるのは、サイトの規模ではなく構成です。

侵害されたサイトがその後どう使われるかは、偽CAPTCHAで踏み台になる仕組みを確認すると分かります。

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

自社のプラグイン更新が週単位や月単位になっている場合、あるいはサイトの担当者が他の業務を兼務している場合を考えます。この運用は、それ自体が怠慢というわけではありません。悪用の試行が始まるまでの猶予が、次の更新までの間隔より長い脆弱性であれば、間に合います。

本体の修正は、間を置かずに出ることがあります。WordPressは2026年9月17日に7.1.1（外部サイト）を出し、9月22日には最初の節で挙げた7.1.2を出しました。

さらに10月6日に7.1.3（外部サイト）を出し、1か月足らずのうちに3回、セキュリティの修正を配布しました。本体の自動更新を止めている運用では、そのたびに適用を判断することになります。

更新に慎重になる理由もあります。プラグインを更新すると表示が崩れたり、フォームなどの機能が動かなくなったりすることがあるため、本番に適用する前に確認する運用をとっている場合です。確認そのものは妥当な手順ですが、公開から数時間で悪用の試行が始まる脆弱性では、確認にかかる時間がそのまま露出時間になります。

最初の節で挙げた5時間は、個々の脆弱性に共通する期限ではありません。攻撃が集中した脆弱性群について、観測された攻撃量で重み付けした中央値です。自社が直面する脆弱性の猶予を測る目盛りとしては使えません。そのうえで、自社の側で使っている時間を出しておきます。「更新が間に合っているかを見分ける」の節の5項目のうち、当て終えるまでの時間を決めるときの出発点になります。脆弱性の公表を知るまでの遅れ、影響を判断する時間、検証の時間、適用の時間を足すと、実際に使っている時間が出ます。営業時間内だけ確認する運用では、夜間や休日に公表された分だけ、公表を知るまでの遅れが長くなります。

実際に観測された悪用も、早い段階で始まっています。CrowdStrikeが2026年8月に公開した年次の報告（外部サイト）では、2026年1月から6月に同社が観測した悪用のうち、実証コード（脆弱性を突けることを示すコード）が公開されていた脆弱性への悪用の88%は、実証コードの公開から48時間以内でした。同社は、深刻度の高いWebアプリケーションの脆弱性1件で、公表から24時間以内に攻撃を始めた攻撃者のグループも確認したと報告しています。

塞ぐ側にかかっている時間も測られています。測られているのはWordPressのプラグインではなく、組織が使う機器やソフト全般で、集計も世界全体のものです。Verizonの同じ調査では、CISA KEVに載るもののうち、2025年のあいだに完全に修正し終えたものは26%で、前年の38%から下がりました。同社によると、修正し終えるまでの期間の中央値は43日で、前年の32日から伸びています。

つまり、更新が間に合わないのは特別な事情がある場合ではありません。通常どおりに運用していても、公開のタイミングによって間に合わなくなります。定期の更新をこまめにしていても、次の定期更新を待つ運用では、猶予の短い脆弱性には間に合いません。

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

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

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

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

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

間に合わないまま運用が続けば、影響が及ぶ期間もそのぶん延びます。

更新が間に合っているかを見分ける

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

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

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

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

前節の条件に欠けがあるなら、欠けている条件ごとに手段が変わります。公表を知る遅れは脆弱性情報の監視で、当て終えるまでの時間は緊急更新の手順で、夜間・休日の空白は不在のときの代わりを含めた担当で、誰が行うかは担当の取り決めで埋めます。検知の欠けは、検知の仕組みを足して埋めます。これらを運用で満たせるなら、更新で間に合わせる方向で進められますが、修正が出ていない脆弱性の分は残ります。その分を、悪用の通信を遮断する仕組みで受ける方法もあります。ただし、遮断の仕組みにも止められる範囲の限りがあります。Patchstackが同じ報告で、2025年にホスティング会社などが使う一般的な防御（WAFやCloudflareなど）に攻撃を当てた試験では、悪用が確認された脆弱性へのWordPressに固有の攻撃のうち、止められたのは12%でした。この試験は修正の有無で脆弱性を分けておらず、修正が出ていない脆弱性に限った値ではありません。これは一般的な防御の成績で、同じ報告はWordPressの脆弱性に合わせて遮断の規則を配る自社の仕組み（仮想パッチ）も紹介しています。どの仕組みでどこまで止められるかは、仕組みごとに確かめる必要があります。満たせない場合は、公開側の構成を変える方向も比較の対象になります。

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

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