プラグイン・テーマ・本体で対処法が分かれる理由 — WordPress脆弱性の3つの発生源
WordPressの脆弱性は、「本体（コア）」「プラグイン」「テーマ」のどこで起きたかによって、対処のスピードも手順も変わります。まず自分のサイトの脆弱性がどの層のものかを見分けること。ここが復旧の出発点です。
層ごとに更新の主導権を握る相手が違うからです。コアはWordPress本体の開発チームが、プラグインとテーマは個々の作者が修正版を出します。作者が更新を放棄していれば、待っても修正は永遠に届きません。
公開プラグイン・テーマが攻撃の入口になりやすい構造的な背景
攻撃の多くはコアではなく、公式ディレクトリで配布される無料プラグインやテーマから侵入します。フォーム値やURLパラメータといった外部入力を独自に処理するコードが多く、そこでサニタイズ漏れが生まれやすいためです。
とりわけ、インストールしたまま長期間更新が止まっているプラグインは危険度が高い。使っていないものは停止ではなく削除まで踏み込むのが、攻撃面を減らす確実な手です。基本的な守りはWordPressセキュリティ対策の基本設定と必須プラグインにまとめています。
本体（コア）の脆弱性を自動更新でどこまで防げるか
コアのマイナー更新（6.7.1のように末尾が上がる更新）は、初期設定で自動適用されます。セキュリティ修正はこのマイナー更新で配布されるため、自動更新を無効化していない限り、コアの既知の脆弱性はかなりの割合で自動的に塞がれます。
一方、メジャー更新は自動化されないことが多く、こちらは手動での判断が必要になります。
脆弱性の公表から復旧までの実務フローと、更新でつまずかないための確認ポイント
脆弱性情報が公表されたら、影響有無の確認 → ステージング環境での更新テスト → 本番反映 → 動作確認、という順で進めます。この順序を飛ばして本番へ直接あてると、脆弱性は消えたのにサイトが動かない、という事故を招きます。
反映後は、表示崩れやエラーが出ていないかを必ず目視で確認してください。手順の詳細はWordPress最新バージョンの確認方法と安全な更新手順が参考になります。
更新後に管理画面が真っ白になる互換性トラブルの原因と切り分け
更新直後に画面が真っ白になる、いわゆるホワイトスクリーンの典型は、プラグインが使う関数が新しいコアで廃止されたケースです。裏ではPHPのFatal errorが出ているのに、画面上は白いだけで原因が見えません。
切り分けの起点は、wp-config.phpでWP_DEBUGをtrueにし、エラーログを読むこと。どのファイルの何行目で落ちたかが分かれば、原因プラグインはほぼ特定できます。復旧できないときはバージョンアップに失敗する場合の手順も併用してください。
すぐ更新できないときの優先度判断と暫定的な回避策
大規模にカスタマイズした案件では、修正版が出ても即更新に踏み切れないことがあります。そのとき見るべきは、脆弱性が「認証不要で外部から突けるか」どうか。ログインを前提とする脆弱性より、未認証で攻撃できるものを最優先で塞ぎます。
本体をすぐ上げられない場合の暫定策としては、次が候補になります。
- 該当プラグインを一時停止し、機能を切り離す
- WAF（不正なリクエストを遮断する仕組み）で該当する攻撃パターンをブロックする
ただし、これはあくまで時間稼ぎです。ステージングでの検証が済み次第、正式な修正版へ更新するのが本筋だと忘れないでください。
EC-CUBEゴールドパートナー
WordPress構築・保守 
