WordPressの脆弱性対策｜影響の確認・安全な更新・保守の手順

WordPressの脆弱性が報告されたときは、まず「どの製品の、どのバージョンが対象か」を自社サイトと照合します。WordPress本体だけを更新しても、テーマやプラグイン、サーバー環境に問題が残る場合があります。反対に、告知にWordPressと書かれていても、使っていないプラグインの問題が自社にそのまま当てはまるとは限りません。

この記事では、企業のWeb担当者が、脆弱性情報の確認から更新、業務への影響確認、継続的な保守まで進めるための手順をまとめます。すでに改ざんや不審な転送が起きている場合は、通常の更新作業だけで終えず、侵害の調査と復旧を保守担当者に相談してください。

まず公式の告知と自社のバージョンを確認する

2026年10月10日の確認時点で、WordPress公式は10月6日にWordPress 7.1.3のメンテナンス・セキュリティリリースを案内しています。過去の記事に書かれた修正版番号を、そのまま現在の推奨版と考えないことが重要です。対応前にWordPress公式のリリース告知と、利用しているテーマ・プラグインの公式情報を確認してください。

脆弱性情報を読むときは、製品名、影響を受ける範囲、修正版、攻撃に必要な条件、推奨される対応を抜き出します。見出しだけで判断せず、告知の日付と更新履歴も確認します。公式から自動更新が案内されていても、自社で実際に更新されているかは管理画面等で確認が必要です。

脆弱性があることと、侵害されたことは違う

脆弱性は、ソフトウェアや設定にある、攻撃に悪用され得る弱点です。脆弱性の報告があるだけで、そのサイトがすでに攻撃されたと断定することはできません。一方、画面が正常に見えていても侵害の痕跡が残ることがあるため、疑わしい変更やアクセスがあれば調査を分けて行います。

企業担当者が最初に決めたいのは「対象か」「どれほど急ぐか」「誰が対応するか」の3点です。CVSS等の深刻度だけでなく、外部からアクセスできる機能か、認証なしで悪用されるか、悪用の情報が出ているか、保存している情報と業務への影響を組み合わせて判断します。

WordPressの脆弱性は4つの範囲に分けて管理する

本体、テーマ、プラグインのどれか一つに対策を入れれば全体が安全になる、という考え方は避けましょう。WordPress公式のセキュリティ強化ガイドでも、更新、権限、サーバー、バックアップ等を組み合わせる考え方を確認できます。

停止中のプラグインも一覧に残します。「無効化済み」だけを安全の根拠にせず、必要性と残っているファイルを保守担当者に確認してください。使っていないテーマやプラグインを整理する際も、復元可能なバックアップと依存関係の確認を先に行います。

自社サイトが影響を受けるかを調べる手順

製品名と現在のバージョンを台帳にする

管理画面や保守記録から、製品名、現在のバージョン、提供元、使用している機能を記録します。名称が似た別のプラグインを混同しないよう、提供元のURLも残してください。複数サイトがある場合はサイトごとに管理し、制作会社の把握している版と実際の版が一致するかを確認します。

告知の影響範囲と照合する

たとえばIPAのWordPressの脆弱性対策に関する注意喚起は、対象となるバージョンと更新による対応を案内しています。過去の告知は「その時点の影響範囲」の情報として使い、最新の公式告知も合わせて確認してください。複数の脆弱性が組み合わさるケースもあるため、一つのCVE番号だけを見て対応を終了しないことが大切です。

外部の簡易チェックで問題が見つからなかったことだけで、脆弱性がないと判断しないようにします。簡易チェック、構成の確認、専門家による診断は調べられる範囲が異なります。また、権限のないサイトへ診断を実施せず、自社や契約で許可された範囲と方法で確認してください。

更新の緊急度と、担当者が取る行動

以下は対応を相談するための判断例です。固定の日数まで放置してよいという意味ではありません。深刻な脆弱性では、通常の定期保守日を待たず、担当者と対応方法を決めます。

WAFやアクセス制限は、修正を進める間の補助策になる場合があります。ただし、それだけで原因が解消されるとは限りません。どの条件に対する対策なのか、いつ解除・見直すのかを決め、更新や代替策の検討を止めないようにします。

安全に更新するための準備と実施手順

更新前にファイルとデータベースをバックアップする

更新前の状態へ戻す方法を確認し、ファイルとデータベースのバックアップを保存します。バックアップがあることと、復元できることは別です。保存日時、保存先、担当者、復元に必要な情報を確認してください。検証環境へ複製する場合は、顧客情報の取り扱い、メール送信や決済の無効化、検索への公開防止も確認します。

重要な機能を先にテスト項目へ書き出す

トップページが表示されるだけでは、業務が正常に動くとは限りません。問い合わせフォームの送信・受信、予約、会員ログイン、決済、資料ダウンロード、検索、管理画面の更新など、サイトごとに必要な項目を整理します。実際の個人情報をテストに使わず、検証用のデータと送信先を用意してください。

