WordPressの脆弱性対策｜初心者が今すぐ行う10の手順と確認方法

WordPressの脆弱性対策で最も重要なのは、セキュリティプラグインを入れることだけではありません。

WordPress本体、テーマ、プラグインを安全なバージョンへ更新し、不要な機能を減らし、不正ログインやデータ消失に備えることが基本です。

ただし、何も確認せずに一斉更新すると、テーマやプラグインの不具合によってサイトが表示されなくなる可能性があります。

そのため、バックアップ、更新、動作確認、認証強化、監視という順番で進めることが大切です。

この記事では、WordPressの脆弱性対策を初心者でも実行できる順番に整理し、脆弱性の調べ方や、実際に問題が見つかった場合の対応まで解説します。

WordPressの脆弱性対策で最初に行うこと

最優先で行うべき対策は、バックアップを確保したうえで、WordPress本体、テーマ、プラグインを安全なバージョンへ更新することです。

その後、使っていないプラグインやテーマを削除し、管理者アカウントへ二要素認証を設定します。

WordPressのセキュリティは、一つの対策だけで成立するものではありません。

更新によって既知の脆弱性をふさぎ、認証強化によって不正ログインを防ぎ、バックアップによって問題発生時に復旧できる状態を作ります。

WordPressの脆弱性対策を安全に進める10の手順

WordPressのセキュリティ設定は、思いついたものから追加するのではなく、復旧できる状態を作ってから順番に進めます。

特に更新前のバックアップと、更新後の動作確認は省略しないでください。

1．ファイルとデータベースをバックアップする

WordPressの更新や設定変更を始める前に、ファイルとデータベースの両方をバックアップします。

ファイルにはテーマ、プラグイン、アップロード画像、設定ファイルなどが含まれます。

データベースには記事本文、固定ページ、ユーザー情報、コメント、各種設定などが保存されています。

どちらか片方だけでは、サイト全体を元の状態へ戻せない場合があります。

レンタルサーバーの自動バックアップを利用している場合も、保存期間、保存対象、復元料金、復元方法を確認してください。

バックアップ機能があることと、実際に復元できることは同じではありません。

重要なサイトでは、サーバー上の自動バックアップだけに依存せず、別の保存先にも定期的なバックアップを保管します。

更新直前のバックアップには、取得日時と更新前のWordPress、テーマ、プラグインのバージョンを記録しておくと、問題発生時の判断がしやすくなります。

2．WordPress本体を安全なバージョンへ更新する

管理画面の「ダッシュボード」から「更新」を開き、利用中のWordPressバージョンと更新の有無を確認します。

セキュリティアップデートが公開されている場合は、通常の機能追加よりも優先度が高いため、できるだけ早く適用してください。

ただし、重要なサイトや独自開発機能を含むサイトでは、バックアップを取得したうえで、可能ならステージング環境で動作を確認します。

更新後はトップページだけでなく、記事ページ、問い合わせフォーム、ログイン画面、画像表示、検索機能、決済機能など、サイトで重要な部分を確認します。

自動更新が設定されていても、更新が常に成功するとは限りません。

管理者宛ての更新結果メールや「ツール」の「サイトヘルス」を確認し、バックグラウンド更新に問題が出ていないかを確認してください。

古いメジャーバージョンにも重大な修正が提供されることはありますが、WordPress公式が正式にサポートするのは原則として最新のメジャーバージョンです。

旧系列へ修正版が提供されたからといって、その系列を長期間使い続けてよいとは限りません。

3．テーマとプラグインを更新する

WordPress本体だけを更新しても、古いテーマやプラグインに脆弱性が残っていれば、サイト全体の危険は解消されません。

管理画面の「プラグイン」と「外観」から、更新可能なプラグインとテーマを確認します。

更新履歴に「Security」「Vulnerability」「XSS」「SQL Injection」「CSRF」「Authorization」などの記載がある場合は、セキュリティ修正を含んでいる可能性があります。

更新前には対応するWordPressバージョン、PHPバージョン、テーマとの互換性、開発元の案内を確認してください。

更新後はキャッシュを削除し、表示やフォーム送信に問題がないかを確認します。

自動更新は管理負担を減らせますが、すべてのプラグインへ無条件で有効にする方法が常に最適とは限りません。

セキュリティ修正が多く、互換性問題が起きにくいプラグインは自動更新を検討し、サイトの表示や機能へ大きく影響するものはバックアップと動作確認を組み合わせます。

4．使っていないテーマとプラグインを削除する

