WordPress セキュリティ対策の基本と実践 - 公式ハンドブックと脆弱性統計から優先順位を決める

WordPress は世界中で最も広く使われている CMS で、そのぶん攻撃の対象にもなりやすいソフトウェアです。ただ、「WordPress は危ない」と言われる理由の多くは本体ではなく、プラグインと運用にあります。

この記事では、WordPress 公式の Advanced Administration Handbook のセキュリティ章と、セキュリティベンダーの年次レポートをもとに、どの対策から手をつけるべきかを優先順位つきで整理します。設定例は、執筆時点の最新版 WordPress 7.1.3（2026年10月6日リリース）を前提にしています。

公式ハンドブックは、セキュリティを "risk reduction, not risk elimination"（リスクをなくすことではなく、減らすこと）と位置づけています。1つの対策で完璧に守ることはできないので、複数の対策を重ねて、攻撃が成功する確率と被害の大きさを下げていく考え方です。

まず数字で現実を知る

WordPress の脆弱性情報を集めている Patchstack の年次レポート「State of WordPress Security in 2026」は、2025年の状況を次のようにまとめています。

Wordfence の「2024 Annual WordPress Vulnerability and Threat Report」でも、2024年に公開された脆弱性8,223件のうちプラグインが96%、本体は5件で、種類別ではクロスサイトスクリプティング（XSS）が46%、認可の欠如が13%、CSRF が11%でした。

ここから読み取れることは3つです。

1. 本体よりプラグイン。脆弱性の9割以上はプラグインとテーマにある
2. 時間がない。大量に悪用されるものは、公開から数時間で攻撃が始まる
3. 更新だけでは足りない場合がある。修正版が出る前に公開される脆弱性も少なくない

なお、集計方法や対象年はベンダーごとに違うので、数字そのものより傾向として捉えてください。Patchstack は仮想パッチ（WAF のルール）を販売している会社でもあります。

対策の全体像

攻撃の入口ごとに、対策を整理すると次のようになります。

以下、効果が大きい順に見ていきます。

1. 更新する（最優先）

本体は最新版だけがサポート対象

WordPress 公式のセキュリティのページでは、積極的にサポートされるのは最新版だけとされています。古いブランチにもセキュリティ修正がバックポートされることはありますが、これは厚意（courtesy）という扱いです。実際に、4.1〜4.6系へのセキュリティ更新は2025年7月で終了しています（Make WordPress Security）。

本体にも深刻な脆弱性が見つかることはあります。2026年9月22日の WordPress 7.1.2 は、条件によってはリモートでコードを実行されうる、認証不要のパストラバーサルを修正したリリースでした。

自動更新の既定値を知っておく

WordPress 本体の自動更新は、インストールした時期によって既定値が違います（Upgrading WordPress）。

• 5.6 以降に新しくインストールしたサイト: マイナー版もメジャー版も自動更新
• それより前からあるサイト: マイナー版（セキュリティ修正を含む）のみ自動更新

wp-config.php の定数 WP_AUTO_UPDATE_CORE で明示できます。管理画面の設定より優先されます。

// true: すべて自動更新 / false: すべて無効 / 'minor': マイナー版のみ
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

すべての自動更新を止める AUTOMATIC_UPDATER_DISABLED という定数もありますが、公式は無効化を強く勧めていません。メジャー版はテスト環境で確認してから上げたい、という運用なら 'minor' にしておけば、セキュリティ修正だけは自動で入ります。

プラグインとテーマも自動更新できる

プラグインとテーマの自動更新は、WordPress 5.5 で管理画面から個別に有効にできるようになりました（公式ドキュメント）。実行は1日2回で、WP-Cron に依存し、成功・失敗はメールで通知されます。

まとめて有効にするなら、WP-CLI が便利です。

wp plugin auto-updates enable --all
 
# 更新が出ているプラグインを確認する
wp plugin list --update=available

コードで制御する場合は、フィルターを使います。公式は、このフィルターを wp-config.php ではなく mu-plugin（wp-content/mu-plugins/ に置く必ず読み込まれるプラグイン）に書くよう案内しています。

