2026年9月30日

WordPressのセキュリティ監査を毎月実施するためのチェックリスト

セキュリティ

WordPress のセキュリティ監査を毎月行うなら、「更新と脆弱性」「ユーザーと権限」「ファイル」「ログ」「設定」「バックアップ」の6つの観点を、同じ手順で確認して記録するのが続けやすい方法です。この記事では、各観点で何を見て、どのコマンドや画面で確かめ、異常があったら何をするかをチェックリストの形で示します。毎回1〜2時間ほどで回せる内容を想定しています。

月1回の監査は、日々の運用を見直すための定期点検です。重大な脆弱性が公表されたときの更新は、監査日を待たずにすぐ行ってください。監査の作業では設定やファイルを変えることがあるため、始める前にバックアップを取り、変更はできればステージング環境で試してから本番に反映します。

準備：記録の型を決める

監査は、前回との差を見られて初めて意味を持ちます。表計算ソフトや社内の Wiki に、次の列を持つ記録表を用意します。

確認日、確認者
項目、結果（問題なし・要対応）
対応内容、担当者、期限、完了日

コマンドの出力は、そのままテキストファイルとして保存しておくと、翌月に差分を比べられます。以下のコマンド例は WP-CLI を使っています。WordPress のディレクトリで実行し、環境に合わせて読み替えてください。

1. 更新と脆弱性

[ ] WordPress 本体、プラグイン、テーマに未適用の更新がないか
[ ] 使っていないプラグインとテーマが残っていないか
[ ] 長期間更新されていない、または配布が停止されたプラグインがないか
[ ] 既知の脆弱性が報告されているプラグインがないか
[ ] PHP の版が、提供元のサポート期間内か

wp core check-update
wp plugin list --fields=name,status,version,update_version --format=table
wp theme list --fields=name,status,version,update_version --format=table

停止中のプラグインも、ファイルが残っていれば攻撃の入口になることがあります。使わないものは削除します。テーマは、使用中のテーマと親テーマのほかに、不具合時の切り替え用として標準テーマを1つ残す程度で十分です。

WordPress.org の公式ディレクトリでは、セキュリティ上の問題などで配布が停止されたプラグインのページに、その旨が表示されます。最終更新が長く止まっているプラグインも含め、代わりのプラグインへの移行を検討します。

既知の脆弱性の照合には、WPScan が使えます。脆弱性データベースの照合には API トークンが必要で、無料で使える範囲や回数の上限は変わることがあるため、公式サイトで確認してください（2026年10月現在）。

wpscan --url https://example.com --api-token your-api-token --enumerate vp,vt

WPScan は外部から確認する道具なので、調査してよいのは自分が管理しているサイトだけです。Patchstack や Wordfence Intelligence のように脆弱性情報を提供するサービスもあり、プラグインと連携して通知を受けられるものもあります。提供される機能の範囲はサービスごとに異なるため、導入時に確認してください。

2. ユーザーと権限

[ ] 管理者権限を持つユーザーが、必要な人だけになっているか
[ ] 退職者、契約が終わった外部の制作者のアカウントが残っていないか
[ ] 管理者に2段階認証が設定されているか
[ ] 不要なアプリケーションパスワードが残っていないか

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --format=table
wp user application-password list 1 --fields=uuid,name,created,last_used --format=table

2つ目のコマンドの 1 はユーザーIDです。アプリケーションパスワードは、外部のツールが REST API で操作するための仕組みで、各ユーザーのプロフィール画面からも確認と取り消しができます。誰が何のために作ったか分からないものは取り消します。

アカウントを削除する前に、そのユーザーが書いた投稿を誰に引き継ぐかを決めておきます。権限が過大なユーザーは、削除ではなく「編集者」や「投稿者」への変更で済む場合もあります。

3. ファイル

[ ] WordPress 本体のファイルが改ざんされていないか
[ ] WordPress.org 配布のプラグインのファイルが改ざんされていないか
[ ] アップロード用のディレクトリに PHP ファイルが置かれていないか
[ ] 最近変更された PHP ファイルに、心当たりのないものがないか

wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -type f -name "*.php"
find . -type f -name "*.php" -mtime -30 -not -path "./wp-content/cache/*"

verify-checksums は公式の配布ファイルと照合するコマンドで、有料プラグインなど WordPress.org 以外から入手したものは照合できません。アップロード用のディレクトリには、通常は画像などのメディアしか置かれないため、PHP ファイルが見つかったら中身と作成日時を確認します。キャッシュ系プラグインの生成物が含まれることもあるので、すぐに削除せず出どころを調べます。

あわせて、管理画面からテーマとプラグインのファイルを編集できないよう、wp-config.php に define( 'DISALLOW_FILE_EDIT', true ); が設定されているかも確かめます。

4. ログ

[ ] ログインの失敗が急に増えていないか
[ ] 管理者による心当たりのない操作がないか
[ ] wp-login.php や xmlrpc.php への大量のアクセスがないか

WordPress 本体は管理画面での操作の履歴を残さないため、操作ログを見たい場合は WP Activity Log のような記録用のプラグインを入れておきます。サーバーのアクセスログでは、特定のファイルへの POST の回数を集計すると、総当たりの攻撃の傾向をつかめます。

grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

ログの場所や形式はサーバーによって違うため、パスは環境に合わせて変えてください。ログイン試行の回数制限や2段階認証が効いていれば、失敗が多いこと自体はすぐの危険を意味しませんが、同じ送信元からの集中が続く場合は、サーバーやWAFでの遮断を検討します。

5. 設定

[ ] 本番環境で WP_DEBUG が無効になっているか、debug.log が外部から読めないか
[ ] SSL 証明書の有効期限に余裕があるか
[ ] ディレクトリの一覧表示が無効になっているか
[ ] wp-config.php のファイルの権限が適切か

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -enddate

証明書を自動更新している場合も、更新の処理が失敗していることがあります。Let's Encrypt は有効期限の通知メールの送信を終了する方針を示しているため、外部の監視サービスやこのコマンドで期限を確かめる運用にしておくと安心です。

wp-content/debug.log はブラウザから直接開ける場所にあることが多く、エラーの内容から内部の情報が漏れることがあります。ブラウザで URL を開いて表示されないことを確かめ、表示される場合はサーバーの設定でアクセスを拒否するか、WP_DEBUG_LOG に公開ディレクトリの外のパスを指定します。

6. バックアップ

[ ] バックアップが予定どおり取得されているか
[ ] バックアップがサーバーとは別の場所に保存されているか
[ ] 復元を試し、実際に戻せることを確認したか

バックアップは、取得できていても戻せなければ役に立ちません。毎月とは言わなくても、数か月に一度はステージング環境に復元し、表示とログインができるかを確かめます。保存期間も確認し、改ざんに気付くのが遅れた場合に備えて、少し前の世代までさかのぼれるようにしておきます。

異常を見つけたときの順番

改ざんや不正なアカウントを見つけた場合は、慌ててファイルを消す前に、状態を記録します。おおまかな順番は、ログとファイルの保全、管理者を含む全ユーザーのパスワードとアプリケーションパスワードの変更、侵入経路と思われるプラグインの更新または削除、改ざんされたファイルの復旧です。wp-config.php の認証用キー（ソルト）を新しくすると、ログイン中のセッションを無効にできます。自力での判断が難しいときは、サーバー会社や専門の事業者に相談してください。

まとめ

月次の監査は定期点検。重大な脆弱性の更新は監査日を待たずに行う
更新と脆弱性、ユーザーと権限、ファイル、ログ、設定、バックアップの6観点を同じ手順で確認する
WP-CLI の verify-checksums やユーザー一覧の出力を保存し、前回との差を見る
記録表に結果、担当者、期限を残し、要対応の項目は翌月までに閉じる
バックアップは復元まで試して初めて確認済みと言える