Mstudio
← ブログ一覧へ

WordPress自動更新のデメリット、数時間で3万台が実際に狙われた

著者: マサシ読了時間: 7分

こんにちは、マサシです。

「WordPressの自動更新は切ったほうがいい」という話を、よく見かけます。

プラグインが急に動かなくなるのが怖い、という理由がほとんどです。

その気持ちはよくわかります。

ただ、今回のニュースを見て、あらためて思ったことがあります。

「切っていい部分」と「切ってはいけない部分」を分けて考える必要がある、ということです。

先に結論:切っていいのはプラグイン側、コア本体のセキュリティ更新は残す

自動更新を全部オフにするか、全部オンにするかの二択で悩む必要はありません。

WordPress本体の「マイナー更新(セキュリティ・不具合修正)」だけは自動のまま残します。

プラグインやテーマ、本体のメジャー更新は手動にする、という分け方です。

理由は単純で、コア本体の重大な脆弱性は、公開から数時間で攻撃対象になることがあるからです。

何が起きたか:公開から数時間で攻撃が始まった

2026年9月22日、WordPress本体に重大な脆弱性(CVE-2026-87902)が見つかりました。

同じ日のうちに、修正版の7.1.2が公開されています。

対象は2016年公開の4.7.0から、直前のバージョンだった7.1.1までと、非常に広い範囲です(出典: WordPress公式ニュース https://wordpress.org/news/2026/09/wordpress-7-1-2-release/)。

深刻度を表すCVSSスコアは9.2でした(出典: Help Net Security https://www.helpnetsecurity.com/2026/09/23/cve-2026-87902-wordpress-7-1-2-security-release/)。

10段階のスコアで、上位にあたります。

さらに気になるのが、攻撃が始まったタイミングです。

セキュリティ企業の観測によると、最初の攻撃の試みは9月22日の協定世界時11:49、つまり修正版が公開されたのとほぼ同じ日のうちに確認されています(出典: The Hacker News https://thehackernews.com/2026/09/attackers-exploit-wordpress-cve-2026.html)。

その後、9月23日以降だけで3万813件のユニークIPからの攻撃通信が観測されました(出典: CrowdSec https://www.crowdsec.net/vulntracking-report/cve-2026-87902-wordpress-vulnerability)。

「気づいたときには様子を見よう」が通用する時間は、ほとんど残っていなかったことになります。

この脆弱性は9月25日にアメリカの政府機関(CISA)の「既知の悪用済み脆弱性」一覧にも追加され、連邦機関には9月28日までの対応が求められました(出典: The Hacker News https://thehackernews.com/2026/09/attackers-exploit-wordpress-cve-2026.html)。

政府機関が扱う期限が3日しかないほど、対応の優先度が高い脆弱性だった、ということです。

自動更新の「デメリット」派の言い分は、どこまで正しいか

自動更新に慎重な人の言い分は、主に2つです。

1つは、プラグインの動きが急に変わって、サイトの表示が崩れるリスクです。

もう1つは、更新のタイミングを自分で選べず、対応できない時間帯に不具合が起きるリスクです。

どちらも実際にあり得る話で、否定はしません。

ただし、この2つはどちらも「プラグイン・テーマ側」の話です。

WordPress本体のマイナー更新は、セキュリティ修正と軽微な不具合修正だけを対象にしています。

見た目や機能への影響は、限定的です。

心配すべき場所と、心配しなくていい場所を混ぜてしまうのが、いちばんもったいないパターンです。

「自動更新は全部危ない」と、ひとまとめに判断してしまうケースです。

管理画面の「ダッシュボード」→「更新」には、2つの選択肢が表示される仕組みになっています。

「メジャー・マイナーとも自動更新」と「メンテナンスとセキュリティのみ自動更新」です。

初期状態では後者が選ばれていることが多いので、まずは今の設定がどちらになっているかを見るところから始めれば十分です。

私がやめたこと:全部を手動更新にしていた時期がある

以前は、本体もプラグインも、更新はすべて手動にしていました。

自動更新で何かが壊れて、原因を探すところから始めるのが面倒だったからです。

ところが、更新通知を見落として、本体のマイナー更新が1か月以上そのままになっていたことがありました。

幸い被害にはつながりませんでしたが、「見落とす前提で運用を作っていなかった」ことに気づきました。

今は、本体のマイナー更新だけは自動に戻しました。

プラグインとテーマは、決済・フォーム・キャッシュに関わる重要なものだけ手動にし、それ以外は自動でもよいという分け方に落ち着いています。

「全部見る」をやめて、「見る場所を絞る」に変えた、という話です。

今日確認したい3ステップ

自分のサイトの設定を、次の3ステップで見直せます。

どれも管理画面を開くだけで、10分もかからない作業です。

WordPress自動更新の設定チェックリスト図

  • 管理画面の「ダッシュボード」→「更新」を開き、本体が「マイナー更新のみ自動」になっているか確認する
  • プラグイン一覧の「自動更新」列を見て、決済・フォーム・キャッシュに関わるものだけ手動になっているか確認する
  • 更新前にバックアップが自動で取られる設定になっているか確認する(サーバーの管理画面またはバックアッププラグイン側)
  • 更新後にトップページ・問い合わせフォームが正しく表示されるか、月1回でよいので目視する

1つ目は、本体側の設定です。

「メジャー更新も自動」になっている場合は、いったん「マイナーのみ自動」へ戻すことをおすすめします。

2つ目と3つ目は、プラグイン側の安全網です。

決済やフォームは自動更新で挙動が変わると被害が大きいので、ここだけは人の目を挟みます。

4つ目は、更新そのものより「更新した後に気づける仕組み」を作る作業です。

まとめ:自動更新は「全部切る」ではなく「残す場所を選ぶ」

今回のように、公開から数時間で攻撃が広がる脆弱性は、これからも出てきます。

そのたびに「自分で気づいて、自分で更新する」を前提にすると、どこかで見落とします。

本体のセキュリティ更新だけは自動に任せ、プラグインの重要な部分だけ自分の目を通す。

この分け方であれば、更新の手間を増やさずに、公開直後の危険な時間帯も自動更新に任せられます。

まずは今日、管理画面の「更新」設定を1回開いて、上の3ステップを試してみてください。

サーバー会社によっては、管理画面とは別に「自動アップデート設定」というメニューを持っていることもあります。

どちらか一方で設定していれば十分ですが、両方をなんとなく触っていると、意図と違う組み合わせになっていることがあります。

一度だけでいいので、両方の設定画面を見比べておくと安心です。

なにか引っかかっていることがあれば。

サイトまわりのことなら、だいたい答えられます。

WordPress 自動更新のデメリット|数時間で3万台が実際に狙われた | Mstudio