WordPressのセキュリティ対策の基本、更新とプラグイン管理、ログイン保護、権限設定の進め方

WordPressは、ブログから企業サイト、ECサイトまで広く使われているCMSです。利用者が多いぶん攻撃の対象にもなりやすく、狙われるのは本体の未知の欠陥より、更新されていないプラグインやテーマ、使い回されたパスワード、緩すぎるファイルの権限といった、運用で防げる弱点であることがほとんどです。2026年10月末にも、コアの更新処理を狙う脆弱性CVE-2026-119977が修正され、修正の直後から悪用の試みが観測されました。

この記事は、WordPressサイトの運用者や制作会社、Web担当に向けて、WordPress公式の堅牢化ガイド(Hardening WordPress)と総当たり攻撃への対策ガイドを土台に、更新、プラグインとテーマの管理、ログインの保護、権限とファイルの設定、バックアップとログの順で、実務で入れる対策を整理します。設定値や定数は、執筆時点(2026年11月5日)の公式ドキュメントで確認したものに限ります。

WordPressが狙われる主な入り口#

対策の優先順位を決めるために、まず攻撃者がどこから入ってくるかを整理します。WordPressの攻撃の多くは、次の4つの入り口のいずれかを通ります。

Webアプリケーション全般の代表的な弱点は、OWASP Top 10が整理しています。WordPressの場合は、プラグインやテーマの脆弱性がこの一覧のインジェクションやアクセス制御の不備として現れることが多く、利用者側でできる最大の対策は、修正版を早く当てることです。

更新を止めない仕組みを作る#

WordPressのドキュメントによれば、自動のバックグラウンド更新はほとんどのサイトで有効です。コアのマイナー更新(7.1.3から7.1.4のような、セキュリティ修正を含む更新)は、既存のサイトでも既定で自動適用されます。5.6以降に新しくインストールしたサイトは、メジャー更新も既定で自動適用されます。翻訳ファイルも既定で自動更新されます。

プラグインとテーマは、5.5以降、管理画面のプラグイン一覧とテーマの詳細画面から、1つずつ自動更新を有効にできます。既定では無効で、WordPress.orgのセキュリティチームが重大な脆弱性への対応として配信する特別な場合を除き、自動では更新されません。更新の確認は既定で1日2回行われます。

自動更新の範囲は、wp-config.phpの定数WP_AUTO_UPDATE_COREでも指定できます。

業務サイトでメジャー更新を検証してから当てたい場合は、'minor'を指定し、セキュリティ修正の自動適用だけは残すのが現実的です。プラグインの自動更新で表示が崩れるのが心配な場合も、すべて手動にするより、検証環境で確かめてから本番へ当てる手順を決め、更新を溜めないことを優先します。更新の前には、データベースとファイル一式のバックアップを取り、そのバックアップが使えることを確かめます。

ソフトウェアの更新を後回しにしない理由は、次の記事で解説しています。

あわせて読みたい

ソフトウェア更新が脆弱性を塞ぐ仕組みと放置したときのリスク

プラグインとテーマを減らして出どころを確かめる#

プラグインとテーマは、それぞれがサーバー上で動くPHPのコードです。入れている数だけ、脆弱性が見つかる可能性のある場所が増えます。公式の堅牢化ガイドは、プラグインを最新に保ち、使っていないものは削除するよう勧めています。停止しただけのプラグインもファイルはサーバーに残り、直接呼び出せるファイルを含む場合があるため、使わないものは削除します。

入手先は、WordPress.orgのプラグインとテーマのディレクトリや、実績のある開発元に絞ります。有料のテーマやプラグインを非公式に配布した改変版(いわゆるnulled版)は、出どころを確かめられず、更新も届かないため使いません。公式ガイドは、データベースに保存した任意のPHPを実行するタイプのプラグインも避け、必要ならカスタムのページテンプレートで実装するよう勧めています。

更新が長期間止まっているプラグインや、ディレクトリから公開停止になったプラグインは、代替への置き換えを検討します。導入しているプラグインとその版の一覧を、サイトごとに管理しておくと、脆弱性の情報が出たときに影響を素早く判断できます。

ログイン画面とXML-RPCを守る#

