WordPressの不正アクセス被害の多くは、更新されていないプラグイン、推測しやすいパスワード、使われていない管理者アカウントといった「基本の抜け」から起きています。この記事では、特別な製品を買わなくても今日から実施できる対策を優先度順に8項目にまとめ、それぞれの理由と、設定できたかを確かめる方法まで解説します。読み終えるころには、自分のサイトのどこが弱いかを点検できるようになります。
まず知っておきたい攻撃の実態
WordPressを狙う攻撃の大半は、人が手作業で行うものではなく、ボットによる自動化された総当たりです。攻撃側は「既知の脆弱性があるプラグインのバージョン」や「よく使われるパスワード」の一覧を持っていて、インターネット上のWordPressサイトに片端から試します。つまり、サイトが小規模で無名でも狙われます。
逆にいえば、自動化された攻撃が想定している弱点をふさぐだけで、被害の可能性は大きく下げられます。高度な対策より先に、次の基本を一つずつ片付けるのが近道です。
1. コア・プラグイン・テーマを最新に保つ
最も効果が大きいのが更新です。公開された脆弱性は、修正版が出た直後から攻撃に使われ始めます。古いバージョンのまま放置する期間が長いほど危険が増します。
WordPress 5.5以降はプラグインとテーマにも自動更新の設定があり、管理画面の「プラグイン」一覧で各プラグインごとに有効化できます。コアのマイナーアップデート（セキュリティ修正を含む）は初期設定で自動適用されます。挙動を明示したい場合は wp-config.php で指定できます。
// wp-config.php（"That's all, stop editing!" の行より上に書く）
// true: メジャー・マイナーとも自動更新 / 'minor': マイナーのみ / false: 自動更新しない
define( 'WP_AUTO_UPDATE_CORE', 'minor' );自動更新で表示が崩れることを心配する場合は、マイナーのみ自動にして、メジャー更新はステージング環境で確認してから手動で当てる運用が現実的です。サーバーにSSHで入れるならWP-CLIで状況をまとめて確認できます。
wp core version
wp plugin list --update=available
wp theme list --update=available2. 使っていないプラグイン・テーマを削除する
停止しているだけのプラグインも、ファイルがサーバー上に残っていれば直接アクセスされる経路になり得ます。更新も止まりがちなので、使わないものは「停止」ではなく「削除」してください。テーマも同様で、有効化中のテーマ（子テーマを使っている場合はその親テーマ）と、不具合時の予備として標準テーマを1つ残す程度で十分です。
開発が止まったプラグインにも注意が必要です。公式ディレクトリで長期間更新されていないものや、配布が停止されたものは、代替プラグインへの移行を検討します。
3. 管理者アカウントとパスワードを見直す
ログイン画面への総当たり攻撃は、ユーザー名 admin と頻出パスワードの組み合わせから試されます。次の点を点検してください。
- ユーザー名に
adminやドメイン名など推測しやすいものを使っていない - パスワードは管理画面で生成される長いランダム文字列か、パスワード管理ツールで作ったものにしている
- 管理者権限を持つユーザーが必要最小限になっている（記事を書くだけの人は「編集者」や「投稿者」に）
- 退職者や外注先の古いアカウントが残っていない
管理者の一覧はWP-CLIでも確認できます。
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredさらに、ログイン時に二段階認証を加えると、パスワードが漏れても突破されにくくなります。二段階認証はWordPress本体には含まれていないため、プラグインで導入します。
4. ログイン画面への攻撃を制限する
WordPress本体には、ログイン失敗回数を制限する機能がありません。そのため、何千回でもパスワードを試せる状態になっています。対策は大きく3通りです。
- ログイン試行回数を制限するプラグインを入れる
- サーバーやWAFの機能で
wp-login.phpへのアクセスを制限する - 管理画面を使う場所が固定なら、IPアドレスで
wp-adminとwp-login.phpを絞る
レンタルサーバーには、管理画面への海外からのアクセスを制限する機能や、WAFが標準で用意されていることが多いので、まずはサーバーのコントロールパネルを確認するのが手軽です。
5. XML-RPCを使っていなければ止める
xmlrpc.php は外部アプリから投稿するための古い仕組みで、1回のリクエストで多数のパスワードを試す攻撃に悪用されることがあります。JetpackやXML-RPCを使う投稿アプリを利用していないなら、サーバー側で遮断するのが確実性の高い方法です。
# .htaccess（Apache 2.4）
<Files xmlrpc.php>
Require all denied
</Files># Nginx の server ブロック内
location = /xmlrpc.php {
deny all;
}遮断後は https://example.com/xmlrpc.php をブラウザで開き、403が返ることを確認します。なお、PHPの xmlrpc_enabled フィルターで止める方法もありますが、これは認証が必要な機能を止めるだけで、ファイル自体へのアクセスは受け付けます。
6. wp-config.phpで安全側の設定にする
wp-config.php には、攻撃を受けたときの被害を小さくする定数があります。代表的なのが管理画面からのファイル編集の無効化です。管理者アカウントが乗っ取られても、テーマやプラグインのPHPを画面から書き換えられなくなります。
// wp-config.php
// 管理画面の「テーマファイルエディター」「プラグインファイルエディター」を無効化
define( 'DISALLOW_FILE_EDIT', true );
// 管理画面とログインをHTTPSに限定（サイト全体がHTTPS化済みの場合）
define( 'FORCE_SSL_ADMIN', true );wp-config.php を編集する前には、元のファイルをコピーして残してください。1文字の誤りでもサイト全体が表示されなくなります。また、認証用キー（AUTH_KEY など）がインストール時の空の値やサンプルのままになっていないかも確認します。値は公式の生成サービスで作り直せます。差し替えるとログイン中のユーザーは全員ログアウトされますが、乗っ取りが疑われるときの対処としても有効です。
ファイルのパーミッションは、一般的にディレクトリ755、ファイル644、wp-config.php は640や600など、他のユーザーから読めない値にします。適切な値はサーバーの構成によって異なるため、レンタルサーバーの推奨値に従ってください。
7. HTTPSで通信を暗号化する
HTTPのままだと、公衆無線LANなどでログイン時のパスワードが盗み見られる可能性があります。多くのレンタルサーバーでは無料SSL証明書を数クリックで設定できます。設定後は「設定」→「一般」のWordPressアドレスとサイトアドレスを https:// に変え、HTTPからHTTPSへのリダイレクトも設定します。
8. バックアップを取り、戻せることを確かめる
どれだけ対策しても、被害の可能性はゼロにはなりません。最後の砦はバックアップです。ポイントは次の3つです。
- データベースと
wp-content配下（アップロード画像・テーマ・プラグイン）の両方を取る - サーバーとは別の場所（クラウドストレージなど）にも保管する
- 一度は実際に復元して、手順と所要時間を把握しておく
サーバーと同じ場所にしかバックアップがないと、サーバーごと被害を受けたときに一緒に失われます。改ざんに気づくまで時間がかかることもあるため、数世代分を残しておくと安心です。
対策できているかを点検する方法
設定したら、次の方法で状態を確認します。
まず、管理画面の「ツール」→「サイトヘルス」を開きます。古いバージョンのPHPや、更新が必要なプラグイン、HTTPSの状態など、セキュリティに関わる項目が指摘されます。
次に、ファイルが改ざんされていないかをWP-CLIで調べられます。公式配布物のチェックサムと照合し、変更されたファイルや余計なファイルを報告してくれます。
wp core verify-checksums
wp plugin verify-checksums --all有料プラグインや独自プラグインは公式のチェックサムがないため、警告として表示される点に注意してください。
最後に、サーバーのアクセスログで wp-login.php や xmlrpc.php へのアクセス数を見ておくと、攻撃の多さと対策の効き具合が分かります。
「バージョン非表示」などの効果は限定的
よく紹介される対策の中には、効果が小さいものもあります。たとえば、<meta name="generator"> からWordPressのバージョン表記を消す方法は、攻撃者が別の手段でバージョンを推定できるため、守りとしての効果は限られます。データベースの接頭辞（wp_）を変更する対策も、SQLインジェクションの根本対策にはなりません。
こうした対策はやってもかまいませんが、更新・パスワード・ログイン制限・バックアップの代わりにはなりません。時間が限られているなら、この記事の1〜8を優先してください。セキュリティプラグインの機能や各サーバーの提供機能は変わることがあるため、導入時点の公式情報を確認してください（2026年10月現在の一般的な構成に基づいて解説しています）。
まとめ
- WordPressへの攻撃の多くは自動化された総当たりで、小規模なサイトも対象になる
- 最優先は更新。マイナーアップデートは自動、メジャーは確認してから当てる
- 使わないプラグイン・テーマは停止ではなく削除する
- 管理者は最小限にし、長いパスワードと二段階認証を組み合わせる
- ログイン試行の制限とXML-RPCの遮断で、総当たりの入口を減らす
DISALLOW_FILE_EDITで乗っ取り時の被害を小さくする- 別の場所にバックアップを置き、復元まで試しておく
- サイトヘルスと
wp core verify-checksumsで定期的に点検する