WordPress 7.0.2は自動更新だけで安心か 確認すべきバージョンと手順

WordPress 7.0.2は自動更新だけで安心か 確認すべきバージョンと手順

WordPress 7.0.2が、2026年7月17日にセキュリティリリースとして公開されました。WordPress.orgは、影響を受けるバージョンのサイトに対して、自動更新システム経由の強制更新を有効化したと説明しています。

ただし、「強制自動更新が有効化されたこと」と「自分のサイトで更新が完了していること」は同じではありません。サイト設定、サーバー権限、ホスティング環境、保守会社の運用によって、確認すべき点が残る可能性があります。

この記事では、士業事務所・中小企業・Web制作会社向けに、確認すべきWordPressのバージョン、管理画面で見る場所、更新後のフォーム確認、制作会社・保守会社へ聞く項目を整理します。国内での被害発生や攻撃観測については、今回確認した一次情報からは断定しません。

WordPress 7.0.2は何のための更新か

2026年7月17日に公開されたセキュリティリリース

WordPress.org Newsは、2026年7月17日付で「WordPress 7.0.2 Release」を公開しました。同発表では、WordPress 7.0.2がセキュリティリリースであり、「critical」1件と「high severity」1件のセキュリティ問題に対応したと説明されています。

WordPress.orgの「Version 7.0.2」ドキュメントでも、WordPress 7.0.2の公開日は2026年7月17日とされ、同ページの最終更新日は2026年7月18日とされています。修正対象ファイルとして、REST API関連のファイルやWP_Queryに関係するファイルが挙げられています。

士業事務所や中小企業のサイト管理者にとって重要なのは、脆弱性の内部実装を細かく理解することよりも、自分のサイトが対象バージョンに該当するか、修正版へ更新済みか、更新後に問い合わせ導線が動作しているかを確認することです。編集部の見解では、今回の対応は「更新作業」だけでなく「更新確認」と「記録」が実務上の中心になります。

関連するCVEと影響範囲

今回のリリースに関連する情報として、GitHub Security Advisoryでは2件の脆弱性が公開されています。

1件目はGHSA-fpp7-x2x2-2mjfで、CVE IDはCVE-2026-60137です。内容は、WP_Queryauthor__not_inパラメータに関するSQL injection脆弱性とされています。SQL injectionとは、データベースへ送る問い合わせ文に不正な入力が混入し、想定外の処理につながる可能性がある問題を指します。

2件目はGHSA-ff9f-jf42-662qで、CVE IDはCVE-2026-63030です。GitHub Advisoryでは、REST API batch-route confusionとSQL injectionの組み合わせにより、Remote Code Executionにつながる脆弱性と説明されています。Remote Code Executionは、遠隔から不正なコード実行につながる可能性がある問題を指します。

なお、WordPress.org Newsでは「critical」1件と「high severity」1件と説明されている一方、GitHub AdvisoryではGHSA-fpp7-x2x2-2mjfがModerate、GHSA-ff9f-jf42-662qがCriticalと表示されています。重要度表記に差がある理由は、今回確認した一次情報だけでは確認できないため、編集部では独自の解釈を加えません。

確認すべきWordPressのバージョン

7.0系、6.9系、6.8系で見るべき修正版

WordPress.orgのリリース情報とGitHub Advisoryに基づくと、今回確認すべき主なバージョンは次のとおりです。

  • WordPress 7.0.0から7.0.1:修正版は7.0.2
  • WordPress 6.9.0から6.9.4:修正版は6.9.5
  • WordPress 6.8.0から6.8.5:修正版は6.8.6

WordPress.orgのリリース情報では、WordPress 6.9は2件の脆弱性の影響を受け、修正版として6.9.5が公開されたとされています。WordPress 6.8は1件目の脆弱性のみ影響を受け、修正版として6.8.6が公開されたとされています。

また、WordPress.orgの説明では、WordPress 6.8より前のバージョンは今回の脆弱性の影響を受けないとされています。ただし、これは「今回の脆弱性」に関する説明です。古いWordPress全般の安全性まで保証するものではないため、古いバージョンを使い続けているサイトでは、別の観点で保守状況を確認する必要があると考えられます。

管理画面で確認する場所

WordPress.orgの更新案内では、手動更新の方法として、WordPress管理画面のDashboard > UpdatesからUpdate Nowを実行する方法が案内されています。日本語環境では、管理画面の「ダッシュボード」や「更新」画面に相当する場所で確認する運用になります。