公式の総当たり攻撃への対策ガイドは、ユーザー名に「admin」を使わないこと、長く使い回さないパスワードをパスワード管理ツールで管理すること、管理者の人数を絞り日常の作業は最小限の権限の役割で行うことを、最初の対策として挙げています。

二要素認証は、WordPressのコアには含まれていません。管理者と権限の大きいユーザーには、信頼できるプラグインか、組織のIDプロバイダー(シングルサインオン)で二要素認証を必須にします。フィッシングに強いパスキー(WebAuthn)も選択肢で、ガイドは管理者ごとに2つ以上の認証器を登録するよう勧めています。

ログイン画面への攻撃は、WordPressに届く前に止めるほどサーバーの負荷を抑えられます。管理者の接続元が決まっている場合は、Webサーバーでwp-login.phpへの接続元を制限します。Apache 2.4での例は次のとおりです(IPアドレスは例です)。

<Files "wp-login.php">
    Require ip 203.0.113.15 203.0.113.16
</Files>

接続元を絞れない場合は、回数制限を入れます。Nginxでは、limit_req_zoneで1分あたりの要求数の上限を決め、wp-login.phpとxmlrpc.phpの両方に適用します。プラグインによる回数制限もありますが、PHPの中で動くため大量の攻撃では資源を使います。ガイドは、CDNやWAF、Webサーバーなど手前での制限を優先するよう勧めています。

公式ガイドは、xmlrpc.phpを、特に1回の要求で多数の操作をまとめるsystem.multicallを使う攻撃の標的になりやすい入り口として挙げています。WordPress 4.4以降は、1回の要求の中で認証に一度失敗すると後続の認証もすべて失敗するよう改められ、1回の要求で多数のパスワードを試す手口は効かなくなりましたが、要求を繰り返す総当たりとサーバーへの負荷は残ります。使っていなければ無効にします。モバイルアプリや外部サービスとの連携で必要な場合は、WAFのルールと厳しい回数制限で絞ります。外部サービスとの連携には、ユーザーのパスワードを変えずに取り消せるアプリケーションパスワードを使います。

パスワードの総当たりと、その対策の全体像は次の記事にまとめています。

あわせて読みたい

総当たり攻撃と使い回しの悪用から見るログインの守り方

管理画面やログイン時の通信を暗号化するため、サイト全体をHTTPSにします。wp-config.phpにFORCE_SSL_ADMINをtrueで定義すると、ログインと管理画面でパスワードとCookieが平文で送られないようにできます。CDNやリバースプロキシでTLSを終端し、WordPressへはHTTPで転送する構成では、WordPressがHTTPSの要求だと認識できるよう、信頼できるプロキシが付ける転送ヘッダーをもとにした設定を先に入れます。入れずに有効にすると、リダイレクトが繰り返されて管理画面に入れなくなります。

権限とファイルの設定を絞る#

ユーザーの役割は、WordPressの権限グループです。単一サイトでは、管理者、編集者、投稿者、寄稿者、購読者があり、プラグインの追加やテーマの編集ができるのは管理者だけです。記事を書くだけの担当者に管理者を渡さず、役割に合った権限を割り当てます。退職者や外部の制作会社のアカウントは、作業が終わったら削除するか権限を下げます。

ファイルとディレクトリの権限は、公式ガイドではディレクトリ755、ファイル644が基本です。wp-config.phpは、所有者(とWebサーバー)だけが読める400か440にします。ただし、正しい値はサーバーの所有者とWebサーバーの実行ユーザーの関係で変わるため、ホスティング事業者の推奨も確認します。

wp-config.phpで定義できる定数のうち、安全側に倒すものは次のとおりです。

乗っ取られた管理者アカウントから、ファイル編集画面でPHPを書き換えられる被害は典型的なため、DISALLOW_FILE_EDITは多くのサイトで入れて差し支えありません。DISALLOW_FILE_MODSは自動更新を含めて更新を止めるため、更新の手段を別に用意できる場合だけ使います。

