2026年7月17日、WordPressのセキュリティアップデート「WordPress 7.0.2」が公開されました。修正されたのは、SQLインジェクションやリモートコード実行につながる可能性がある、深刻度の高いセキュリティ問題2件です。今回はWordPress公式が影響を受けるバージョンに対して強制的な自動更新を実施しているため、サイト管理者が何も操作していなくても、すでにバージョンが上がっているサイトが多くあります。

実際、私のもとにも7月18日の朝方、自社サイトを含む管理中の複数のサイトから「自動更新しました」という通知メールが相次いで届きました。この記事では、WordPress 7.0.2で何が修正されたのか、どのバージョンが影響を受けるのか、そして「勝手に更新されていた」ことに気づいた後、何を確認すればよいのかを、WordPress専門のエンジニアとして解説します。

WordPress 7.0.2で修正された2つの脆弱性とは？

結論から言うと、今回修正されたのはSQLインジェクションに関する問題（深刻度High）と、REST APIのバッチルートの処理の混乱とSQLインジェクションを組み合わせてリモートコード実行につながる可能性がある問題（深刻度Critical）の2件です。

リモートコード実行とは、攻撃者が対象のサーバー上で不正なプログラムを実行できてしまう状態のことで、サイトの改ざんや乗っ取りに直結する、最も危険な部類の脆弱性です。攻撃を成立させる細かな条件までは公開情報だけでは判断できませんが、WordPress公式がわざわざ強制自動更新に踏み切ったこと自体が、緊急性の高さを物語っています。

影響を受けるバージョンと修正版

影響範囲と修正版は次のとおりです。お使いのバージョンの系統がどれに当たるか、まず確認してください。

WordPressの系統	影響	修正版
WordPress 7.0系	2件の問題の影響を受ける	WordPress 7.0.2
WordPress 6.9系	2件の問題の影響を受ける	WordPress 6.9.5
WordPress 6.8系	1件目の問題の影響を受ける	WordPress 6.8.6
WordPress 7.1 Beta	2件の問題の影響を受ける	WordPress 7.1 Beta 2以降
WordPress 6.8より前	今回の2件については影響なし	別の脆弱性対策として更新を推奨

ここで注意したいのは、「6.8より前なら安全」という意味ではないことです。古いWordPressには、過去に修正された別のセキュリティ問題がそのまま残っています。今回の脆弱性を避けるために古いバージョンにとどまる、という判断は適切ではありません。

「勝手に更新された？」——今回は強制自動更新が実施されています

WordPressには、セキュリティ目的の小規模な更新（7.0→7.0.2のようなマイナーアップデート）を自動適用する仕組みがもともとあります。今回はそれに加えて、問題の深刻度を考慮し、WordPress.org側が影響バージョンのサイトに対して強制的な自動更新を有効化しました。

そのため、身に覚えがなくてもバージョンが上がっており、管理者宛てに次のようなメールが届いているはずです。私のサイトに実際に届いたメールが、こちらです。