停止中のプラグインでも、サーバー上にファイルが残っていれば、脆弱性の影響を受ける可能性があります。

今後も使用しないプラグインは、停止するだけでなく削除してください。

テーマについても、現在使用しているテーマと、復旧用に残すWordPress公式の標準テーマを除き、不要なものは削除します。

同じ機能を持つプラグインを複数入れると、攻撃対象となるコードが増えるだけでなく、機能の競合や更新管理の漏れも起きやすくなります。

長期間更新されていないプラグインや、現在のWordPressバージョンでの動作確認が取れていないプラグインは、必要性を見直してください。

代替プラグインへ変更する場合は、旧プラグインが保存した設定やデータが残ることがあるため、削除前に移行手順を確認します。

プラグイン数だけで安全性が決まるわけではありませんが、利用目的を説明できないプラグインを残さないことが基本です。

5．管理者アカウントのパスワードを強化する

WordPress、レンタルサーバー、FTPやSFTP、データベース、ドメイン管理サービスでは、それぞれ異なるパスワードを使用します。

同じパスワードを使い回すと、別のサービスから認証情報が漏れた際に、WordPressへ不正ログインされる可能性があります。

パスワードは、十分な長さを持つランダムな文字列をパスワード管理ツールで生成し、保存する方法が現実的です。

「admin」というユーザー名を変更するだけでは、十分な脆弱性対策にはなりません。

ユーザー名を推測しにくくする対策よりも、固有の強力なパスワードと二要素認証の方が重要です。

退職者、外部制作者、過去の担当者など、現在は利用していないアカウントが残っていないかも確認してください。

アカウントを削除する際は、そのアカウントが所有する記事を別のユーザーへ引き継ぐ設定を忘れないようにします。

6．管理者アカウントに二要素認証を設定する

二要素認証では、パスワードに加えて、認証アプリの確認コードやセキュリティキーなどを求めます。

パスワードが漏れた場合でも、追加の認証手段がなければログインしにくくなるため、不正ログイン対策として効果的です。

インストール型のWordPress本体には、管理画面用の二要素認証機能が標準搭載されていません。

そのため、信頼できるプラグイン、レンタルサーバーの認証機能、SSOなどを利用して設定します。

最初は管理者権限を持つすべてのアカウントを対象にし、その後、編集者や投稿者へ適用範囲を広げます。

設定時には、スマートフォンを紛失した場合に備えて、バックアップコードを安全な場所へ保管してください。

複数の管理者がいるサイトでは、一人だけが設定して終わりにせず、対象者全員が設定を完了したか確認します。

7．ユーザー権限を必要最小限にする

記事を書くだけの利用者へ管理者権限を与える必要はありません。

WordPressには、管理者、編集者、投稿者、寄稿者、購読者などの権限が用意されています。

各利用者には、担当する作業に必要な範囲だけを与える「最小権限」の考え方を適用してください。

管理者権限を持つアカウントが増えるほど、パスワード漏えい、誤操作、端末の紛失などによる影響範囲が大きくなります。

普段の記事作成には編集者アカウントを使用し、プラグイン追加や設定変更が必要なときだけ管理者アカウントを使う運用も有効です。

外部の制作会社や作業者へ一時的に権限を渡した場合は、作業終了後に削除または権限変更を行います。

共有アカウントは誰が操作したか分かりにくくなるため、原則として利用者ごとに個別のアカウントを発行します。

8．ログイン画面への攻撃を制限する

WordPressのログイン画面には、自動プログラムによる大量のログイン試行が送られることがあります。

対策として、ログイン試行回数の制限、WAF、CDN側のレート制限、CAPTCHAやTurnstileなどを利用します。

サーバーやCDN側で攻撃を遮断できれば、WordPressが処理を開始する前に不要な通信を減らせます。

ログインURLを変更する方法は、自動攻撃の一部を減らす可能性はありますが、それだけで脆弱性や不正ログインを防げるわけではありません。

URL変更を主要な防御策とせず、二要素認証、強力なパスワード、レート制限と組み合わせてください。

XML-RPCを利用していない場合は、サーバーやセキュリティ機能で制限することも選択肢になります。

ただし、WordPressアプリ、外部連携、特定のプラグインなどがXML-RPCを使用している場合があるため、無効化前に利用状況を確認します。

9．HTTPSと安全な接続方法を使用する

WordPressの管理画面やログイン画面は、HTTPSで通信できる状態にします。

HTTPSを使用すると、ブラウザとサーバー間で送受信されるログイン情報や管理画面の通信が暗号化されます。

