WordPress 7.0.2は、デザインや操作性を変えるための小さな更新ではありません。WordPress公式が2026年7月17日に公開したセキュリティリリースで、重大度の高い問題が修正されています。管理画面に更新通知が出ているものの「サイトが普通に表示されているから後でよい」と考えている場合は、表示の正常さと安全性が別の問題であることを押さえてください。脆弱性は、目に見える故障が起きてから対処するものではなく、攻撃に使われる前に塞ぐことが重要です。
WordPress 7.0.2で修正された問題
公式発表では、SQLインジェクションに関係する問題と、REST APIのバッチルート処理に関係する問題が説明されています。後者は条件が重なるとリモートコード実行へつながる可能性があるとされ、単なる管理画面の表示崩れとは性質が異なります。脆弱性の詳しい攻撃手順を試す必要はありません。サイト運営者が取るべき行動は、影響を受けるバージョンを確認し、修正版へ更新し、更新後の動作を検証することです。
WordPress 7.0系を利用している場合は7.0.2、6.9系は6.9.5、6.8系は6.8.6が修正版として案内されています。古いバージョンが必ず同じ問題の影響を受けるとは限りませんが、サポート状況や別の既知問題を考えると、長期間更新していない環境をそのままにする理由にはなりません。まず「ダッシュボード→更新」を開き、現在のWordPress本体の番号を記録しましょう。
自動更新されたサイトでも確認が必要な理由
今回のように重要度が高い更新では、自動バックグラウンド更新が実行される場合があります。ただし、自動更新のメールを受け取っただけで作業を終えないでください。サーバー側の権限、容量不足、通信の中断、独自カスタマイズなどにより、更新処理が完了しない可能性があります。管理画面のバージョン表示を確認し、トップページと主要ページを実際に開いて初めて確認が完了します。
複数サイトを運営している場合は、サイト名、URL、更新前バージョン、更新後バージョン、作業日時、確認者を一覧にします。「たぶん全部更新された」という状態を避け、対象漏れを防げます。制作会社や保守会社へ任せているサイトでは、契約にWordPress本体の更新が含まれるか、緊急更新時の連絡方法は何かも確認してください。
更新前に行うバックアップ
バックアップは、データベースとファイルの両方が必要です。データベースには投稿本文、固定ページ、設定、ユーザー情報などが保存されます。ファイル側にはテーマ、プラグイン、アップロード画像、wp-config.phpなどがあります。片方だけでは完全な復旧ができない場合があるため、サーバーの自動バックアップ、WordPress用バックアッププラグイン、手動保存のどれを使う場合でも対象範囲を確認します。
バックアップデータは、更新対象と同じサーバー内だけでなく、別の保存先にも置くと安全性が高まります。サーバー全体に障害が起きたとき、同じ場所のバックアップへアクセスできないことがあるためです。ただし、顧客情報や注文情報が含まれるデータを個人の端末へ無造作に保存してはいけません。社内ルールに沿った暗号化とアクセス管理を行い、不要になった古いバックアップは適切に削除します。
安全に更新する手順
- アクセスが比較的少ない時間帯を選び、関係者へ作業予定を共有する
- ファイルとデータベースをバックアップし、保存先と作成時刻を確認する
- キャッシュやセキュリティ設定の現状を記録する
- WordPress本体を修正版へ更新する
- 互換性を確認しながらテーマとプラグインも更新する
- キャッシュを削除し、表示と機能をテストする
- エラーログとセキュリティログを確認し、作業記録を残す
更新ボタンを連打したり、処理中にブラウザーを何度も再読み込みしたりしないでください。更新中は一時的にメンテナンスモードとなり、完了まで少し時間がかかる場合があります。長時間戻らないときは、別のタブからサイトの状態を確認し、サーバーのファイルマネージャーやログで原因を調べます。
更新後に確認するページと機能
トップページが表示されるだけでは十分ではありません。投稿ページ、固定ページ、カテゴリー一覧、サイト内検索、問い合わせフォーム、ログイン、画像表示、スマートフォン表示を確認します。ECサイトなら商品詳細、カート、決済直前までの導線、会員サイトならログイン後の権限別画面も対象です。送信テストを行う場合は、テストデータであることを明記し、実際の顧客対応へ混ざらないようにします。
ブラウザーの開発者ツールやサーバーログを利用できる場合は、PHPエラー、JavaScriptエラー、404、500エラーが増えていないか確認します。画面上は正常でも、裏側でエラーが繰り返されていると表示速度や安定性へ影響します。更新前後のページ速度を比較するときは、一度の測定だけで断定せず、キャッシュ状態をそろえて複数回確認しましょう。
不具合が起きたときの切り分け
最初に、ブラウザーキャッシュ、WordPressのキャッシュプラグイン、サーバーキャッシュ、CDNキャッシュを順番に確認します。古いCSSやJavaScriptが残り、更新後のファイルと食い違っているだけのケースがあるためです。それでも直らない場合は、エラーログの時刻と更新時刻を照合します。
プラグインが原因と思われる場合は、無計画にすべて停止するのではなく、ステージング環境で再現するか、直前に更新したものから一つずつ確認します。本番で停止すると問い合わせフォームやセキュリティ機能まで止まる可能性があります。テーマの独自コードが原因なら、子テーマの変更箇所やfunctions.phpを確認します。原因が分からないまま古いWordPressへ戻して放置すると、修正済みの脆弱性が再び残るため、戻す場合も一時対応として期限を決めてください。
更新できない事情がある場合
古いプラグインや業務システムとの連携により、すぐ更新できないサイトもあります。その場合は「更新しない」で終わらせず、外部公開範囲の縮小、WAF、管理画面のアクセス制限、不要アカウントの停止、強固なパスワードと多要素認証、ログ監視などの緩和策を検討します。これらは更新の代わりではありませんが、更新までのリスクを下げる助けになります。
同時に、互換性問題を解消する計画を作ります。問題のプラグインを代替製品へ移す、開発元へ対応状況を確認する、ステージング環境で新バージョンを試す、保守会社へ改修を依頼する、といった作業へ期限と担当者を設定します。更新できない状態が長引くほど、次の更新との差が広がり、将来の移行コストが増えます。
日常運用で再発を防ぐチェックリスト
- WordPress本体、テーマ、プラグインの更新通知を週1回以上確認する
- 使用していないテーマとプラグインを削除する
- 管理者アカウントを必要最小限にする
- バックアップの作成だけでなく復元テストも行う
- PHPとデータベースのサポート期限を確認する
- 改ざん検知やログ監視の通知先を最新に保つ
- 制作会社と緊急時の連絡手順を共有する
セキュリティは一度設定して終わる作業ではありません。月次点検の項目へ更新状況、バックアップ結果、管理者一覧、ログの異常を含めると、担当者が変わっても確認を継続しやすくなります。作業記録には、何を更新したかだけでなく、更新しなかったものと理由も残してください。
よくある質問
自動更新が有効ならバックアップは不要ですか？
不要にはなりません。自動更新は修正版を早く適用する仕組みで、更新失敗や互換性問題から復旧する仕組みとは別です。サーバーの自動バックアップがある場合も、保持期間と復元単位を確認してください。
更新すると検索順位が下がりますか？
通常のセキュリティ更新そのものを理由に順位が下がるとは考えにくいものの、更新後の不具合でページが表示されない、noindexが付く、表示速度が大幅に悪化するなどの問題が起きれば検索にも影響し得ます。更新後の表示と設定確認が大切です。
プラグインだけ更新すればよいですか？
今回の修正はWordPress本体に関するため、本体を対象バージョンへ更新する必要があります。テーマやプラグインにも別の脆弱性が見つかるため、全体を継続的に管理してください。
まとめ
小規模サイトでも用意したい緊急対応メモ
一人で運営するブログや小規模な会社サイトでも、緊急時の情報を一枚にまとめておくと対応が速くなります。記載するのは、サーバー会社、契約プラン、管理画面URL、ドメイン管理会社、バックアップの保存場所、保守担当者、問い合わせ先、復旧時の優先ページです。パスワードそのものを平文で書くのではなく、安全なパスワード管理方法とアクセス権を決めてください。
サイトが停止したときは、原因調査と同時に利用者への案内も必要です。問い合わせや購入ができない場合、SNSや別ドメインの案内ページなど代替連絡手段を準備します。障害中に慌てて新しいアカウントを作ると、なりすましと区別しにくくなるため、平常時から公式連絡先を明示しておきましょう。
復旧後は、発生時刻、影響範囲、原因、実施した対応、再発防止を記録します。攻撃の有無が分からない場合に断定的な発表は避けますが、個人情報漏えいの可能性があるときは、法律や契約に基づく報告義務を専門家と確認してください。更新管理は技術作業であると同時に、利用者の信頼を守る運用です。
WordPress 7.0.2は、後回しにしにくいセキュリティ更新です。現在のバージョンを確認し、ファイルとデータベースをバックアップしたうえで修正版へ更新してください。作業後はトップページだけでなく、フォーム、ログイン、検索、スマートフォン表示、エラーログまで確認します。すぐ更新できない事情がある場合も、緩和策と解消期限を決め、放置状態を作らないことが重要です。
コメント