Webから直接呼び出す必要のないファイルは、Webサーバーの設定でアクセスを拒否します。公式ガイドは、Apacheでwp-config.phpへのアクセスを拒否する設定と、wp-includes/の下のPHPファイルを直接呼ばせない書き換えのルールを紹介しています。.htaccessに書く場合は、WordPressが上書きする「# BEGIN WordPress」と「# END WordPress」の外側に置きます。コアの更新中の作業ディレクトリを狙ったCVE-2026-119977でも、/wp-content/upgrade/へのWebからのアクセスを拒否する設定が有効な暫定策でした。

あわせて読みたい

WordPressの脆弱性CVE-2026-119977とは、コア更新中の作業ディレクトリを狙う未認証RCEと修正版

データベースは、サイトごとに別のデータベースとユーザーを用意し、使わない機能(外部からのTCP接続など)を無効にします。通常の運用では、データベースのユーザーにはSELECT、INSERT、UPDATE、DELETEがあれば足ります。DROP、ALTER、GRANTを外すと、乗っ取られたときの被害を小さくできますが、スキーマを変えるプラグインやメジャー更新が失敗する場合があるため、復元を確かめたバックアップを用意したうえで判断します。

ユーザー名をadmin以外にする、テーブルの接頭辞を既定のwp_から変えるといった「隠す」対策は、一部の自動化された攻撃を外す効果はありますが、補助的なものです。更新と権限の絞り込みの代わりにはなりません。

PHPとサーバーの版をサポート期間内に保つ#

WordPressは、サーバーで動くPHPの上で動きます。PHP本体の脆弱性は、WordPressをいくら更新しても直りません。2026年10月には、PHP本体の未認証のリモートコード実行につながる脆弱性(php2shell)も修正されました。WordPress.orgの要件ページが推奨するPHPとデータベースの版と、PHPのサポート期限のページを確認し、サポート中の版で動かします。共用サーバーでは、管理画面でPHPの版を選べることが多いため、定期的に見直します。

あわせて読みたい

php2shellとは、PHP本体の未認証RCE(CVE-2026-109618とCVE-2026-109619)の影響と対策

バックアップとログで被害から戻れるようにする#

公式ガイドは、データベースを含めて定期的にバックアップを取り、暗号化やハッシュ値の別保管、書き換えできない媒体への保存でバックアップの完全性を守るよう勧めています。侵害の前の状態へ戻せるよう、コアのファイルとデータベースを含むサイト全体のスナップショットを、信頼できる場所に定期的に保管します。バックアップはサイトと同じサーバーだけに置かず、別の場所にも複製します。

ログは、Webサーバーのアクセスログとエラーログが基本です。誰がいつどこへ要求したかが分かります。ログインしたユーザー名はWebサーバーのログには残らないため、管理画面の操作を記録する監査ログのプラグインも検討します。公式ガイドは、PHPのような実行可能なファイルを中心に、ファイルの変更を監視することも勧めています。変更の監視は、攻撃者に止められにくいよう、サイトとは別の権限で動かします。

WAFは、既知の攻撃の要求を手前で止める仕組みです。プラグイン型、ModSecurityのようなサーバー型、CDNやリバースプロキシ型があります。WAFは修正版を当てるまでの時間を稼ぐ手段で、更新の代わりにはなりません。

あわせて読みたい

バックアップの3-2-1ルールが守る障害とその仕組み

導入の順番#

すでに動いているサイトに対策を入れるときは、効果が大きく、サイトを壊しにくいものから順に進めます。

チェックリスト#

まとめ#

WordPressのセキュリティ対策は、特別な製品を入れることより、更新を止めないこと、入れるものを減らすこと、権限を絞ること、戻せるようにしておくことの積み重ねです。公式の堅牢化ガイドと総当たり攻撃への対策ガイドは、そのための設定を具体的に示しています。

最初の一歩は、コアの自動更新が有効かを確かめ、使っていないプラグインとテーマを削除し、管理者に二要素認証を入れることです。そのうえで、ファイルの権限とwp-config.phpの定数、Webサーバーでのアクセス拒否、バックアップとログを順に整えます。

アカウントの乗っ取りを防ぐ二要素認証の選び方と導入の進め方は、次の記事で解説しています。

あわせて読みたい

多要素認証（MFA）の選び方と導入の勘所。方式比較から運用まで徹底解説