<?php
// すべてのプラグインを自動更新にする
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

自動更新で表示が崩れるリスクを心配する声もありますが、悪用まで数時間という現実を考えると、手動更新が遅れるリスクのほうが大きいことが多いです。崩れて困るサイトほど、後述のバックアップを先に整えたうえで自動更新を有効にするのが現実的です。

PHP も更新対象

PHP のバージョンも重要です。WordPress の推奨環境は PHP 8.3 以上、MySQL 8.0 以上または MariaDB 10.11 以上、HTTPS 対応です。WordPress 7.0 からは最低要件が PHP 7.4 に上がっています。

PHP 自体のサポート期限は php.net で確認できます。執筆時点では、PHP 8.1 以前はすでにサポートが終了し、8.2 のセキュリティ修正も2026年12月31日で終わります。PHP の各バージョンの変化は PHP のバージョン履歴にまとめています。

2. プラグインを減らし、選ぶ

脆弱性の9割がプラグインにある以上、使うプラグインを減らすことがそのまま攻撃対象を減らすことになります。公式ハンドブックの Hardening WordPress も、信頼できる入手元から入れること、使っていないものは削除することを挙げています。

• 無効化ではなく削除する。無効化したプラグインのファイルもサーバーに残り、直接アクセスされる脆弱性の対象になりうる
• 入手元を限定する。WordPress.org の公式ディレクトリか、信頼できる開発元の公式サイトから。配布元の分からない有料プラグインの「無料版」は使わない
• 機能が重なるものはまとめる。テーマや本体の機能で代替できないか検討する

選ぶときの目安と、その限界

WordPress.org のプラグインページには、目安になる表示があります（Alerts and Warnings）。

• 「このプラグインは WordPress の最新3メジャーリリースでテストされていません」: readme の Tested up to が直近3つのメジャーリリースに達していないと表示される
• 閉鎖（closed）の表示: 閉鎖日が表示され、60日後に理由（作者の依頼、ガイドライン違反、セキュリティ問題など）が表示される。閉鎖中は新たにインストールできない

ただし、「テストされていません」の表示は開発者が readme に書いた値に基づくもので、コードがきちんと保守されているかを直接示すものではありません。閉鎖されても、すでにインストールしているサイトに必ず通知が届くとは限らない点も注意が必要です。手元のプラグインの状態は WP-CLI で一覧にできます。

wp plugin list --fields=name,status,version,update,wporg_status,wporg_last_updated

wporg_status が closed のものや、最終更新が何年も前のものは、置き換えを検討します。

サプライチェーン攻撃の実例

プラグインそのものに悪意あるコードが入れられる事件も起きています。

• 2024年6月: WordPress.org の5つのプラグインにバックドアが仕込まれました。原因は、開発者がほかのサービスで漏えいしたパスワードを使い回していたことでした（Wordfence）。これを受けて WordPress.org は、2024年10月1日からプラグイン・テーマ作者のアカウントに2要素認証を必須にしました（Make WordPress Plugins）。
• 2026年4月: 30前後のプラグインを抱える開発元が売却され、買収した側が正規の更新としてバックドアを混入させていたことが発見されました。発見者の報告によると、コードは2025年8月の更新に含まれ、2026年4月に動き出して wp-config.php にスパム配信のコードを書き込んでいました。同じ報告では、WordPress.org がプラグインを閉鎖して強制更新を配信したものの、wp-config.php に書き込まれたコードはその更新では消えないとされています（Anchor Hosting の報告。WordPress.org 側の公式発表は確認できていません）。

後者は、自動更新があだになりうる例でもあります。だからこそ、プラグインの数を絞ること、後述の改ざん検知とバックアップを組み合わせることが大切です。

3. ログインを守る

公式ハンドブックの Brute Force Attacks は、ログインへの総当たり攻撃への対策として次を挙げています。

