「自動更新は絶対オフにしてたのに気づいたらバージョンが上がっている」
どうもこれは設定のミスや不具合ではなく、WordPress側が用意している仕組みによるものらしいです。いやいや自動更新を無効にしてるんですけどヤメテクダサイヨ・・・
例えば、2026年7月17日にWordPress 7.0.2が公開されました。重大度Criticalが1件、Highが1件という深刻な脆弱性を修正するリリースで影響の大きさからWordPress.org側は対象バージョンに対して自動更新システムによる強制更新を有効にしています。
結論を先に言うと、ダッシュボードの「自動更新」設定はもともとメジャーバージョン向けの設定で、マイナー・セキュリティ更新は別枠でデフォルト適用される仕組みになっています。そのうえ今回は深刻度が高いため、WordPress.org側が明示的に強制更新のフラグを立てています。
この記事では、そのあたりの仕組みと本当の意味で自動更新を止める方法、アップデート後に確認しておきたいことをQ&A形式でまとめました。
WordPress 7.0.2では何が修正されたの？
2026年7月17日付けのセキュリティリリースでCritical 1件・High 1件の脆弱性が修正されています。
- Critical（CVE-2026-63030）
-
REST APIのバッチリクエスト処理にあるルート判定の不備とSQLインジェクションを組み合わせることで、ログインなしにリモートでコードを実行できてしまう問題です。海外では「wp2shell」とも呼ばれていて、REST APIのバッチルート処理とSQLインジェクションの問題を組み合わせることでログインしていない攻撃者が標準構成のWordPressでリモートコード実行に至る可能性がある、非常に深刻な脆弱性です。
- High（CVE-2026-60137）
-
複数の研究者がチームで報告したSQLインジェクションの問題です。
特にCriticalの方はログインすら不要でサイトを乗っ取れるタイプのものです。攻撃者が匿名のHTTPリクエストを1回送るだけで成立するため脆弱性のランクとしては最悪の部類に入ります。
バックポート状況は次のとおりです。
| 系列 | 影響を受ける脆弱性 | 修正版 |
|---|---|---|
| 7.0系 | 両方 | 7.0.2 |
| 6.9系 | 両方 | 6.9.5 |
| 6.8系 | SQLインジェクションのみ | 6.8.6 |
| 7.1 beta | 両方 | 7.1 beta2 |
6.8より前のバージョンはそもそも影響対象外です。とはいえサポートが切れている古いバージョンを使い続けること自体がリスクなので、この機会に手元のバージョンを確認しておくのがおすすめです。
自動更新をオフにしているのになぜ更新されるの？
WordPressのコア更新には開発版・メジャー・マイナー（セキュリティ含む）の3種類があります。ダッシュボードの更新画面にある「自動更新」のオンオフは、このうち主にメジャーバージョンの切り替えに関する設定です。
マイナー・セキュリティ更新は2013年公開のWordPress 3.7以降、デフォルトで自動的に適用される仕組みになっていて、そのトグルでは止まりません。整理すると以下のようになります。
| 更新の種類 | 通常の扱い | 管理画面の設定との関係 |
|---|---|---|
| 開発版更新 | 開発版を利用している環境が対象 | 通常の本番サイトには関係しない |
| メジャー更新 | インストール時期や現在の設定によって異なる | 「すべての新しいバージョン」を選ぶと対象になる |
| マイナー・セキュリティ更新 | 原則として自動更新 | 「メンテナンスとセキュリティリリースのみ」でも対象になる |
管理画面の設定は「自動更新を完全にオン／オフする」というより、「メジャー更新まで自動化するか、マイナー・セキュリティ更新だけにするか」を切り替えるものです。
強制更新は誰が行っているのか
「強制更新はプラグインやサーバー会社が行ったのか」という疑問もよく見かけます。答えは状況によって3パターンに分かれます。
まず土台としてWordPressコアはマイナー・セキュリティリリースを初期設定で自動適用する仕組みになっています。これはWordPress側の設計であり、特別な操作をしていない限り常に有効です。
次に今回のように深刻度が高いケースではWordPress.org自身が対象バージョンに対して自動更新システムによる適用を後押ししていると公式に案内しています。通常のマイナー更新よりも適用の優先度が引き上げられているイメージです。
さらにレンタルサーバーやマネージド型のホスティングでは、プラットフォーム側の判断でサイトの個別設定にかかわらず更新を適用することがあります。WordPress VIPでは今回の7.0.2が全サイトに自動で適用され、利用者側の対応は不要だったと案内されています。
wp-config.phpで AUTOMATIC_UPDATER_DISABLED をtrueに設定していた場合、WordPressコア自体の自動更新機能は動きません。それでも更新されていたならホスティング側の独自機能が働いた可能性が高いです。
通常の自動更新と緊急のセキュリティ更新は何が違うの？
普段のマイナー更新はWP-Cronで1日数回チェックされる通常のスケジュールに沿って適用されます。特に急いで配信する仕組みではありません。
一方の緊急の強制更新は、WordPress.orgの判断で通常のスケジュールや個別設定を待たずに優先度高く適用される、めったに使われない対応です。今回の7.0.2ではWordPress.orgが影響を受けるバージョンに対して、自動更新システム経由の「forced updates」を有効にしました。これはAUTOMATIC_UPDATER_DISABLEDなどのローカル設定やファイル権限を無視して必ず更新するという意味ではなく、自動バックグラウンド更新が利用可能なサイトに対しWordPress.org側が7.0.2への更新を自動適用の対象として配信した、という意味です。
強制アップデートを止めてもいいの？
技術的にはwp-config.phpに定数を追加すれば止められます。
// 開発版・マイナー・メジャーすべての自動更新を止める
define('WP_AUTO_UPDATE_CORE', false);
// バックグラウンド更新の仕組みそのものを止める（プラグイン・テーマ・翻訳も含む）
define('AUTOMATIC_UPDATER_DISABLED', true);- WP_AUTO_UPDATE_CORE:
trueで全種類を自動更新、falseで全種類を止める、'minor'（デフォルト）でマイナー・セキュリティ更新のみ自動更新します。 - AUTOMATIC_UPDATER_DISABLED:
trueにするとコアだけでなくプラグイン・テーマ・翻訳の自動更新もまとめて止まります。WP_AUTO_UPDATE_COREより強い設定です。
ただ正直なところ、今回のCVE-2026-63030はログイン不要で乗っ取りが成立してしまう問題なので、このタイミングで止めるのはおすすめしません。ステージング環境で検証してから本番に反映したいという運用上の理由がある場合も、検証をできるだけ早く終えて本番へ反映するほうが安全です。
アップデート後は何を確認すればいいの？
更新が入ったこと自体に気づいたら、以下を順番に見ておくと安心です。
- ダッシュボードの「概要」画面でバージョンが7.0.2（該当するバックポート版）になっているか確認する。
- 自動バックアップの有無を確認し、なければ手動でバックアップを取る。
- サイトの表示崩れや、管理画面へのログインに問題がないか確認する。
- 古いプラグインやテーマでエラーが出ていないか確認する。
- セキュリティプラグインを導入している場合は、更新前後で不審なアクセスログが残っていないか確認する。
もしまだ古いバージョンのままだった場合は、ダッシュボードの「更新」から手動で今すぐ適用しておくのが安全です。
WordPress 7.0で追加された機能やメジャーアップデート前後の注意点はこちらでまとめています。
