WordPressの更新を追っていても危険が残るようになった理由

生成AIによって何が変わったのか

2026年4月、Anthropicが発表した「Claude Mythos Preview」は、主要なOSやブラウザの未知の脆弱性を自律的に大量発見できることを実証しました。人手では見つけるのに時間がかかっていた欠陥が、短時間でまとめて洗い出される時代になったということです。

Mythos自体は攻撃者に公開されておらず、Project Glasswingという防御側の連合（外部サイト）（AWS・Apple・Cisco・CrowdStrike・Google・Microsoftなど）にのみ限定提供されています。ただし同じ2026年、複数のセキュリティ企業が公表したデータからも、脆弱性の公開から実際の悪用が始まるまでの猶予が急速に失われている実態が裏付けられています。

ZeroFoxの2026年の分析（外部サイト）では、2018年に756日あった猶予期間が、2026年には約10時間まで縮まったと報告されています。

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

AIによる脆弱性の自動発見はMythosに限った話ではありません。2026年6月には、OpenAIのコーディングエージェント「Codex」が、nginxやApache httpdなど主要なWebサーバーソフトウェアに共通する未知の欠陥（CVE-2026-49975（外部サイト）、通称「HTTP/2 Bomb」）をコードを読むだけで発見しています。個別には10年以上前から知られていた2つの手法の組み合わせで、人間の研究者はその組み合わせに気づいていませんでした。WordPressを支える基盤ソフトウェアの側でも、同様の発見が現実に起き始めています。

これらは別々の調査です。AIによる発見や悪用の自動化が進んでいることと、公表から悪用までの猶予が縮んでいることが、同じ時期に観測されています。縮んだ分のうちどれだけがAIによるものかは、どの資料も示していません。運営者にとって効いてくるのは原因の内訳ではなく、実際に使える時間が短いという事実のほうです。

「更新すれば安全」が崩れた理由

従来の防御は、攻撃者が脆弱性を悪用できるようにするまでに時間がかかることを前提にしていました。かつては、その猶予のあいだに月次でプラグインを更新していれば、多くの攻撃を防げました。

生成AIによる脆弱性発見・悪用の高速化が進むにつれ、更新が配布される前、あるいは更新を適用する前に悪用が始まる場面が出てきました。公表から数時間のうちに適用を終える運用は、専任の担当者がいなければ現実的ではありません。

この差は、担当者がこまめに作業しているかどうかとは別のところで生まれます。脆弱性の公表を知るまでの時間、影響を確かめる時間、夜間や休日の空白。どれも通常の運用に含まれるもので、削っていくと別の危険が出ます。確認を省いて適用すれば、表示や機能が壊れたことに気づくのが利用者からの連絡になります。

速さを詰める方向には上限があります。どれだけ詰めても、公表の時刻が金曜の夕方であれば、月曜の始業を待つ時点で猶予を超えています。

更新を当てても防げない形がある

速さの問題とは別に、更新そのものが安全とは限らない場面が出ています。プラグイン開発元「Essential Plugin」では、2025年の所有権交代を機に約30本のプラグインへ休眠状態のバックドアが仕込まれました。2026年4月にそれが動き出しています。TechCrunchの報道（外部サイト）によれば、影響を受けたプラグインは2万件を超える稼働中のWordPressに入っていました。

運営者から見れば、公式の更新を普段どおり適用しただけです。開発元の配布物そのものに仕込まれていたため、更新を欠かさないことが防御にならず、むしろ配信の経路になりました。供給網（サプライチェーン）を狙う形と呼ばれます。

同じ年の6月にも、別のプラグイン開発元で配布・更新の仕組み自体が侵害される形が確認されています。開発元の管理体制は、利用する側から見えません。プラグインの評価やインストール数を見ても、この種の危険は判断できません。

更新の記録を見返しても、不正なコードが混ざったことには気づけません。気づくきっかけは、サーバー会社からの検出通知や、閲覧者からの指摘といった外側からになります。通知が届いたときの確認手順は改ざん検知・不正ファイル検出への対応にまとめています。

つまり、更新を追う運用は必要ではあっても、それだけで危険を避けきれる時期ではなくなった、ということです。速さで追いつけない分と、更新しても防げない分が残ります。

侵害されると加害者の側に回る

侵害されたWordPressは、閲覧者が被害を受けるだけでは済みません。他者への攻撃の踏み台として使われます。代表例が、閲覧者に画面の指示どおりの操作をさせて感染させる手口です。ESETの2025年上半期の脅威レポート（外部サイト）では、この検知件数が直前の半年から500%を超えて増え、フィッシングに次ぐ2番目の多さになったとされています。侵害されたサイトは、この画面を閲覧者へ配る場所として使われます。

同じ侵入から、別の使われ方をすることもあります。スパムメールの大量送信元にされる形がその一つです。閲覧者への配信とスパム送信は別の活動で、片方だけが起きている場合もあります。共通しているのは、運営者が気づかないうちに加害者の側に立たされる点です。

自社サイトが踏み台になると、ドメインやIPアドレスが迷惑メールの発信元リストに登録され、通常の業務メールまで相手に届かなくなることがあります。マイニングボットの設置やスパム大量送信が原因の場合、最初の兆候はサーバー会社からの高負荷警告として届くこともあります。被害は自社の外にも広がります。

偽CAPTCHAで踏み台になる仕組みを確認する →

運用の努力では埋まらない差が残る

ここまでの2つは、どちらも運用の頑張りで消える種類のものではありません。速さは詰めても上限があり、供給網を狙う形は自社の作業と関係なく起こります。

自社が更新の速さで守れる範囲にいるかどうかは、更新の間隔、脆弱性の公表を知る速さ、担当者が不在になる時間から見分けられます。範囲の中にいるなら、いまの運用を続ける判断も成り立ちます。

範囲の外にいるなら、埋め方は2つです。監視や緊急更新の手順を足して速さを補うか、更新の遅れが公開側の侵入口にならない構成へ変えるか。前者は人手と費用が継続的にかかり、供給網を狙う形には効きません。

更新の速さで守れる条件を確認する →

公開側から実行環境を外すという方向

後者は、公開しているサイトでプログラムを動かさない構成にする方向です。ページをあらかじめ作り置きして配信すれば、公開側に残るのは出来上がったファイルだけになります。更新が遅れても、その遅れが公開側の侵入口にはなりません。

編集の手順は管理画面に残せるため、日々の記事の追加や修正のやり方は大きく変わりません。変わるのは、外から到達できる範囲のほうです。編集用の環境は残るため、そちら側の守り方は別に要ります。

どの機能をそのまま移せるかは、サイトの構成によって変わります。仕組みと適用の条件はWordPress静的移行の技術的な仕組みを確認するにまとめています。