• 強く、使い回さないパスワードと、パスワードマネージャーの利用
• 管理者全員への2要素認証（2FA）
• フィッシングに強いパスキー（WebAuthn）の検討
• ログイン画面へのレート制限と CAPTCHA（Cloudflare Turnstile など）
• admin のような推測しやすいユーザー名を避け、管理者の人数を絞る

2要素認証はプラグインで入れる

ハンドブックが明記しているとおり、WordPress 本体には2要素認証の機能がありません。プラグインか、シングルサインオン（SSO）の認証基盤で追加します。WordPress.org が開発している Two Factor プラグインは、認証アプリの時刻ベースのコード（TOTP）、メールでのコード、バックアップコードに対応しています。

レート制限

ログイン画面への試行回数を制限すると、総当たりの効率が大きく下がります。ハンドブックには Nginx の設定例が載っています。

limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m;
 
server {
    location = /wp-login.php {
        limit_req zone=logins burst=20 nodelay;
        include fastcgi_params;
        # 通常どおり PHP-FPM などへ渡す
    }
 
    location = /xmlrpc.php {
        limit_req zone=logins burst=20 nodelay;
        include fastcgi_params;
    }
}

1分あたり10回、一時的に20回までの超過を許す設定です。レート制限の考え方はレート制限アルゴリズムの記事で詳しく書いています。サーバーの設定を触れない環境では、WAF の機能やセキュリティプラグインで同様の制限をかけます。Fail2ban のように、失敗が続いた IP を一時的にブロックする方法もハンドブックで紹介されています。一方、国単位で恒久的にブロックする方法は、正規の利用者を締め出すおそれがあるとして勧められていません。

XML-RPC

xmlrpc.php は、system.multicall で1回のリクエストに大量のパスワード試行を詰め込めるため、総当たりの的になりやすい入口です。ハンドブックは、使っていなければ無効にし、使うならレート制限をかけるよう勧めています。

注意したいのは、よく紹介される xmlrpc_enabled フィルターは名前に反して認証が必要なメソッドだけを止めるもので、ピンバックなど認証が不要なものは止まらない点です（公式リファレンス）。外部から一切使わないなら、Web サーバーで xmlrpc.php へのアクセス自体を拒否するほうが確実です。

location = /xmlrpc.php {
    deny all;
}

XML-RPC を使うプラグインや外部の投稿ツールがある場合は、止める前に確認してください。

アプリケーションパスワード

WordPress 5.6 で追加されたアプリケーションパスワードは、REST API などで外部のアプリから認証するための専用パスワードです。通常のログイン画面では使えず、個別に失効させられます。既定では HTTPS のサイト（またはローカル環境）でのみ有効です。

使っていないなら、フィルターで無効にできます。

<?php
// アプリケーションパスワードを使わないサイトでは無効にする
add_filter( 'wp_is_application_passwords_available', '__return_false' );

使っている場合は、wp user application-password list <ユーザー> で発行済みのものを定期的に確認し、使っていないものを削除します。REST API の仕組みは WordPress REST API の記事で解説しています。

ユーザー名が見えることについて

/?author=1 や /wp-json/wp/v2/users からユーザー名が分かることを「脆弱性」として対策する記事をよく見かけます。しかし WordPress の公式見解は、ユーザー名やユーザー ID は秘密情報ではないというものです（Reporting Security Vulnerabilities）。REST API でユーザー一覧を公開しているのも意図的な設計で、守るべきなのはパスワードのほうだ、という立場です。

列挙を止めても総当たりの手間が少し増えるだけなので、優先度は低めです。先にパスワード、2要素認証、レート制限を固めましょう。

4. wp-config.php とサーバーの設定

管理画面からのファイル編集を止める

WordPress の管理画面には、テーマやプラグインの PHP ファイルを直接編集できる機能があります。管理者のアカウントを乗っ取られると、ここから任意のコードを書き込まれます。

// 管理画面のテーマ・プラグインエディターを無効にする
define( 'DISALLOW_FILE_EDIT', true );
 
// ログインと管理画面を HTTPS に強制する
define( 'FORCE_SSL_ADMIN', true );

