WordPressの不正ログイン対策では、パスワードの使い回しを避け、多要素認証とアカウントの権限を確認します。不正アクセス全体への対策には、本体・テーマ・プラグインの更新、公開範囲、保管情報、バックアップ、保守の担当も含まれます。 ログインを経由せず、脆弱性を悪用される場合があるためです。
管理者本人が設定を見て確認結果を残せば、第三者へパスワードを渡さずに点検を進められます。この記事では、企業サイトの運営者が確認する項目と、保守会社へ依頼する内容を説明します。
すでに身に覚えのない管理者やページの書き換えが見つかった場合は、通常の点検よりも、被害拡大の防止と調査のための記録を優先してください。不正アクセスが疑われるときの初動で、最初に相談・確認することを整理しています。
参照資料と注意喚起の確認日：2026年10月6日。脆弱性の影響条件や修正版は変わるため、作業時には提供元の最新情報を確認してください。
不正ログインと不正アクセスの違い
ここでは、不正ログインを「他人がアカウントの認証を突破・悪用して利用すること」、不正アクセスを「許可されていない操作や侵入を含む広い意味」で使います。法律上の該当性を判定するための定義ではありません。
| 起こり得ること | 点検する対象 |
|---|---|
| 漏れたパスワードの使い回しや、偽のログイン画面への入力 | 認証、復旧用メール、アカウントと権限 |
| ログインを必要としない脆弱性の悪用 | 実際の稼働版、影響条件、修正、公開範囲 |
| 保守用の接続や外部連携の権限の悪用 | 接続経路、権限の範囲、停止・失効の方法 |
ログイン失敗の記録が多いことは、試行があったことを示します。それだけで侵入に成功したとは判断できません。一方、ログイン失敗が記録されていないことも、脆弱性の悪用などがなかった証明にはなりません。
最近の注意喚起も、自分の構成と照合する
2026年9月22日、WordPress本体の重大な脆弱性への修正が公表されました。公式情報には、認証されていない利用者から悪用され得る問題と、テーマ・PHP環境による条件、影響を受ける版、7.1.2などの修正版が示されています。古い系列にも修正が提供されていますが、そのことだけでテーマやプラグインを含む構成全体の保守が続くとは判断できません。WordPress公式の脆弱性情報（新しいタブで開きます）
Patchstackは、修正公開当日から、この脆弱性を狙うアクセスを観測したと報告しています。これは攻撃の試行に関する観測であり、全サイトの被害割合や、自社サイトでの侵入成功を示すものではありません。Patchstackの観測報告（新しいタブで開きます）
「WordPressだから危険」「更新済みだから安全」と一括りにせず、使用している構成と修正の適用状況を照合します。
WordPressの不正アクセス対策で確認する6項目
最初に、各項目の確認結果を「確認できた」「対応が必要」「未確認」に分け、確認日と担当者を残します。「未確認」は安全とも危険とも判定せず、次に誰へ何を確かめるかを決めるための状態です。
1. ログインの入口と、アカウントの権限
WordPress、サーバーの管理画面、契約管理、復旧に使うメールは、それぞれ別の入口です。サイトの管理者だけに多要素認証を設定しても、ほかの入口まで適用されたことにはなりません。
パスワードの使い回しを避け、利用するサービスで提供される多要素認証を確認します。必要な管理者が実際に使っているか、復旧手段を誰が管理するかも調べてください。WordPressへの適用方法は、導入した認証機能やプラグインによって異なります。WordPress公式のログイン攻撃対策（新しいタブで開きます）
退職者や旧担当者のアカウント、共用の管理者、保守会社の権限も確認します。記事を編集する人に、すべての設定を変更できる管理者権限が必要かを見直します。外部連携に発行した権限は、用途と停止・失効の方法を記録します。
2. 本体・テーマ・プラグインと、PHPの保守
実際に使うWordPress本体、テーマ、プラグイン、PHPの版と、修正が提供される状態かを一覧にします。更新通知の有無に加え、公式の注意喚起が自分の構成に該当するかを確かめます。WordPress公式のセキュリティ指針（新しいタブで開きます）、PHP公式のサポート状況（新しいタブで開きます）
本体の更新と、導入した部品すべての更新は分けて確認します。使わないテーマやプラグインも、無効化とファイルの削除を区別してください。停止中の部品に対して、外部から直接アクセスできるファイルが残るかは、その部品の構成によって変わります。
通常の更新は、必要な機能、互換性、バックアップ、戻す手順を確認して進めます。重大な注意喚起や悪用の観測がある場合は、提供元・保守担当と影響を判断し、修正や一時的なアクセス制限を急いで検討します。
3. 公開範囲と、保守用の接続
公開ページのほかに、管理画面、ファイル転送、外部連携、検証用サイトなどの入口を確認します。必要な接続は認証・権限・接続元の制限を検討し、使わなくなった入口は停止する担当と方法を決めます。
WAFは、ウェブへの通信を調べて特定の攻撃を遮断する仕組みです。ログイン試行への制限も役立ちますが、どの入口に適用されるか、遮断の通知を誰が確認するかが点検項目です。WAFの有効化だけで、すべての脆弱性への対処が済むとは判断できません。WordPress公式のログイン攻撃対策（新しいタブで開きます）
検証用サイトを検索対象外にする設定と、第三者の閲覧を制限する認証は、別の対策です。検索に出ないだけで、URLを知る人からのアクセスが防げるわけではありません。
4. 問い合わせ・会員情報が残る場所
問い合わせフォームの内容は、サイトのデータベース、通知メール、外部サービスなどに残る可能性があります。実際の保存先は、導入した機能と設定によって変わります。
情報の種類、保存先、保存期間、閲覧・書き出しできる人を確認します。検証環境の複製、ログ、バックアップも対象に含めます。削除の判断では、業務上の必要性や保存義務も確認してください。IPAの中小企業向け情報セキュリティ対策ガイドライン（新しいタブで開きます）
点検票に残すのは、例えば「問い合わせ内容をデータベースに保存しているか」と、その確認結果です。実際の氏名、連絡先、問い合わせ本文を点検のために転記する必要はありません。
5. バックアップの範囲と、復元の確認
WordPressの復元には、必要なファイルとデータベースの保存を確認します。画像や添付資料、設定を含むか、過去の状態を選べるか、保存の失敗に気付けるかも点検項目です。WordPress公式のバックアップ・保護の指針（新しいタブで開きます）
本番サイトの管理権限が奪われた場合、同じ権限でバックアップまで変更・削除できるかを確認します。保管先の分離と、その保管先のアクセス制限も検討してください。
保存済みの表示だけでは、必要な状態へ戻せるかは分かりません。本番に影響しない環境で復元を試し、サイトと必要な機能が戻ること、担当者が手順を使えることを確認します。侵害が疑われるときは、被害を免れたバックアップの保護も必要です。JPCERT/CCの侵入型ランサムウェア対応FAQ（新しいタブで開きます）
6. 更新・通知・異常時の担当
「保守を委託している」だけでは、すべての作業を任せているかは分かりません。本体・テーマ・プラグイン、サーバー環境、バックアップ、復元、異常の通知について、契約の範囲と担当を確認します。
重大な注意喚起が出たときの連絡先、影響を調べる人、アクセス制限や停止を決める人を記録します。平常時の問い合わせ窓口と、緊急対応の受付時間・契約条件も確かめてください。
不正アクセスが疑われるときの初動
身に覚えのない管理者、ページの書き換え、不審な転送などは、調査が必要な兆候です。その兆候だけで原因や被害範囲までは確定できません。
- 見つけた事実を記録し、連絡する。 発見日時、変更を見つけたページや画面、確認した現象を記録し、社内の責任者、契約しているサーバー提供元、保守担当へ連絡します。必要に応じてインシデント対応を行う専門家へ調査を依頼します。
- 被害の拡大を抑える。 担当者と、公開範囲や接続の制限、侵害が疑われるアカウント・セッションへの対処、バックアップの保護を検討します。具体的な停止範囲は、攻撃の進行と業務への影響を踏まえて判断します。
- 調査用の情報を保全する。 ログ、ファイル、設定、データベースなど、保存すべき対象を調査担当へ確認します。自己判断で一括削除・初期化・復元を進める前に、保全方法と作業記録を決めてください。
- 原因への対処と復旧を確認する。 侵入経路、残された不正なファイルや権限、情報へのアクセス範囲を調べます。修正・認証情報の変更・権限の失効など、状況に合う対処を行い、復旧後も再発の有無を確認します。
被害の拡大を抑える対応と、調査は並行して進める場合があります。詳細な原因調査が終わるまで、すべての制限を待つという意味ではありません。JPCERT/CCのFAQは、侵入型ランサムウェアを対象に、被害の最小化、原因への対処、復旧の考え方を説明しています。JPCERT/CCの対応FAQ（新しいタブで開きます）
サイトが表示に戻ったことと、侵入経路を塞いだこと、情報漏えいの範囲を確認したことは、別々に確かめる必要があります。
パスワードを渡さずに確認する方法
管理者本人が、自分の端末で管理画面や契約情報を開きます。確認結果には、設定の適用範囲、確認日、次の対応を残します。保守担当へ共有するときも、パスワード、認証コード、APIキー、セッション情報を確認票に書き込む必要はありません。
| 確認方法 | 分かることと、確認の限界 |
|---|---|
| 本人が管理画面・契約情報を見る | 稼働版、アカウント、設定など。表示内容と実際の適用範囲を確かめる |
| 保守担当が契約範囲と作業記録を確認する | 更新・保存・復元の実施状況。記録がない項目は追加確認する |
| 公開ページの応答を観測する | HTTPSの接続や転送、取得したページの応答。内部の認証・保管情報・侵入の有無は確定できない |
HTMLに見える版番号やファイル名だけで、実際の稼働版や全体の修正状況を確定することもできません。外部からの観測と、本人・保守担当が内部の設定や記録を確認した結果を分けて残します。
この方法で整理できるのは、確認漏れと追加で調べる項目です。不正侵入がないことを証明するものではありません。
保守会社へ確認する質問
「安全ですか」だけでは、回答の範囲が曖昧になります。次のように、確認する対象と記録を指定すると、担当分担を整理できます。
- 本体・テーマ・プラグイン・PHPの稼働版と、修正の適用状況を、いつ確認しましたか。
- 多要素認証は、どの管理画面と、どのアカウントに適用されていますか。
- 不要なアカウント、保守用接続、検証用サイトは残っていますか。
- 問い合わせ・会員情報は、どこに、どの期間保存され、誰が書き出せますか。
- バックアップの保存範囲と権限はどうなっていますか。最後に復元を試したのはいつですか。
- 異常時に、誰へ、どの時間帯に連絡できますか。調査・停止・復旧は契約のどこまでに含まれますか。
分からない項目は、回答できる担当者と次の確認日を決めます。契約書に含まれている作業と、実際に実施・確認した作業も分けて記録してください。
よくある質問
パスワードを変えれば、不正アクセス対策は完了しますか
完了とは判断できません。侵害されたアカウントへの対処に加え、残ったセッション、外部連携の権限、復旧用メール、脆弱性、不正なファイルなどを状況に応じて調べます。ログインを経由しない脆弱性への修正は、パスワード変更とは別に必要です。
セキュリティプラグインやWAFがあれば安全ですか
それだけでは判断できません。製品ごとの保護範囲と設定、更新・通知への対応を確認します。導入した対策が、必要な入口や管理者に適用されているかも点検してください。
ログイン失敗が多いと、不正アクセスされたということですか
失敗の記録だけでは、侵入成功を示しません。不審な成功ログイン、アカウントやファイルの変更など、ほかの記録と合わせて調べます。成功・失敗の記録が取得できる範囲も確認してください。
URLを入力する診断だけで、安全性は分かりますか
公開ページから確認できる範囲には限界があります。認証設定、保存する個人情報、バックアップの権限、復元の実施状況などは、内部の設定や記録を確認する必要があります。公開ページに問題が見つからなかったことを、侵入がない証明にしないでください。
WordPressを別の仕組みに置き換えれば、保守は不要になりますか
移行後も、編集環境、フォーム、配信、外部連携の認証・更新・復旧は管理する対象です。構成を見直す場合は、サイトの役割と更新方法を整理し、WordPress・旧サイトの全面リニューアルで、移行と引継ぎの確認事項をご覧ください。
日常の点検を、次の対応につなげる
まずは6項目について、確認結果、確認日、担当者、次の対応を一つの記録にします。確認できない項目があれば、その理由と確認先を残してください。重大な注意喚起が出た場合と、侵害が疑われる場合は、通常の点検と対応の優先順位を分けます。
サイトの機能・更新方法・担当分担を見直すご相談は、ウェブ運用・改善から、支援内容をご確認いただけます。ご依頼前に、調査・改修・保守の対象と、緊急対応を含むかなどの条件を合意します。相談窓口には、現在整理したい内容をお知らせください。