サイト (https://edel-hearts.com) を WordPress 7.0.2 へ自動更新しました。

何もする必要はありません。バージョン 7.0.2 について詳しくは「WordPress について」画面をご覧ください

このメールが届いていれば、更新自体は完了しています。ただし、注意したいケースが2つあります。1つは更新に失敗しているケースです。「一部のファイルをコピーできず、更新に失敗しました」というエラーになることがあり、私の経験では、失敗したときに通知が届くとは限らず、後になって失敗に気づいたこともあります。もう1つは、管理者メールアドレスが今は使っていないアドレスのままで、通知に誰も気づいていない場合です。サイトを長く運用していると、開設時に設定したメールアドレスが放置されていることは珍しくありません。だからこそ、メールを待つのではなく、この後説明するバージョン確認を能動的に行うことが大切です。

「何もする必要はありません」を、そのまま信じていいのか

メールには「何もする必要はありません」と書かれています。たしかに更新の操作は不要です。しかし、保守を仕事にしている立場から言うと、「更新の操作は不要。ただし、サイトが正常に動いているかの確認はしてほしい」というのが正直なところです。

マイナーアップデートは互換性への影響が小さい更新ですが、独自カスタマイズしたテーマや古いプラグイン、サーバー環境との組み合わせによっては、不具合が出る可能性がゼロではありません。しかも強制自動更新は、こちらのタイミングを選ばずに実行されます。「知らないうちに更新され、知らないうちにフォームが止まっていた」という事態が、いちばん怖いのです。

まず現在のWordPressバージョンを確認する

管理画面にログインし、次のいずれかの場所でバージョンを確認してください。

「ダッシュボード」→「更新」
「ダッシュボード」→「ホーム」の概要欄
「ツール」→「サイトヘルス」→「情報」

7.0系なら7.0.2以上、6.9系なら6.9.5、6.8系なら6.8.6になっていれば修正済みです。まだ更新されていない場合は、バックアップを取得したうえで「ダッシュボード」→「更新」から手動更新します。更新の基本手順は安全なWordPress更新手順の記事に詳しくまとめています。

更新後に確認したい7つのチェックポイント

バージョンが上がっていることを確認したら、あわせてサイトの動作も点検しておきましょう。私が更新後のサイトを確認するときの基本チェックは次の7つです。

トップページの表示（ログアウト状態・シークレットウィンドウでも見る）
主要な固定ページ・投稿ページの表示（特にショートコードやページビルダー使用ページ）
お問い合わせフォームの送信テスト（管理者宛て・自動返信メールの受信まで確認）
管理画面へのログインと、投稿一覧・メディアライブラリの表示
会員登録・予約などの機能（会員サイト・予約サイトの場合）
カート・決済・注文メール（ECサイトの場合）
サーバーのエラーログに新しいエラーが出ていないか

ポイントは、トップページが表示されるだけで安心しないことです。特にフォームは、画面上は送信完了と出ていてもメールが届いていないケースがあるため、実際の受信確認までを1セットにしてください。

自動更新されていない場合に考えられる原因

強制自動更新が有効化されていても、すべてのサイトで確実に更新が完了するとは限りません。次のような環境では、自動更新が動かない・失敗することがあります。

WordPressやサーバー側で自動更新を無効化している
ファイルやディレクトリの権限が適切ではない
サーバーの空き容量が不足している
セキュリティプラグインやBasic認証が更新処理を妨げている
独自の更新管理システムを使用している
更新中に通信やサーバー処理が中断された

管理画面に「別の更新が現在進行中です」といったメッセージが残っている場合も、更新が正常に完了していない可能性があります。私自身、過去に管理していたサイトで、管理画面から更新を試みた際に「一部のファイルをコピーできず、更新に失敗しました」というエラーが出た経験があります（そのときの対処は後半の技術者向けセクションで紹介します）。未更新のまま長期間放置するのがいちばん危険です。原因が分からない場合は、早めに専門家へ相談してください。

【技術者向け】REST APIバッチルートと、自動更新の制御・失敗時の復旧

ここからは少し技術的な補足です。2件目のCriticalな脆弱性は、REST APIのバッチルート（複数のAPIリクエストを1回にまとめて送れるエンドポイント）の処理の混乱とSQLインジェクションの組み合わせと発表されています。REST APIは通常のサイトでも外部から到達できる面（アタックサーフェス）なので、「REST APIは使っていないから関係ない」とは言えない点に注意が必要です。

また、wp-config.phpで自動更新を制御しているサイトは、今回のような強制更新が届いていない可能性があります。次の設定に心当たりがある場合は、必ず手動でバージョンを確認してください。

// 自動更新をすべて無効化（強制更新も適用されない）
define( 'AUTOMATIC_UPDATER_DISABLED', true );

// 本体の自動更新を無効化
define( 'WP_AUTO_UPDATE_CORE', false );

// 自動更新をすべて無効化（強制更新も適用されない）

define( 'AUTOMATIC_UPDATER_DISABLED', true );

// 本体の自動更新を無効化

define( 'WP_AUTO_UPDATE_CORE', false );

自動更新を無効化する運用自体が悪いわけではありません。問題なのは、更新を止めたまま、誰もセキュリティ情報を追いかけていない状態です。無効化するなら、リリース情報を確認して速やかに手動更新する体制と、更新前のバックアップ・戻せる手順をセットで用意してください。バックアップの考え方はバックアップ解説記事で、万一更新後にエラーが出た場合の対処は重大なエラーの直し方の記事で解説しています。

更新の失敗時には、コマンドライン（WP-CLI）が使えると対応が速くなります。私も管理画面から更新を試みて「一部のファイルをコピーできず、更新に失敗しました」というエラーが出たことがあり、そのときは管理画面での再更新を繰り返すのではなく、SSHでサーバーにログインし、コマンドで本体を更新し直すことで解消しました。失敗した状態を放置すると、新旧のファイルが混在した不安定な状態が続くおそれがあります。

wp core version           # 現在のバージョンを確認
wp core update            # 本体を最新版へ更新
wp core verify-checksums  # 本体ファイルの整合性をチェック

wp core version # 現在のバージョンを確認

wp core update # 本体を最新版へ更新

wp core verify-checksums # 本体ファイルの整合性をチェック

更新が中途半端に終わっている疑いがあるときは、同じバージョンを上書きし直す wp core update –force も有効です。複数サイトを管理している場合も、WP-CLIならバージョン確認から更新までを素早く一括で回せます。

なお、WAFやログイン保護などの多層防御は日頃から重要ですが、本体の脆弱性修正の代わりにはなりません。セキュリティ対策の全体像は不正ログイン対策の記事も参考にしてください。

更新メールが届いた日こそ、サイトを見に行く日

WordPress 7.0.2は、SQLインジェクションやリモートコード実行につながる可能性のある深刻な脆弱性の修正であり、公式が強制自動更新を実施するほどの緊急対応でした。確認すべきことを整理します。

使用中のWordPressが修正版（7.0.2／6.9.5／6.8.6）になっているか
更新に失敗していないか（失敗しても通知が届くとは限りません）
サイトの表示・フォーム・会員/予約/決済機能が正常に動くか
自動更新を無効化しているサイトは、手動で更新したか

セキュリティ更新は「適用されて終わり」ではなく、更新後の動作確認と、問題が起きたときに戻せる準備までがワンセットです。「何もする必要はありません」というメールが届いた日こそ、ご自身のサイトを一度見に行ってあげてください。

「自分のサイトが更新されているか分からない」「更新後の確認まで手が回らない」という場合は、WordPress保守サポートで日常の更新と動作確認を代行しています。弊社の保守契約では毎日自動でバックアップを取得して7世代分を保持し、万が一更新で問題が起きてもすぐに元の状態へ戻せる体制を取っています。異常があったときだけご報告する運用なので、お客様が日々気にする必要はありません。更新後にサイトの表示がおかしくなってしまった場合はトラブル対応サービスへ、まず現状を把握したい方は無料AI診断もご利用ください。