確認時には、単に「更新があります」と表示されているかを見るだけでなく、現在のWordPressコアバージョンを確認することが重要です。7.0系であれば7.0.2、6.9系であれば6.9.5、6.8系であれば6.8.6になっているかを見ます。

手動更新を行う場合、WordPress.orgのドキュメントでは、更新前にサイトのバックアップを取ることが案内されています。編集部の見解では、士業事務所や中小企業が自力で作業する場合でも、委託先へ依頼する場合でも、更新前バックアップの有無は確認項目に入れるべきです。更新作業そのものより、復旧できる状態で作業したかどうかが実務上の安心材料になります。

強制自動更新があっても確認が必要な理由

自動更新が完了したとは限らない

WordPress.orgは、今回のリリースについて、影響を受けるバージョンのサイトに対し、自動更新システム経由の強制更新を有効化したと説明しています。これは重要な対応ですが、個別サイトで更新が完了していることまで確認不要になるわけではありません。

WordPress Developer Resourcesの「Upgrading WordPress」では、自動バックグラウンド更新にはコア更新、プラグイン更新、テーマ更新、翻訳ファイル更新があると説明されています。また、既存インストールでは原則としてminor core updatesが自動更新され、新規インストールではWordPress 5.6以降、条件によりmajor core updatesも自動更新されるとされています。

一方で、自動更新の挙動は、wp-config.phpの定数、フィルター、ファイル権限、ホスティング環境、管理会社の設定、バージョン管理を使った独自デプロイなどの影響を受ける可能性があります。したがって、編集部では「自動更新されたはず」と断定せず、管理画面や保守会社の報告で更新結果を確認する運用が妥当だと考えます。

プラグイン・テーマ更新との混同を避ける

今回の記事で主に扱っているのは、WordPress本体、つまりWordPressコアの更新です。プラグインやテーマの更新とは区別して確認する必要があります。

WordPressサイトの管理画面では、コア、プラグイン、テーマ、翻訳ファイルなど複数の更新が同じ画面に表示されることがあります。そのため、「プラグインを更新したから今回の対応も済んだ」と誤解しないようにする必要があります。

制作会社や保守会社へ確認する場合も、「WordPress本体は何のバージョンになっていますか」と聞くほうが明確です。「更新しましたか」だけでは、プラグイン更新、テーマ更新、コア更新のどれを指しているのかが曖昧になる可能性があります。

士業・中小企業サイトで確認したい実務チェック

更新前後に確認する項目

士業事務所や中小企業では、WordPressの技術詳細をすべて把握するよりも、確認項目をチェックリスト化するほうが実務に落とし込みやすいと考えられます。

最低限、次の項目を確認するとよいでしょう。

  • 更新前バックアップを取得しているか
  • 現在のWordPressコアバージョンは何か
  • 更新後のWordPressコアバージョンは何か
  • 管理画面へログインできるか
  • 問い合わせフォームが送信できるか
  • 予約フォーム、資料請求フォームなど主要フォームが動作するか
  • 主要ページが通常どおり表示されるか
  • 更新作業者または確認者を記録しているか
  • 確認日時を記録しているか
  • 異常時の連絡先が決まっているか

編集部の見解では、今回のようなセキュリティリリース対応では、対応したかどうかを口頭で済ませるより、確認結果を簡単に記録しておくことが有効です。後日、顧客や社内から確認を求められた際にも、対象バージョン、更新後バージョン、動作確認結果を示しやすくなります。

問い合わせフォームを持つサイトで特に見る場所

士業サイトでは、問い合わせフォームや相談予約フォームが業務の入口になっているケースがあります。今回確認した一次情報から、国内の士業サイトで実被害が発生しているとは確認できません。ただし、SQL injectionやRemote Code Executionにつながる脆弱性が含まれるとされているため、フォームやログインまわりの動作確認は優先度が高いと考えられます。

税理士事務所であれば、顧問契約相談、資料請求、問い合わせフォームを確認します。社会保険労務士事務所であれば、労務相談、助成金相談、顧問契約問い合わせの導線を確認します。行政書士事務所であれば、許認可、在留資格、建設業許可など分野別問い合わせページを確認します。司法書士事務所であれば、相続相談、登記相談、予約・問い合わせ導線を確認します。

中小企業サイトでは、問い合わせ、資料請求、採用応募、予約フォームなどが確認対象になります。フォームが複数ある場合は、代表的なフォームだけでなく、売上や採用に関係する主要フォームを優先して確認する運用が現実的です。