サイトがHTTPS化されていても、管理者が安全でない端末やネットワークを使用していれば、認証情報が別の経路から漏れる可能性があります。

WordPressを管理するパソコンやスマートフォンのOS、ブラウザ、セキュリティソフトも更新してください。

サーバーへファイルを転送する場合は、通信内容が暗号化されない通常のFTPではなく、SFTPなどの安全な接続方法を利用します。

無料Wi-Fiなど、管理状態が分からないネットワークから重要な設定を変更することも避けた方が安全です。

HTTPS化後は、WordPressアドレスとサイトアドレスが正しいURLになっているか、HTTPの画像やスクリプトが混在していないかも確認します。

10．サーバー設定とファイル変更を制限する

WordPress管理画面には、テーマやプラグインのPHPファイルを直接編集する機能があります。

管理者アカウントを不正利用された場合、この機能を使って悪意のあるコードを書き込まれる可能性があります。

管理画面からファイルを編集する必要がない場合は、wp-config.phpへ次の設定を追加すると、テーマエディターとプラグインエディターを無効化できます。

define( 'DISALLOW_FILE_EDIT', true );

この設定は、管理画面へ侵入された後の被害を抑える対策の一つであり、不正ログインそのものを防ぐものではありません。

ファイルとフォルダの権限についても、必要以上に書き込み可能な状態へ設定しないでください。

特に、問題を解決するためという理由で、すべてのファイルやフォルダを「777」に変更するのは危険です。

適切な権限はサーバー構成によって異なるため、初心者はレンタルサーバーの公式マニュアルまたはサポート案内を優先してください。

wp-config.phpや.htaccessを変更する場合は、変更前のファイルを必ず保存し、一度に複数の設定を変更しないようにします。

WordPressに脆弱性があるか調べる方法

利用中のWordPressに脆弱性があるか確認するときは、管理画面だけで判断せず、WordPress公式情報、開発元の更新履歴、脆弱性データベースを照合します。

確認時には、製品名だけでなく、現在使用している正確なバージョンと、問題が修正されたバージョンを調べることが重要です。

管理画面の更新通知とサイトヘルスを確認する

最初に「ダッシュボード」の「更新」を開き、WordPress本体、テーマ、プラグインに未適用の更新がないか確認します。

続いて「ツール」の「サイトヘルス」を開き、致命的な問題や推奨される改善項目を確認してください。

サイトヘルスでは、更新状況、PHPの状態、HTTPS、バックグラウンド更新など、サイトの保守に関係する問題が表示されます。

ただし、サイトヘルスで「良好」と表示されたからといって、すべての既知の脆弱性が検査されたとは限りません。

サイトヘルスは総合的な運用状態を確認する機能であり、利用中の全プラグインを専門データベースと照合する完全な脆弱性診断ではありません。

WordPress公式のセキュリティ情報を確認する

WordPress本体の脆弱性については、WordPress公式ニュースの「Security」カテゴリーとリリース情報を確認します。

セキュリティリリースには、修正された問題、影響を受ける系列、修正版の番号などが掲載されます。

利用中のバージョンが修正対象に含まれている場合は、バックアップを取得して速やかに更新してください。

ベータ版やリリース候補版は、本番サイトで使用する安定版とは異なります。

数字が新しいという理由だけで、開発・検証用のバージョンを本番サイトへ導入しないようにします。

テーマとプラグインの開発元を確認する

テーマやプラグインの脆弱性は、WordPress本体とは別に公開されることがあります。

WordPress公式ディレクトリのプラグインページ、変更履歴、開発元サイト、サポート情報を確認してください。

脆弱性情報に製品名が書かれていても、同じ名前の別製品や、有料版と無料版の違いがある可能性があります。

プラグインのスラッグ、開発者名、影響を受けるバージョン、修正版の番号まで照合します。

修正版が公開されていない場合は、問題のある機能を無効化するか、プラグイン自体を停止し、必要に応じて削除します。

停止によってサイトの重要機能が使えなくなる場合は、代替手段を準備したうえで対応してください。

脆弱性データベースで製品名とバージョンを検索する

国内情報を確認するときはJVN iPedia、国際的なCVE情報を調べる場合はNVD、WordPressに特化した情報を調べる場合はWPScanなどが利用できます。

データベースごとに掲載時期や評価方法が異なるため、一つの検索結果だけで危険性を断定しないようにします。

CVSSの点数が高い脆弱性でも、認証済みの管理者権限が必要なものと、誰でも攻撃できるものでは緊急性が異なります。