公式ハンドブックは DISALLOW_FILE_EDIT について、悪意あるファイルのアップロードまでは防げないが、一部の攻撃は止められるかもしれない、という控えめな書き方をしています。

さらに強い DISALLOW_FILE_MODS を true にすると、管理画面からのプラグイン・テーマのインストールや更新もできなくなります（ファイルエディターも無効になります）。デプロイを Git や CI で管理していて、本番のファイルを管理画面から変えさせたくないサイト向けです。管理画面からの更新を前提にしているサイトで有効にすると更新が止まるので、運用と合わせて判断してください。

セキュリティキー

wp-config.php の AUTH_KEY などのセキュリティキーは、ログイン Cookie の署名などに使われます。公式の生成ページで作った値に置き換えると、既存の Cookie がすべて無効になり、全員がログアウトされます。インストール時に設定されていない場合や、乗っ取りが疑われる場合に入れ替えます。

ファイルの権限

ハンドブックは、権限の一例として「ディレクトリは755、ファイルは644」を挙げています。wp-config.php は、一般に400か440にできるとしています（Web サーバーの実行ユーザーから読めることが前提です）。

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 440 /path/to/wordpress/wp-config.php

ファイルの所有者と Web サーバーの実行ユーザーの関係によって適切な値は変わります。777 のように誰でも書き込める権限は使いません。

エラー表示を本番で出さない

PHP のエラーメッセージには、サーバーのパスやプラグインの構成が含まれます。公式ハンドブックは、本番環境で display_errors を有効にしないよう指示しています（Display Errors）。

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

HTTPS

ハンドブックは HTTPS 対応を強く推奨しています（HTTPS）。ログイン Cookie や管理画面の通信を盗み見られないためです。リバースプロキシや CDN の配下で動かす場合は、HTTP_X_FORWARDED_PROTO を正しく扱わないとリダイレクトがループすることがあるので注意します。HTTPS の仕組みは TLS 1.3 の記事で解説しています。

5. 改ざんを検知する

更新と設定で入口を狭めても、侵入を完全に防ぐことはできません。改ざんにすばやく気づく仕組みも用意します。

WP-CLI のチェックサム検証

WP-CLI には、WordPress.org が公開しているチェックサムとファイルを照合するコマンドがあります。

# 本体（wp-admin / wp-includes / ルートのコアファイル）を照合する
wp core verify-checksums
 
# WordPress.org で配布されているプラグインを照合する
wp plugin verify-checksums --all
 
# 管理者権限のユーザーを一覧する（見覚えのないアカウントがないか）
wp user list --role=administrator

wp core verify-checksums は、安全のため WordPress を読み込まずに実行されます（公式ドキュメント）。本体のディレクトリに本来存在しないファイルがあれば「File should not exist」と報告されます。ただし、wp-content 配下（テーマやアップロードしたファイル）と、WordPress.org 以外で配布されているプラグインは照合の対象外です。これらは、ファイルの変更を監視するツールや、Git でのデプロイと差分の確認で補います。

cron で毎日実行して、結果に差分があれば通知するようにしておくと、改ざんに早く気づけます。

WAF

Web アプリケーションファイアウォール（WAF）は、既知の攻撃パターンを含むリクエストを手前で止めます。ハンドブックでは、プラグイン型、ModSecurity のような Web サーバーのモジュール型、CDN などのリバースプロキシ型が紹介されています。修正版がまだ出ていない脆弱性に対しても、WAF のルール（仮想パッチ）で時間を稼げることがあります。

ログ

ログイン試行、管理者の操作、ファイルの変更を記録しておくと、異常に気づくきっかけになり、被害を受けたときの調査にも使えます。ログの取り方の考え方はオブザーバビリティの記事も参考になります。

6. バックアップと復旧の準備

バックアップ

公式の Backups ページのポイントは次のとおりです。