制作会社・保守会社に確認したいこと

委託先に送る確認項目

自社や事務所でWordPressを直接管理していない場合は、制作会社・保守会社・社内担当者へ確認するのが実務的です。その際は、質問を曖昧にせず、確認してほしい項目を並べると回答を得やすくなります。

確認項目の例は次のとおりです。

  • 当社サイトは今回の影響対象バージョンに該当していましたか
  • 現在のWordPressコアバージョンは何ですか
  • 7.0系の場合は7.0.2、6.9系の場合は6.9.5、6.8系の場合は6.8.6へ更新済みですか
  • 自動更新で完了しましたか、手動対応しましたか
  • 更新前バックアップは取得済みですか
  • 更新後に管理画面ログインを確認しましたか
  • 更新後に問い合わせフォーム、予約フォーム、資料請求フォームの動作確認を行いましたか
  • 更新後に主要ページの表示確認を行いましたか
  • 自動更新を止める設定や、ホスティング側の制約はありますか
  • 異常が見つかった場合の復旧手順と連絡先は決まっていますか

このように確認すると、制作会社側も「何を確認すればよいか」を整理しやすくなります。中小企業経営者や士業事務所側も、技術的な判断を抱え込みすぎず、管理責任者として確認すべき事項を押さえやすくなります。

制作会社側の顧客説明ポイント

Web制作会社や保守会社にとっては、今回の対応は「更新作業をしたか」だけで終わらせにくい案件です。強制自動更新が有効化されているため、実際には自動で更新されたサイトもあると考えられます。しかし、顧客への説明では、確認した結果を記録して伝えることが重要です。

たとえば、顧客ごとに次のような形で整理すると、説明の品質をそろえやすくなります。

  • 対象サイト名
  • 確認日時
  • 更新前または確認時点のWordPressコアバージョン
  • 更新後のWordPressコアバージョン
  • 自動更新か手動更新か
  • バックアップ確認の有無
  • 管理画面ログイン確認の結果
  • フォーム送信確認の結果
  • 主要ページ表示確認の結果
  • 未確認項目と次回対応予定

編集部の見解では、制作会社側がこの記録を残すことで、顧客からの問い合わせ対応を減らせる可能性があります。また、保守契約の範囲が曖昧な場合でも、コア更新、プラグイン更新、テーマ更新、フォーム動作確認、バックアップ確認のどこまでが契約範囲かを見直すきっかけになります。

ただし、顧客へ説明する際に「国内で攻撃が増えています」「すでに被害が出ています」といった表現を使う場合は、別途その根拠が必要です。今回確認した一次情報の範囲では、日本国内の士業・中小企業サイトでの被害事例や攻撃観測は確認できていません。説明は、公式発表で確認できる対象バージョンと修正版、そして自社で確認した更新結果に基づいて行うのが適切です。

まとめ

WordPress 7.0.2は、2026年7月17日に公開されたセキュリティリリースです。WordPress.orgは、影響を受けるバージョンに対して強制自動更新を有効化したと説明していますが、それだけで自サイトの確認が不要になるわけではありません。

まず確認したいのは、WordPressコアのバージョンです。7.0系は7.0.2、6.9系は6.9.5、6.8系は6.8.6になっているかを、管理画面や保守会社の報告で確認します。手動更新が必要な場合は、更新前バックアップを取り、更新後にログイン、フォーム、主要ページを確認する流れが実務的です。

士業事務所や中小企業は、技術対応をすべて自分で抱え込む必要はありません。現在のWordPressコアバージョン、バックアップ、フォーム動作確認、委託先への確認項目をチェックリスト化し、確認結果を記録することから始めるのが現実的です。Web制作会社や保守会社にとっても、更新結果と動作確認結果を顧客ごとに整理して説明することが、今回の対応で重要になると考えられます。

出典一覧

  1. WordPress.org News「WordPress 7.0.2 Release」(2026-07-17)
  2. WordPress.org Documentation「Version 7.0.2」(発表日不明)
  3. GitHub Security Advisory「GHSA-fpp7-x2x2-2mjf」(2026-07-17)
  4. GitHub Security Advisory「GHSA-ff9f-jf42-662q」(2026-07-17)
  5. WordPress.org Documentation「Updating WordPress」(発表日不明)
  6. WordPress Developer Resources「Upgrading WordPress」(確認日:2026-07-29)

この記事はAIが生成し、編集長のチェックを受けて公開しています。

この記事をシェアする