攻撃に必要な権限、外部から悪用できるか、公開サイトで利用している機能か、修正版があるかを確認してください。

WordPressの脆弱性が見つかった場合の対応

利用中のWordPress、テーマ、プラグインに脆弱性が見つかった場合は、修正版への更新を最優先にします。

修正版がない場合は、問題のあるテーマやプラグインを停止し、外部から利用できない状態へ変更します。

更新しただけで、すでに侵入された形跡まで消えるとは限りません。

脆弱性が公開されてから更新までに時間が空いた場合は、見覚えのない管理者、公開日時の不自然な記事、プラグイン一覧、テーマファイル、サーバーログなどを確認します。

WordPress本体のファイルが改変されていないか確認できる環境では、WP-CLIの次のコマンドで公式チェックサムと照合できます。

wp core verify-checksums

このコマンドはWordPress本体のファイルを確認するものであり、アップロード領域、テーマ、すべてのプラグイン、データベース内の不正コードまで完全に検査するものではありません。

結果の意味が分からない場合や、業務サイト、会員サイト、個人情報を扱うサイトでは、サーバー会社またはセキュリティ対応が可能な専門事業者へ相談してください。

WordPressが改ざんされた場合の初動対応

サイトの改ざん、不審な転送、見覚えのない管理者、マルウェア警告などが見つかった場合は、通常の更新作業とは分けて対応します。

最初に現在の状態を保存し、被害の拡大を抑え、侵入経路を取り除いてから復旧します。

1. サーバー会社へ連絡し、必要に応じてサイトの公開を制限します。
2. 感染している可能性がある状態も含め、調査用のバックアップを保存します。
3. WordPress、サーバー、SFTP、データベース、ドメイン管理の認証情報を変更します。
4. 見覚えのない管理者アカウントや外部連携を停止します。
5. 改ざんされたファイル、テーマ、プラグイン、データベースを調査します。
6. 安全性を確認できるバックアップまたは正規ファイルから復旧します。
7. 侵入原因となった脆弱性、設定、漏えいした認証情報を修正します。
8. 復旧後に認証情報をもう一度変更し、二要素認証を設定します。

正常だった時点のバックアップへ戻すだけでは、侵入原因となった古いプラグインや漏えいしたパスワードまで元に戻る可能性があります。

復元と同時に、更新、不要プラグインの削除、パスワード変更、権限確認を行ってください。

原因を特定しないまま公開を再開すると、同じ方法で再び侵入されるおそれがあります。

復旧後は、管理者アカウント、予約投稿、cron、.htaccess、wp-config.php、テーマファイル、プラグイン、アップロードフォルダなどに不審な変更が残っていないか確認します。

WordPressの脆弱性対策でよくある誤解

セキュリティプラグインを入れれば安全になるわけではない

セキュリティプラグインは、ログイン制限、監視、ファイル変更検知、WAFなどを補助する手段です。

古いWordPressや脆弱なプラグインを放置したまま、別のセキュリティプラグインを追加しても、根本的な問題は解消されません。

セキュリティプラグイン自体もソフトウェアであり、更新と管理が必要です。

機能が重複するプラグインを複数導入すると、設定の競合やサイト速度の低下が起きる場合もあります。

必要な防御機能を整理したうえで、信頼できるものを必要最小限に導入してください。

ログインURLを変えるだけでは十分ではない

ログインURLの変更は、定型的なアクセスを減らす補助策にはなります。

しかし、URLが判明した場合や、テーマやプラグインの脆弱性が直接悪用される場合には防御できません。

ログインURLの変更を行う場合も、二要素認証、強力なパスワード、レート制限、更新管理を優先します。

更新しない方がサイトを壊さないという考え方は危険

更新による不具合を避けるため、古いバージョンのまま固定する運用は、既知の脆弱性を残すことにつながります。

安全な対応は更新を止めることではなく、バックアップやステージング環境を用意し、問題が起きても戻せる状態で更新することです。

互換性の問題で更新できないプラグインがある場合は、そのプラグインへ依存し続ける運用そのものを見直す必要があります。

WordPressの脆弱性対策を継続する管理スケジュール

一度設定した対策も、その後の更新や利用者の変更によって状態が変わります。

次のような頻度を目安に、定期的な確認を行ってください。

更新通知を受け取るメールアドレスが古いままだと、緊急情報や自動更新失敗を見落とします。

管理者メールアドレス、レンタルサーバーの登録メール、ドメイン管理サービスの連絡先も定期的に確認してください。

まとめ［Q&A］

さらに詳しく知りたい方へ