WordPress 7.1.2が2026年9月22日に公開されました。公式発表では、重大度がCriticalのセキュリティ脆弱性を修正するリリースとして、サイトを直ちに更新することが推奨されています。
今回は、特定のサーバー環境とテーマの条件が揃うと、未認証の攻撃者が有効テーマ外の読み取り可能なPHPファイルをテンプレートとして読み込ませ、リモートコード実行につながる可能性がある問題です。
急ぐ必要はありますが、バックアップも確認もせずに更新するのではなく、短い手順で安全性を確保します。
まず現在のバージョンを確認する
管理画面の「ダッシュボード」から更新情報を確認できます。複数サイトを管理している場合は、一覧だけで判断せず各サイトの実際のバージョンを確認します。
WP-CLIを利用できる環境では、次のコマンドで確認できます。
wp core versionWordPress 7.1.2だけでなく、修正はセキュリティ修正対象の旧ブランチにもバックポートされています。ただし、公式が積極的にサポートするのは最新バージョンです。古い環境へ修正が届いたことを、長期的に古いままでよい理由にはできません。
更新前に最低限確認すること
緊急更新でも、復旧手段は必要です。
- データベースのバックアップが取得できる
wp-contentと設定ファイルを復元できる- バックアップの保存先がサイトと同じサーバーだけになっていない
- 現在のテーマ名と有効プラグインを記録した
- サイトと管理画面へアクセスできる
- キャッシュやCDNを使っているか把握した
バックアップを作っただけでなく、ファイルが存在し、容量が極端に小さくないか確認します。
WP-CLIで更新する場合
WordPress本体を更新します。
wp core update更新後にデータベース更新が必要か確認します。
wp core update-db最後にバージョンとコアファイルの整合性を確認します。
wp core version
wp core verify-checksumsverify-checksumsで警告が出た場合は、キャッシュファイルや独自ファイルと決めつけず、対象と設置理由を確認します。
更新後はトップページだけを見ない
HTTP 200が返り、トップページが表示されたから完了とは限りません。今回の問題はテンプレート解決に関係するため、異なるテンプレートを使うページも確認します。
- トップページ
- 固定ページ
- 投稿詳細
- カテゴリー一覧
- 検索結果
- 404ページ
- 問い合わせフォーム
- ログインと管理画面
PHPエラーログも確認し、更新時刻以降に新しいFatal errorやWarningが増えていないか見ます。
自動更新任せでも確認は必要
自動バックグラウンド更新が有効なサイトは、処理が始まることがあります。しかし、全サイトで成功したとは限りません。
複数サイトを保守している場合は、サイト名、更新前バージョン、更新後バージョン、確認日時、表示確認結果を一覧で残します。自動更新は作業を減らす仕組みではなく、緊急修正を早く適用する仕組みとして扱い、結果確認を行います。
改ざんの疑いがある場合
更新前後に見覚えのない管理者、PHPファイル、予約投稿、リダイレクトなどが見つかった場合は、更新だけで終わらせません。
サイトを保全し、ログ、ファイル更新日時、ユーザー、プラグイン・テーマの状態を調査します。感染した環境の上でファイルを上書きしても、別の不正ファイルや認証情報が残る可能性があります。
今回の確認チェックリスト
- WordPressの現在バージョンを確認した
- 復元可能なバックアップを取得した
- 7.1.2または該当ブランチの修正版へ更新した
wp core verify-checksumsを実行した- 複数種類のページとフォームを確認した
- PHPエラーログを確認した
- 管理者ユーザーと不審ファイルを確認した
- 作業日時と結果を記録した
セキュリティ更新は、早さと確認の両方が必要です。「更新ボタンを押した」で終わらず、正しい版になり、サイトが正常に動き、不審な状態がないところまで確認しましょう。