互換性を確認し、作業結果を記録する

どの製品から更新するかは、依存関係や提供元の案内によって異なります。全サイトに同じ順番を機械的に当てはめず、WordPress本体、テーマ、プラグイン、PHP等の組み合わせを確認します。作業前後の版、実施日時、作業者、警告やエラー、テスト結果を残します。更新後の版を台帳へ反映し、予定していた対応と実際の結果が一致するかを確認してください。

更新後に表示崩れや不審な動作があった場合

表示崩れやフォーム不具合が出たら、変更した範囲とログを確認し、保守担当者に相談します。無条件に古い版へ戻すと、脆弱性が再び有効になる可能性があります。影響する機能を一時的に制限する、修正する、代替製品を使うなど、セキュリティ上のリスクと業務への影響を合わせて判断します。

不審なファイルや管理者、身に覚えのない投稿、外部への転送がある場合は、更新によって侵害が解消したと考えないでください。ログの保全、原因調査、認証情報の対応、復旧後の確認などが必要になる場合があります。現状を記録したうえで、通常のメンテナンスと侵害対応を分けて依頼しましょう。

保守会社へ確認したい契約と報告の範囲

脆弱性の情報収集、本体やプラグインの更新、緊急時の連絡、バックアップと復元、更新後の動作確認が、保守契約に含まれているかを確認します。「月額保守」と書かれていても作業範囲は会社や契約によって異なります。脆弱性診断、侵害後の復旧、提供終了プラグインの置き換えが別料金になるかも、先に整理しておくと判断しやすくなります。

株式会社ファーストネットジャパンへWordPressの保守を相談する場合は、サイトURL、現在の保守体制、確認できる製品一覧、問題の告知、希望する対応範囲を整理してください。対応内容と費用は個別の状態によって変わります。WordPressの保守について相談する際には、パスワードを問い合わせ本文へ記載する必要はありません。

継続運用では「誰がいつ確認するか」を決める

公開後は、製品一覧の更新、提供元の告知確認、管理者権限の点検、バックアップと復元手順の見直しを継続します。担当者が変わったときも引き継げるよう、台帳と作業記録の保管先を決めておきましょう。更新の完了は口頭の報告だけで判断せず、現在版とテスト結果を確認します。

自動更新を使う範囲も、サイトの機能と運用体制に合わせて決めます。自動化すること自体より、失敗や互換性の問題に気づける仕組み、問い合わせを受ける担当、復元可能なバックアップを用意することが重要です。定期的な確認と、緊急時に動ける連絡経路を両方整えてください。

脆弱性の告知から、自社の対応記録までをつなげる

製品名と版だけでなく、利用している機能を確認する

告知を読んだときは、対象となる製品名、影響を受ける版、修正の案内、利用条件を自社の台帳と照合します。似た名称のプラグインや追加機能を同じものとして扱わず、導入している製品を管理画面や保守資料で確認してください。外部の記事が古い場合は、公式の現在の案内を確認し、過去の修正版をいつまでも最新の推奨版として扱わないようにします。

影響の判断が難しい場合は、未確認のまま安全と結論を出さず、保守担当へ確認する情報を整理します。現在の版、利用している機能、公開しているページ、更新を管理する担当、告知のURLと確認日時をまとめましょう。秘密情報や個人情報を公開の質問欄へ貼り付ける必要はありません。必要な情報を適切な窓口で渡します。

台帳は、一度作って終わりではなく、導入、変更、更新、利用終了の際に見直します。使っていない機能でも、関連する製品や設定が残っていることがあります。削除や停止が必要かは依存する画面や業務を確認して判断し、操作を行う人と確認する人を決めてください。知らない設定を一括で変えるより、対象と影響を整理することが先です。

対応の判断と実施結果を分けて残す

対応の記録には、告知の根拠、自社の確認結果、更新や別の措置を選んだ理由、実施担当、実施日時、実施後の確認をまとめます。対応予定を決めたことと、実際に修正版へ更新したことは別の状態です。保守会社へ依頼した場合も、受付の返答だけで完了とせず、どの製品がどの版になり、何を検査したかを確認しましょう。

すぐ更新できない事情がある場合は、影響を確認したうえで担当者と対応を相談します。表示や連携に不具合があるという理由だけで放置せず、いつ何を検証し、どの条件で更新するかを記録してください。代替の措置を行う場合も、その範囲と限界を明確にし、恒久的な解決を実施したと誤認しないようにします。

更新の検査は、サイトの表示と業務の完了で行う

自社で重要な操作をサンプルにする

更新前に、問い合わせ、予約、ログイン、購入、資料の閲覧など、自社が実際に使う機能を一覧にします。すべてのサイトに同じ検査項目が必要なわけではありません。企業サイトなら問い合わせ、会員サイトなら認証と権限など、停止すると影響がある操作を優先してください。

