WordPressの更新を追っていても残る危険

生成AIによる脆弱性の発見と、公表から悪用までの時間

2026年4月、AnthropicはAIのモデル「Claude Mythos Preview（外部サイト）」を発表し、利用者の指示を受けたこのモデルが、主要なOSと主要なWebブラウザのすべてで未知の脆弱性を見つけ、悪用までできたと報告しました。報告のとおりなら、AIが未知の脆弱性を見つけ、悪用まで組み立てられることになります。

Anthropicは発表の時点で、Mythos Previewを一般には公開せず、Project Glasswingという防御側の連合（外部サイト）（AWS・Apple・Cisco・CrowdStrike・Google・Microsoftなど）に参加する組織やオープンソースの開発者に限って提供するとしていました。WordPressの側では、Mythos Previewの報告とは別の調査として、脆弱性の公開から悪用の試行が始まるまでの時間の短さを示すデータが2026年に公表されています。

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

AIを使った脆弱性の発見は、Mythosのほかにも公表されています。2026年6月には、セキュリティ企業Califの研究者Quang Luong氏がOpenAIのコーディングエージェント「Codex」にコードを読ませ、nginxやApache httpdなど主要なWebサーバーソフトウェアを止める攻撃が成り立つ組み合わせを見つけたことが公表されています（通称「HTTP/2 Bomb」。Apache httpdではCVE-2026-49975（外部サイト））。組み合わせた2つの攻撃の手法はどちらも10年前から公開されていましたが、Califが確認できた限り、これらのサーバーに対して2つを組み合わせた人はいませんでした。WordPressを支える基盤ソフトウェアの側でも、AIを使った発見の公表があったことになります。

これらは別々の調査です。AIによる脆弱性の発見の報告は2026年のもので、公表から悪用までの時間の短さは2025年に公表された脆弱性についての観測です。AIの報告が示すのは、脆弱性を見つける手間と悪用を組み立てる手間が、どちらも小さくなりうることです。ただし、時間の短さのうちどれだけがAIによるものかは、どの資料も示していません。運営者にとって効いてくるのは原因の内訳ではなく、実際に使える時間が短いという事実のほうです。

「更新すれば安全」と言い切れない理由

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

実際には、月次の更新を待つあいだに、悪用の試行が先に始まる脆弱性があります。公表から数時間のうちに適用を終える運用は、専任の担当者がいなければ現実的ではありません。

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

速さを詰める方向には上限があります。攻撃が集中する脆弱性では、公表から数時間で試行が始まることがあります。公表が金曜の夕方であれば、月曜の始業を待つあいだに、その時間帯へ入ることがありえます。

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

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

運営者から見れば、公式に配布されているプラグインを使っていただけです。開発元の配布物そのものに仕込まれていたため、更新を欠かさないことが防御になりません。供給網（サプライチェーン）を狙う形と呼ばれます。

仕込まれたコードは、入った時点では何もしません。Patchstackの分析（外部サイト）によれば、開発元のドメインが特定の応答を返したときに初めて動き、ファイルの書き込みや命令の実行が行われる作りでした。コードは、通常の互換性の更新に見せかけて、すべてのプラグインに入れられたとされています。各サイトが更新で受け取ったのか、新しく導入して受け取ったのかの内訳は公表されていません。

2026年6月のThe Hacker Newsの報道（外部サイト）によれば、別のプラグイン開発元（ShapedPlugin）の有料版のプラグインに、開発元の正規の更新の経路からバックドアが配られていました。WordPress向けのセキュリティ企業Wordfenceは開発元の作成・配布の仕組みが侵害されたとみており、開発元は更新の経路で配った版が改ざんされたと説明しています。WordPress.orgで配られている無料版は影響を受けていません。ただし、公式のディレクトリから入れたことも安全の根拠にはならず、Essential Pluginの件はそこで起きています。開発元の管理体制は利用する側から見えず、どこから入れたかでは、この種の危険は判断できません。

更新の記録を見返しても、不正なコードが混ざったことには気づけません。気づくきっかけは、配布元やプラグインの審査チームからの告知、サーバー会社からの検出通知、閲覧者からの指摘といった外側からになります。Essential Pluginの件では、WordPress.orgのプラグインの審査チームが、バックドアの除去と管理者への警告を試みる更新を、強制的に配りました。通知が届いたときの確認手順は改ざん検知・不正ファイル検出への対応にまとめています。

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

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

侵害されたサイトの被害は、運営者自身にとどまらないことがあります。閲覧者など他者への攻撃の踏み台として使われる場合があるためです。例として、Proofpointが2025年10月に公表した報告（外部サイト）は、侵害された正規のサイトに不正なスクリプトを埋め込み、偽のCAPTCHA（人間かどうかを確かめる画面）を重ねて表示させ、閲覧者に画面の指示どおりの操作をさせて感染させる手口を追跡しています。

Check Point Research（外部サイト）は2026年8月、攻撃者が侵害したWordPressのサイトにプラグインを入れ、Windowsの閲覧者には元のページに重ねて偽のCAPTCHAの画面を出していたと報告しています。配信場所にされると、運営者は自社のサイトを通じて、閲覧者を攻撃する側に回ります。

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

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

記事の前半で見た速さの差と、供給網を狙う形は、どちらも運用の頑張りだけでは消しきれません。速さの差は手順を足せば縮められますが、夜間や休日の空白は残りやすく、供給網を狙う形は自社の作業と関係なく起こります。

自社の更新が間に合う範囲にいるかどうかは、緊急のときに何時間で更新を当てられるか、脆弱性の公表を知る速さ、担当者が不在になる時間、外から指摘される前に異常に気づけるかから見当がつきます。範囲の中にいて、それぞれを誰が行うかも決まっていれば、速さの差と気づくまでの遅れは運用で抑えられる見込みがあります。それでも安全が保証されるわけではなく、供給網を狙う形は範囲の中にいても残ります。

範囲の外にいるなら、どこで外れているかで打つ手が変わります。公表を知るのが遅い、緊急のときに当てるのが遅い、担当者が不在の時間が長い、誰が行うかが決まっていない、のどれかなら、まず脆弱性の公表を追う仕組みと緊急更新の手順、不在のときの代わりを含めた担当を用意して、運用で補えるかを確かめます。運用で補うには、人手と費用が継続的にかかります。補えなければ、更新の遅れが公開側の侵入口にならない構成へ変えることを考えます。外から指摘される前に異常に気づく手段が無いなら、ほかの欠けがあってもなくても、検知を足します。検知は、間に合わなかったときの被害を抑えるもので、更新を間に合わせるものではありません。どの打つ手も、供給網を狙う形を消すものではありません。構成を変えた場合に変わるのは、仕込まれたコードが公開側で直接動くかどうかです。

更新が間に合う条件を確認する →

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

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

編集用のWordPressを残すため、記事を書く操作は管理画面のまま大きく変わりません。変わるのは、プレビューや予約公開のやり方と、編集してから公開に反映されるまでの待ち時間です。

編集用の環境のWordPressは残ります。そこが侵害されれば、書き出したページに不正なコードを混ぜられるおそれがあるため、編集用の環境は非公開の場所に置き、接続できるアクセス元を限ったり、サイトの手前に認証をかけたりして、接続できる相手を絞ります。そうすれば、いまのように誰でも接続できるサイトでWordPressを動かすより、更新の遅れを外から突かれる範囲を狭くできます。

どの機能をそのまま移せるかは、サイトの構成によって変わります。機能ごとの見分け方は、WordPress静的移行の技術的な仕組みを確認すると分かります。