WordPressの脆弱性対策｜プラグイン・PHP・サーバーの確認手順

WordPressの脆弱性対策では、本体・テーマ・プラグイン・PHP・サーバーを分けて確認します。 管理画面の「更新」を完了しても、PHPやOSの修正まで終わったとは限りません。制作会社に依頼したサイトも、公開後の保守が契約に含まれるかを確認する必要があります。

この記事は、自社のWordPressサイトを管理する担当者向けに、確認する場所と更新の進め方を整理したものです。特定の脆弱性の修正版一覧は、php2shellの概要と対応などの個別記事で確認してください。公式資料の確認日は2026年10月23日です。

最初に、どの層を誰が更新するか整理する

次の表は担当を決めるための例です。実際の責任範囲は、サーバーと保守の契約で確認してください。WordPress公式のセキュリティガイドでも、ホスティング事業者とサイト所有者の責任範囲を理解することが重視されています。

「サーバー代を払っているから、プラグインも更新される」とは判断できません。マネージドサービスでも、テーマの独自改修や更新後のフォーム確認まで含まれるかは契約次第です。

サーバー管理を自社で行う場合は、OSやDBの更新通知の受信先、適用する担当、必要な再起動を記録します。レンタルサーバーなら、事業者が行う更新と利用者が選択・操作する更新を分けて問い合わせます。

写真はサーバー設備の参考例です。実機を見られないホスティングでも、OSやPHPなどの管理対象は残ります。必要なのは、機器の所在地よりも自社の契約範囲と更新状況を確認できることです。

管理画面と公式の告知を照合する

本体・テーマ・プラグインを一覧にする

「ダッシュボード → 更新」で本体の状態を確認し、「外観 → テーマ」「プラグイン」で導入済みの製品を調べます。無効化してあるものも対象です。使わないプラグインやテーマは、依存関係と復元方法を確認して削除します。子テーマが使う親テーマを誤って削除しないよう注意してください。

更新通知があるものは、配布元の変更履歴・セキュリティ告知を開き、影響を受ける版、修正版、必要な追加設定を照合します。有料プラグインの契約切れや独自配布の製品では、管理画面だけでは更新の有無を判断できない場合があります。配布元を特定できないものは、その状態を保守担当へ伝えます。

更新が長くないことだけで脆弱性があるとは言えません。ただし、サポート終了や修正版が提供されないことを確認した製品は、削除・代替・公開制限を検討する対象です。

PHPはサイトヘルスで確認し、更新先は提供元で確かめる

WordPressなら、ここで確認

ツール→サイトヘルス→情報→サーバー

確認する行：PHP version（PHPバージョン）

画像を拡大 ↗

表示されたバージョンを控え、利用中のサーバー事業者の告知と照合してください。

WordPress公式のサイトヘルス説明にあるとおり、この画面は構成の情報を表示する場所です。PHPを更新する操作は、サーバーの管理画面や運用担当側で行います。CLIの php -v とWebで実行されるPHPが異なる構成もあるので、切り替え後はこの画面でも確認します。

表示したバージョンは、PHP公式のサポート期間と照合します。OS提供のパッケージは、古い系列に修正を取り込む場合があるため、上流の番号だけで未修正と断定せず提供元の情報を確認してください。系列ごとの期限と計画的な更新は、PHPのサポート期限とバージョンアップで詳しく扱っています。

バックアップから更新後の確認まで

以下は通常の更新に備える手順です。すでに悪用されている問題や侵害の疑いがある場合は、検証を待つ間も無防備な公開を続けないよう、保守担当と一時停止やアクセス制限を判断します。

ファイルとDBを同じ時点に戻せるか

WordPress公式の更新手順は、事前のバックアップを案内しています。投稿データだけのエクスポートでは、テーマ・プラグイン・画像・設定などを含むサイト全体の復旧には足りません。保存の成功に加えて、復元を試せることを確認します。

会員登録や注文が続くサイトでは、古いDBへ戻すと更新後に入ったデータを失うおそれがあります。停止時間や新しい注文の扱いを先に決めてください。バックアップの保存先も、公開ディレクトリや同じサーバー内だけにせず、アクセス権を管理します。

更新順は互換性で決める

すべてのサイトに共通する更新順はありません。たとえば、古いプラグインが新しいPHPに対応していなければ、先に対応版や代替製品を検証する必要があります。本体・テーマ・プラグイン・PHPの対応範囲を並べ、段階を分けて確認します。検証環境では、実際の顧客へのメール送信や本番決済が起きないよう外部接続も制限します。

本番の適用後は、管理画面が開くだけで完了としません。問い合わせが担当者へ届くか、購入処理が終わるかまで確認し、エラーログを見ます。脆弱性のある版へ切り戻す必要が生じた場合は、公開制限などの保護も合わせて判断します。

自動更新の失敗を誰が受け取るか

テーマ・プラグインの自動更新は個別に設定できます。WordPress公式の自動更新ガイドでは、成功・失敗の通知と、スケジュール実行が動かない場合の確認方法を説明しています。設定を有効にした後も、通知を受ける担当と、失敗したときの対応を決めておきます。

WAFで防げる攻撃と、更新が必要な理由

WAFは、WebへのHTTP通信を検査し、ルールに該当する攻撃を遮断する仕組みです。OWASPの仮想パッチの解説では、修正の公開・適用までの間にリスクを減らす方法として紹介されています。ソフトウェア自体を書き換える修正とは異なります。

WAFを緩和策として使うなら、次を事業者や運用担当へ確認します。

• 対象の脆弱性に対応するルールがあり、検知のみでなく必要な遮断が有効か
• 別ホスト名やサーバーへの直接アクセスなど、WAFを通らない入口が残っていないか
• 正常なフォームやAPIを止めていないか、検知ログを誰が確認するか

ルールに対応していない攻撃や盗まれた認証情報による操作まで、一律に防げるとは言えません。修正版の適用計画と合わせて運用します。

保守契約と日々の確認を、担当者が替わっても続ける

制作時の契約書や引き継ぎ資料に、5つの層の担当が書かれているか確認します。記載がなければ、次の事項を保守会社と具体化します。

契約の有無だけでは、誰が更新後の動作を確認するかは分かりません。契約書と実際の手順を照合します。権限や退職者アカウントなど、更新以外の確認事項はWebサービスのセキュリティ対策にまとめています。

SECURITY ACTIONを社内の取り組みの入口にする

IPAのSECURITY ACTIONは、中小企業が情報セキュリティ対策への取り組みを自己宣言する制度です。IPAによる安全性の認定ではありません。社内の基本方針や担当を整理する入口にはなりますが、WordPressの脆弱性の確認や更新を代わりに行う制度ではないため、この記事の作業と並行して進めます。

更新を続けられない場合は、構成と担当を見直す

更新を妨げているものが独自改修なのか、保守終了のプラグインなのか、担当不在なのかで対処は変わります。不要な機能の削除や保守契約の見直しで解決する場合もあります。CMSの変更を検討するなら、WordPressを継続する場合と乗り換える場合の比較で、編集・フォーム・検索流入への影響も確認してください。

更新担当や復旧手順の整理は、受託開発・SRE顧問の対応領域をご覧ください。相談時には、現在のサーバー、保守契約の範囲、更新できずにいる対象を相談フォームで共有いただくと、確認すべき範囲を整理しやすくなります。