検証環境では、更新の前後で同じ操作を試します。ページが表示されるだけでなく、送信結果、通知、管理側の記録、次の画面までを確認します。実在の顧客情報や通常の注文を試験に使わず、確認用のデータとその整理方法を用意しましょう。外部サービスへ接続する操作は、そのサービスの試験方法を保守担当と確認します。

表示の確認には、PCとスマートフォン、主要なページ、長い文章や表、画像、フォームの入力とエラー表示を含めます。検査した端末と操作、確認した結果を残すと、不具合が報告されたときに比較できます。検査できなかった機能がある場合は、その範囲を未確認として記録し、すべて正常だったと報告しないことが大切です。

バックアップを戻す判断と手順も確認する

バックアップは、保存した日時、対象となるファイルやデータ、保存先、復元する担当を確認します。保存できたことだけで、必要な状態へ戻せると判断しません。復元の確認が契約に含まれるか、更新前後で増えた問い合わせや注文をどう扱うかも相談してください。

更新後に問題が起きた場合は、表示の不具合と侵害の疑いを分けます。単に旧版へ戻せば安全になるとは限りません。現在の状態とログ、実施した更新を保守担当へ共有し、復元、修正、調査のどれを進めるかを判断します。影響があると分かっている旧版へ戻す場合は、別の対応と再更新の計画を一緒に検討してください。

担当者が交代しても、確認と更新が止まらない契約にする

WordPressの管理は、サイト制作、サーバー、外部サービスなど複数の担当に分かれることがあります。保守契約には、どの製品や設定を確認し、告知を誰が読み、更新を誰が承認し、障害をどこへ連絡するかを明記します。サーバー側の保守があることと、すべてのWordPress製品が更新されることを同じ範囲として扱わないでください。

日常の報告では、実施した更新、見送った理由、検査結果、次の確認を分けます。管理画面の通知が少なくなったことだけで対策完了とは判断せず、対象と実施結果を照合します。担当者の交代時には、契約の範囲、台帳、連絡先、バックアップ、過去の不具合と検査手順を引き継ぎましょう。

運用を振り返る際は、確認漏れや更新を待った理由、業務検査で見つかった問題を整理します。脆弱性に関するニュースの量と、自社サイトで起きた事実を分けて記録してください。保守会社の選定では、絶対安全という説明より、確認、判断、実施、検査の各段階で何を報告するかを比較すると、自社に必要な支援を見極めやすくなります。

更新作業を別の担当へ引き継ぐ際は、次回の予定だけでなく、確認が終わっていない対象と、その理由を明示します。対応済みと未確認を分けることで、担当者交代による確認漏れを防ぎやすくなります。

関連記事

• WordPressセキュリティ対策会社の比較
• WordPressの復旧を依頼する会社の選び方
• ホームページ保守の内容と費用

よくある質問

WordPressの脆弱性が報告されたら必ず更新が必要ですか？

まず自社が使う製品とバージョンが告知の対象かを確認します。対象で修正版がある場合は、深刻度、公開機能、悪用情報と業務への影響を踏まえて速やかに対応を検討し、定期保守日まで待ってよいかも保守担当者に確認してください。

WordPress本体を最新版にすれば安全ですか？

本体だけでなく、テーマ、プラグイン、PHP等のサーバー環境も確認する必要があります。最新版でも脆弱性がゼロになるとは限らないため、更新、権限の管理、バックアップ、動作とログの確認を継続します。

停止中のプラグインは確認しなくてよいですか？

停止中であることだけを安全の根拠にせず、一覧に記録して必要性と残っているファイルを確認します。不要なものを削除・置き換える場合は、依存関係と復元可能なバックアップを先に確認してください。

自動更新を有効にしていれば確認は不要ですか？

自動更新が実際に成功しているか、更新後に重要な機能が動くかの確認は必要です。自動化する範囲を決め、失敗や互換性の問題に気づく担当と連絡経路を用意します。

更新後に不具合が出たら古い版へ戻してよいですか？

古い版へ戻すと脆弱性が再び有効になる場合があります。変更した範囲とログを確認し、修正、機能の一時制限、代替製品などを、セキュリティ上のリスクと業務への影響を合わせて保守担当者と判断します。

WAFがあれば脆弱性への対応は不要ですか？

WAFは補助策になる場合がありますが、脆弱性そのものの修正を保証するものではありません。適用範囲と限界を確認し、修正版への更新や代替策の検討を続けてください。

まとめ

WordPressの脆弱性対策は、対象製品と版の確認、緊急度の判断、バックアップ、更新、業務機能のテスト、記録の更新までを一連の作業として進めます。本体だけでなくテーマ・プラグイン・サーバーも管理し、通常の更新と侵害後の調査を分けて依頼しましょう。担当と連絡経路を決めておくことが、継続的な運用につながります。