• データベースとファイルは別物で、両方必要
• 更新の前には必ずバックアップを取る
• 頻度の目安は、更新の少ないサイトで週1回、頻繁に更新するサイトで毎日
• 直近3〜5世代を、サーバー・クラウド・手元など別々の場所に保管する
• 自動バックアップでも、ときどき手動で復元できるか確かめる

同じサーバーにしかないバックアップは、サーバーごと侵害されたときに一緒に消されたり、改ざんされたりします。

改ざんされたとき

WordPress.org の「FAQ My site was hacked」は、改ざんされたときの手順を示しています。要点は次のとおりです。

1. 落ち着いて、症状と時刻を記録する
2. サイトと、作業に使う手元の PC の両方をスキャンする
3. ホスティング会社に連絡する
4. SFTP、管理画面、コントロールパネル、データベースなど、すべての経路の認証情報を変える
5. 全ユーザーのパスワードをリセットし、セキュリティキーを入れ替えて全員をログアウトさせる
6. 調査のために、感染した状態のままスナップショットを取っておく
7. wp-admin と wp-includes を、同じバージョンの公式ファイルで SFTP から置き換える（管理画面からの再インストールは既存のファイルを上書きするだけなので使わない）
8. .htaccess、index.php、テーマの header.php・footer.php・functions.php などを確認する
9. 最新版に更新し、きれいにしたあとでもう一度パスワードを変える
10. 侵入経路を調べ、同じ手口で再侵入されないよう対策する

7番が示すように、管理画面からの「再インストール」は、本来ないはずのファイル（バックドア）を消しません。前述の 2026年4月の事例のように wp-config.php に書き込まれたコードも、本体の再インストールでは残ります。

効果が限定的な対策

よく紹介される対策の中には、公式が効果を限定的と見ているものもあります。やってはいけないわけではありませんが、これだけで安心しないことが大切です。

ハンドブックの中でも記述が食い違っている部分があるので、更新日の新しいページを優先して読むのがよいでしょう。

チェックリスト

最後に、優先度の高い順にまとめます。

まとめ

• 脆弱性の9割以上はプラグインとテーマにあり、大量に悪用されるものは公開から数時間で攻撃が始まる
• 最優先は更新。本体は最新版だけがサポート対象で、プラグインも含めて自動更新を有効にする
• プラグインは減らし、入手元を限定する。サプライチェーン攻撃の例もあるので、改ざん検知とバックアップを組み合わせる
• ログインは強いパスワード、2要素認証（本体にはないのでプラグインで）、レート制限で守る
• DISALLOW_FILE_EDIT、FORCE_SSL_ADMIN、適切なファイル権限、本番でのエラー非表示を設定する
• WP-CLI のチェックサム検証と WAF、ログで改ざんに早く気づけるようにする
• バックアップは複数世代を別の場所に置き、改ざんされたときは公式の手順に沿って、再インストールではなくファイルを置き換える
• ログイン URL の変更やテーブル接頭辞の変更は、補助的な対策にとどめる

日本語の公的な資料としては、IPA の「安全なウェブサイトの作り方」が、プラグインに多い XSS や CSRF などの脆弱性の仕組みと対策を解説しています。プラグインを自作・改修する場合は、あわせて読んでおくと役に立ちます。

参考リンク

• Security（WordPress Advanced Administration Handbook）
• Hardening WordPress
• Brute Force Attacks
• Multi-Factor Authentication
• Application Passwords
• Backups
• Upgrading WordPress（自動更新）
• wp-config.php（Advanced Administration Handbook）
• FAQ My site was hacked（WordPress.org）
• WordPress 7.1.3 Maintenance and Security Release
• WordPress Security（wordpress.org）
• Requirements（wordpress.org）
• Supported Versions（php.net）
• State of WordPress Security in 2026（Patchstack）
• 2024 Annual WordPress Vulnerability and Threat Report（Wordfence, PDF）
• wp core verify-checksums / wp plugin verify-checksums（WP-CLI）
• Two Factor（WordPress.org プラグイン）
• Upcoming security changes for plugin and theme authors on WordPress.org
• 安全なウェブサイトの作り方（IPA）