DDDefense DeskWordPress 緊急対応
技術資料

AIがゼロデイを自動発見する時代に中小企業のWordPressは何をすべきか

未知の脆弱性(ゼロデイ)が次々と見つかる時代に、中小企業がすべてを先回りで塞ぐのは現実的ではありません。だからこそ、攻撃の対象になる部分そのものを減らす発想に切り替えます。何から削り、どこまでWordPress静的移行で守るのか、無理なく続けられる手順を確認できます。

公開日 2026.07.09更新日 2026.10.18読了目安 5分著者 DD Defense Desk

ゼロデイが「例外」でなくなった

生成AIによる脆弱性の自動発見が進み、これまで人間が見落としていた欠陥が短時間で見つかるようになったと報告されています。2026年4月のAnthropic「Claude Mythos Preview」発表(外部サイト)はその象徴的な出来事で、Anthropicは、利用者の指示を受けたこのモデルが、主要なOSと主要なWebブラウザのすべてで未知の脆弱性を見つけ、悪用までできたと報告しています。Anthropicは発表の時点で、Mythos Previewを一般には公開せず、Project Glasswingという防御側の連合に参加する組織やオープンソースの開発者に限って提供するとしていました。Mythos Previewも次に挙げるCodexの事例も、防御側が自ら探して開発元へ知らせたもので、攻撃に使われたという報告ではありません。それでも運用側から見ると、修正が出るまでのあいだ手の打ちようがない期間は、以前より起きやすくなります。

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

中小企業がすべての脆弱性を先回りで塞ぐのは現実的ではありません。攻撃の対象になる部分そのものを減らす方向に、考え方を切り替える必要があります。

攻撃が成り立つ条件

  1. 1

    ソースコードのAI静的解析

    公開されているプラグインやWebサーバーのコードをAIに読み込ませ、未公表の欠陥を自動解析します。

  2. 2

    未公開脆弱性(ゼロデイ)の抽出

    人間が気づいていなかった複合的な処理の不備から、セキュリティ上の弱点(ゼロデイ)を特定します。

  3. 3

    修正が出ていない期間の発生

    開発元やセキュリティベンダーが把握していない段階では、更新を当てるという対処が取れません。

  4. 4

    公開側の処理が入り口になる

    公開サーバーでプログラムが動いている限り、その処理が攻撃の入り口として残ります。ここまでの段階が実際の侵入やデータ奪取に至ったという報告ではありません。

まず削るべきもの

  • 使っていないプラグイン・テーマ:有効・無効を問わず、使っていないものは削除する。導入数が多いほど攻撃の入り口が増える。
  • 不要な公開範囲:管理画面へのアクセス元を制限し、公開しなくてよい機能を閉じる。
  • 放置されたアカウント:使われていない管理者アカウントを整理し、パスワードを見直す。

攻撃の入り口を構造的に減らす

攻撃の入り口そのものを取り除く方法は、公開側でプログラムを動かさない構成にすることです。WordPressのページを事前に作り置きする“表示専用”の構成(WordPress静的移行)にすれば、WordPress本体とプラグインに由来する未知の脆弱性は、公開側から外れます。ただし公開側にはWebサーバーと配信の仕組みが残り、そちらの脆弱性は残ります。実際、2026年6月に公表された、nginxやApache httpdなどの既定の設定で成り立つ攻撃の手口は、WordPressの有無に関わらず影響します。減らせるのは入り口の数であって、ゼロにはなりません。

記事の編集は管理画面で続けられるため、日々の運用は大きく変わりません。攻撃の対象になる部分だけを公開側から切り離す、という発想です。

機能ごとに、どこまで適用できるかが分かれる

どこまで適用できるかは、いま動いている機能ごとに分かれます。次の表を、自社のサイトで動いているものに当てはめてください。

いま動いている機能確かめること確かめた結果ごとの行き先
記事・固定ページの表示プラグインで差し込んでいる部分(一覧の絞り込み、外部からの埋め込み)があるか無ければそのまま移せる。あれば、その部分を置き換える方法を決める
問い合わせフォーム送信先、送信内容を保存するか、添付ファイルを受けるか外部のフォームサービスへ分ける
サイト内検索対象のページ数と、絞り込みの条件少なければ閲覧側だけで完結させる。多ければ外部の検索サービスへ分ける
会員だけに見せる出し分けWordPressの会員プラグインで、会員をサイトの中で管理しているか管理しているなら静的移行には収まらない。作り替えの検討へ回す
1日に何度も変わる情報の掲載更新してから公開に出るまでの時間差を、何分まで許せるか間に合うなら作り置きの間隔を短くする。間に合わないなら静的移行には収まらない。掲載の方法を見直すか、作り替えを検討する
ECの購入手続きWordPressのECプラグイン(WooCommerce など)で、注文と在庫をサイトの中で扱っているか扱っているなら静的移行には収まらない。作り替えの検討へ回す。外部のショップや決済のサービスに預けているなら、そのまま移せる
予約の受け付けと空き状況の表示WordPressの予約プラグインで、予約をサイトの中で扱っているか扱っているなら静的移行には収まらない。作り替えの検討へ回す。外部の予約サービスに預けているなら、そのまま移せる

フォームとサイト内検索は、別の仕組みへ預けられることが多い部分です。方式ごとの違いと、選ぶ前に確かめる項目はフォームや検索を公開側の処理なしで動かす方法にまとめています。

行き先が「作り替えの検討へ回す」になった機能があるなら、静的移行では届きません。閲覧の部分は作り置きのページで配信し、会員、購入、予約の処理はサーバー側のプログラムで作り直す、作り替えの構成を検討することになります。

段階的な実行計画

  • 棚卸し:現在のプラグイン・動的機能・公開範囲を洗い出す。
  • 優先度づけ:攻撃の入り口になりやすい部分を洗い出し、静的移行に収まる機能と、作り替えに回す機能を切り分ける。
  • 移行と引き継ぎ:作り替えに回す機能が無ければ、置き換える機能を用意してから公開側をまとめて静的移行に切り替え、運用手順を引き継ぐ。作り替えに回す機能があれば、サイト全体を作り替えとして計画する。

費用対効果の考え方

静的移行には初期費用がかかります。月々の保守作業(更新確認・バックアップ・監視)は、公開側から外した範囲にかかっていた分だけ減ります。侵害が起きたときの復旧費用と機会損失は、避けられると約束できるものではありません。入り口が減る分だけ、起こる可能性が下がります。継続してかかる費用と、事故が起きたときの損失の両方を並べて比べてください。

具体的な費用の目安と変動要因は、料金・見積の考え方を確認するページにまとめています。

参考情報(外部サイト)

本文で参照した外部の公開情報です。

「塞ぎ続ける」から「対象を減らす」へ

この切り替えは、一度で全部を作り替える話ではありません。使っていない機能を外す、公開しなくてよい画面を閉じる、といった範囲から順に減らせます。

どこまで減らせるかは、いま使っている機能によって変わります。減らせない部分が残っても、残る範囲がはっきりすれば、そこに手当てを集められます。

WordPressサイトの侵害で生じる報告義務・信用・売上の負担

侵害時の報告義務と事業への負担を確認する →

← コラム一覧へ戻る

緊急対応を依頼する