---
title: "WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】"
url: "https://www.issoh.co.jp/tech/details/18610/"
published: 2026-10-20
updated: 2026-10-20
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】

WordPressのセキュリティ対策は、プラグインを1つ入れて終わる作業ではありません。2026年9月に公表されたCVE-2026-87902は、4.7以降のコアすべてに影響し、サーバーとテーマの条件がそろうと未認証でコード実行に届く脆弱性でした。この記事では、ログイン、プラグイン、権限、サーバー設定、コア更新の攻撃面ごとに、wp-config.phpの定数、Webサーバーの設定、WP-CLIの確認コマンドを公式ドキュメントに沿って示します。数値と版番号は2026年10月20日時点の実測です。

## まとめ：WordPressのセキュリティ対策は更新運用と管理者権限の絞り込みから着手

優先順位ははっきりしています。最初にコアとプラグインの更新が止まっていないかを確かめ、次に管理者アカウントとログイン画面を絞り、そのあとでWAFや監視を足します。逆の順で、セキュリティプラグインを先に入れても、脆弱な版のプラグインが残っていれば防げません。

| 攻撃面   | 最初に入れる対策    | 確認の手段            |
| ----- | ----------- | ---------------- |
| コア    | マイナー自動更新の維持 | stable-check API |
| プラグイン | 未使用の削除と更新   | wp plugin list   |
| ログイン  | IP制限と二要素認証  | サーバー設定           |
| 権限    | 管理者の棚卸し     | wp user list     |
| ファイル  | 編集機能の停止     | verify-checksums |

2026年10月20日時点の最新版は7.1.3です。7.1.2は公式APIで「insecure」と判定されているため、9月に更新を済ませたサイトでも、もう一段の更新が必要です。

## 直近の脆弱性と更新運用：7.1.2と7.1.3の修正内容から決める自動更新

2026年のWordPressコアは、7月のwp2shell、9月の7.1.2、10月の7.1.3と、短い間隔でセキュリティリリースが続きました。どの版まで上げればよいかを、公式の発表と脆弱性情報から確かめます。

### 7.1.2で修正されたCVE-2026-87902とKEV追加から読む対応期限

[WordPress 7.1.2のリリース告知](https://wordpress.org/news/2026/09/wordpress-7-1-2-release/)（2026年9月22日）は、深刻度criticalの脆弱性1件を修正したと伝えています。中身は[GitHubのセキュリティアドバイザリGHSA-7hp8-65ch-5whp](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp)に書かれており、ページテンプレートの解決処理で、有効なテーマの外にあるローカルの`.php`ファイルを未認証で読み込ませられるというものです。CVSS v4.0は9.2で、影響は4.7.0から7.1.1まで。修正は7.1.2のほか、7.0.6、6.9.9、6.8.10から4.7.37まで各ブランチに配られました。

コード実行に届くには前提条件が2つあります。サーバー上に攻撃者が選べるPHPファイルがあること（アドバイザリは`register_argc_argv`が有効な環境の`pearcmd.php`を例に挙げています）。そして、有効なテーマの直下に`page-`で始まるディレクトリがあることです。条件付きとはいえ、[CISAの既知の悪用された脆弱性カタログ（KEV）](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)には2026年9月25日に追加され、米連邦機関への対応期限は3日後の9月28日でした。公表から3日で実悪用の一覧に載った計算です。月1回の手動更新では間に合いません。

### 7.1.3で直った7件の脆弱性と旧ブランチへのバックポートの扱い

[WordPress 7.1.3](https://wordpress.org/news/2026/10/wordpress-7-1-3-maintenance-and-security-release/)（2026年10月6日）は、セキュリティ修正7件とバグ修正4件を含みます。保留中コメント経由の管理画面の保存型XSS、WXRエクスポートの二次SQLインジェクション、非公開投稿のコメントが未認証で読める問題、投稿者ロールが権限なしに投稿を先頭固定できる問題などです。旧ブランチへのバックポートは「準備ができ次第順次」とされ、公式APIでは10月20日時点で7.0系が7.0.7、6.9系が6.9.10を自動更新の配布対象にしています。

手元の版が安全かは、公式のstable-check APIで判定できます。各版に`latest`、`outdated`、`insecure`のいずれかが返ります。

```
# サイトのコア版を確認する
wp core version

# 公式APIで7.1系の各版の判定を見る（7.1.2以前はinsecure）
curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep -o '"7\.1[.0-9]*":"[a-z]*"'
```

wp2shellの経緯と影響版は[wp2shellとは？WordPress未認証RCE（CVE-2026-63030・CVE-2026-60137）の仕組みと影響バージョン・確認手順](https://www.issoh.co.jp/tech/details/15412/)で扱っています。ここでは、次の脆弱性に備える更新の設定に進みます。

### wp-config.phpとフィルターでコアとプラグインの自動更新範囲を固定

[公式の更新ドキュメント](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/)によると、既存のサイトはマイナー版の自動更新が既定で有効です。5.6以降に新規インストールしたサイトは、メジャー版も自動で上がります。一方でプラグインとテーマは、セキュリティチームが判断した特例を除き、既定では自動更新されません。脆弱性の大半はプラグイン側で出るため、ここを放置しないことが肝心です。

```
<?php
// wp-config.php：コアはマイナー（セキュリティ）更新のみ自動にする（既定値）
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// wp-content/mu-plugins/auto-update.php：指定したプラグインだけ常に自動更新する
function issoh_auto_update_plugins( $update, $item ) {
    $slugs = array( 'akismet', 'two-factor' );
    return in_array( $item->slug, $slugs, true ) ? true : $update;
}
add_filter( 'auto_update_plugin', 'issoh_auto_update_plugins', 10, 2 );
```

注意が必要なのは、次の1つの設定です。`auto_update_plugin`に`__return_false`を返すと、セキュリティチームが重大な脆弱性で強制配布する更新まで止まります。「更新で表示が崩れるのが怖い」という理由で全停止するくらいなら、ステージングで確認する対象を絞り、残りは自動に任せるほうが事故は少なくなります。

## WP-CLIで脆弱なプラグインと改ざんされたコアファイルを洗い出す手順

管理画面の更新一覧は、ログインした人が見なければ気づけません。WP-CLIで同じ情報をコマンドにしておくと、cronや保守の定例作業に組み込めます。

### wp plugin listで更新待ちと配布状況の怪しいプラグインを一覧化

[wp plugin list](https://developer.wordpress.org/cli/commands/plugin/list/)は、既定で`update_version`（更新先の版）と`auto_update`（自動更新の有無）を出します。任意フィールドの`wporg_status`と`wporg_last_updated`を足すと、WordPress.org上での公開状況と最終更新日も確認できる一覧です。何年も更新されていないプラグインや、公開が止まったプラグインは、脆弱性が見つかっても修正版が出ない前提で扱います。

```
# 更新待ち・自動更新の有無・WordPress.org上の状態を一覧にする
wp plugin list --fields=name,status,version,update_version,auto_update,wporg_status,wporg_last_updated

# 無効化したまま残っているプラグイン（使わないなら削除する）
wp plugin list --status=inactive --field=name
```

無効化したプラグインもファイルはサーバーに残り、直接アクセスされる経路は消えません。公式の[Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/)も、使っていないプラグインはシステムから削除するよう書いています。無効化で止めず、削除まで進めてください。

### verify-checksumsでコアとプラグインのファイル改ざんを検出する

[wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/)は、インストール済みのファイルをWordPress.orgが公開するチェックサムと照合します。照合時にWordPress本体を読み込まないため、改ざんされたコードを動かさずに検査できる仕組みです。プラグイン側は[wp plugin verify-checksums](https://developer.wordpress.org/cli/commands/plugin/verify-checksums/)が同じ役割を持ちます。

```
# コアファイルの改ざんと、ルート直下の見慣れないファイルを検出する
wp core verify-checksums --include-root

# WordPress.orgで配布されているプラグインをまとめて照合する
wp plugin verify-checksums --all

# 管理者ロールのユーザーと登録日を棚卸しする
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
```

照合できる対象は、WordPress.orgで配布されているものだけです。有料プラグインや自作テーマは対象外なので、Gitで管理したファイルとの差分で確かめる運用を別に持ちます。管理者一覧に覚えのないアカウントや、最近の登録日が並んでいたら、侵入を疑って調査に切り替えます。

## ログイン画面への総当たり攻撃を止めるIP制限と二要素認証の設定

[公式のBrute Force Attacksの解説](https://developer.wordpress.org/advanced-administration/security/brute-force/)は、アプリケーション層のプラグインでログイン試行を制限するとPHPの処理資源を消費するため、可能ならエッジやWebサーバーの層で止めるよう勧めています。この順番で設定します。

### wp-login.phpをApacheとNginxの設定でIPアドレス制限する書き方

管理者が決まった拠点やVPNから作業するなら、`wp-login.php`へのアクセスそのものを許可したIPアドレスに絞るのが最も効きます。公式の例をもとにした設定です（IPアドレスはドキュメント用の例示アドレス）。

```
# Apache（.htaccess または VirtualHost）
<Files "wp-login.php">
    Require ip 203.0.113.15 203.0.113.16
</Files>

# Nginx（server ブロック内）
location = /wp-login.php {
    allow 203.0.113.15;
    allow 203.0.113.16;
    deny all;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}
```

Nginxでは`location`を分けるとPHPへの受け渡しも書き直す必要があり、ソケットのパスは環境ごとに違います。会員登録やコメントのログインを一般利用者に開いているサイトでは、IP制限は使えません。その場合は次の二要素認証が主役になります。

### Two Factorプラグインで管理者に二要素認証を入れる方式の選び方

WordPress本体には二要素認証が入っていません。WordPress.orgで配布されている[Two Factorプラグイン](https://wordpress.org/plugins/two-factor/)（2026年10月時点で0.17系、有効インストール10万以上）は、認証アプリのTOTP、メールでのコード、バックアップコードに対応しています。管理者には認証アプリを使わせ、メール方式は避けます。メールアカウントが乗っ取られていると、2つ目の要素として機能しないためです。

バックアップコードは必ず発行し、パスワード管理ツールなど別の場所に保管します。認証アプリを入れたスマートフォンを失くした管理者が、復旧のためにデータベースを直接書き換える事態を防ぐためです。要素の種類やフィッシングに強い方式の違いは、[多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](https://www.issoh.co.jp/tech/details/13314/)で整理しています。

### adminユーザーの廃止とxmlrpc.phpを止めるかどうかの判断基準

公式ドキュメントは、ユーザー名`admin`を使わないよう明記しています。古いサイトに残っている場合は、別名の管理者を作ってから`admin`を削除し、投稿は新しいユーザーへ引き継ぎます。

もう1つの入口が`xmlrpc.php`です。1回のリクエストで多数のパスワードを試せる`system.multicall`が総当たりに使われてきました。ただし、よく紹介される`xmlrpc_enabled`フィルタは認証を伴うメソッドを止めるだけで、ピンバックは残ります。JetpackやモバイルアプリがXML-RPCを使う場合もあるため、止める範囲は[xmlrpc.phpとは？無効化で止まる範囲と止まらない範囲を実装から整理](https://www.issoh.co.jp/column/details/7727/)で確かめてから決めてください。

## 権限とファイル設定でプラグイン経由の侵入後の被害を抑える設定

ここからは、侵入を許した後に被害を広げないための設定です。管理画面を乗っ取られても、ファイルを書き換えられない、PHPを動かす足場が無い状態にしておきます。

### DISALLOW\_FILE\_EDITと権限644・755・440による書き換え防止設定

[wp-config.phpの公式解説](https://developer.wordpress.org/advanced-administration/wordpress/wp-config/)にある定数のうち、すぐ入れてよいのは次の2つです。

```
// 管理画面のテーマ・プラグインファイル編集機能を止める
define( 'DISALLOW_FILE_EDIT', true );
// ログインと管理画面をHTTPSに限定する
define( 'FORCE_SSL_ADMIN', true );
```

```
# ディレクトリ755・ファイル644にそろえ、wp-config.phpは440にする
find /var/www/wordpress/ -type d -exec chmod 755 {} \;
find /var/www/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /var/www/wordpress/wp-config.php
```

管理画面のファイル編集は、乗っ取られた管理者アカウントからPHPを書き込む最短の経路です。停止しても通常の更新には影響しません。より強い`DISALLOW_FILE_MODS`は、プラグインとテーマのインストールと更新も停止する設定です。WP-CLIやデプロイで更新を回す体制が無いサイトで入れると、更新が止まって逆に危険になります。パーミッションの数値はHardening WordPressの推奨値で、`wp-config.php`は400か440とされています。

### 管理者アカウントの棚卸しと投稿者・編集者に権限を絞る運用ルール

7.1.3で直った脆弱性のうち、保存型XSSは保留中のコメントを経由して管理画面で発火するものでした。管理画面に入れる人が多いほど、このような脆弱性の当たり先が増えます。記事を書くだけの担当者は「投稿者」、他人の記事も直す担当者は「編集者」にとどめ、管理者は2〜3人までに絞ります。

サイト公開時の制作会社や退職者のアカウントが、管理者のまま残っていないかも確かめます。先ほどの`wp user list`を四半期に1回走らせ、役割と在籍を突き合わせるだけで、こうした管理者アカウントの残存を防げるためです。共有アカウントを使い回している場合は、誰が何をしたかを追えないため、1人1アカウントに分けるところから始めます。

### PHPのregister\_argc\_argvとサポート期限でサーバー側の前提を潰す

CVE-2026-87902の前提条件は、WordPressの外にありました。[PHPマニュアルのコア設定](https://www.php.net/manual/en/ini.core.php)によると、`register_argc_argv`の既定値は有効で、PHP 8.5.0で非推奨になっています。Webサーバー経由で引数を受け取る必要が無ければ、無効にして攻撃の足場を1つ減らせます。

```
; php.ini（PHP-FPM・Apacheモジュールなど Web 側の設定ファイル）
register_argc_argv = Off
```

CLI用とWeb用でphp.iniが別ファイルの環境が多く、`php -i`で見える値はCLI側です。Web側の値は、一時的に置いた`phpinfo()`で確かめて、確認後すぐに削除します。併せて確認する対象は、PHP本体のサポート期限です。[php.netのサポート表](https://www.php.net/supported-versions.php)では、8.2系のセキュリティ修正は2026年12月31日で終わります。8.4系か8.5系への移行計画は今から立てる時期です。8.5の変更点は[PHP 8.5の変更点と新機能まとめ](https://www.issoh.co.jp/tech/details/8179/)にまとめています。

## WAFとセキュリティプラグインの役割分担と保守を外部に任せる判断基準

最後に、どこまで自社で運用し、どこから外の仕組みや人に任せるかを決めます。

### エッジのWAFでレート制限しプラグインは監査と検知に回す構成

公式ドキュメントは、CloudflareやSucuri、ホスティング事業者のマネージドWAFを挙げ、攻撃をサーバーに届く前に遮断できる点を利点としています。総当たりや既知の攻撃パターンはWAFで落とし、WordPress内のセキュリティプラグインはログイン履歴の記録、ファイル変更の検知、脆弱なプラグインの通知に使います。両方に同じ遮断を設定すると、正規の利用者が誤って止められたときに原因を追いにくくなるため、遮断の重複設定には注意が必要です。WAFの方式と選び方は[WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説](https://www.issoh.co.jp/tech/details/13275/)を参照してください。

WAFは更新の代わりにはなりません。シグネチャは公表された攻撃パターンに合わせて作られるため、未知の変形や、正規のリクエストと区別しにくい経路は通ることがあります。WAFは修正版を当てるまでの時間を稼ぐ手段と位置づけます。

### セキュリティ対策を自社運用で回せる条件と保守委託へ切り替えるべき場面

自社で回せるのは、次の3つがそろうときです。セキュリティリリースの告知を当日中に見る担当者がいること。ステージングで更新を確かめてから本番に出せること。改ざん時にバックアップから戻した経験があることです。戻せる状態の作り方は[WordPressのバックアップ設計：WP-CLIでの取得・世代管理・復元テストの手順](https://www.issoh.co.jp/tech/details/18612/)で、取得から復元テストまでコマンド付きで解説しています。1つでも欠けるなら、更新と監視は外部に任せます。改ざんされてから復旧と調査を頼むより、更新が止まらない体制に月額を払うほうが、費用の見通しが立つからです。

逆に、会員情報や決済を扱わない数ページの会社案内サイトで、WAFとプラグインを何重にも重ねるのは過剰です。マイナー自動更新、プラグインの削減、二要素認証の3点で足ります。保守を外部に出す場合の作業範囲と費用の目安は[WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準を解説](https://www.issoh.co.jp/column/details/15799/)で、当社の対応範囲は[WordPress保守・メンテナンス](https://www.issoh.co.jp/service/web/wordpress-support/)で紹介しています。

## よくある質問

WordPressのセキュリティ対策について、よく寄せられる質問にまとめて答えます。

### WordPressのセキュリティプラグインは入れたほうがよいですか？

入れる価値はありますが、役割はログイン履歴の記録やファイル変更の検知と考えてください。総当たりの遮断をプラグインだけで行うと、攻撃のたびにPHPが動いてサーバーの負荷が上がります。遮断はWAFやWebサーバー設定で行い、プラグインは監査と通知に使う役割分担が適した構成です。同じ機能を持つプラグインを複数入れると競合の原因になるため、1つに絞ります。

### 自動更新を有効にすると、サイトが壊れることはありませんか？

マイナー版の自動更新はセキュリティとバグ修正が中心で、機能の追加や大きな変更はメジャー版で入ります。崩れやすいのはメジャー版の更新と、大型のプラグインの更新です。マイナー版は自動に任せ、メジャー版と主要プラグインはステージングで確かめてから手動で上げる、という分け方が現実的です。全停止すると、セキュリティチームの強制配布も届かなくなります。

### WordPressの脆弱性情報はどこで確認すればよいですか？

コアの脆弱性は、WordPress.orgのニュースのリリース告知と、GitHubのwordpress-developリポジトリのセキュリティアドバイザリが一次情報です。実際に悪用されているかはCISAのKEVカタログで確かめられます。プラグインの脆弱性は、各プラグインの変更履歴と、脆弱性データベースを提供するセキュリティ企業の情報を併せて見ます。

### ログインURLを変更するだけで十分な対策になりますか？

ボットからのアクセスは減りますが、それだけでは足りません。URLはプラグインの痕跡やリダイレクトから推測されることがあり、パスワードが漏れていれば突破されます。公式ドキュメントも、推測されにくさに頼る対策は補助的な位置づけにしています。IP制限か二要素認証を先に入れ、URL変更は上乗せとして扱うのが順序です。

### 古いバージョンのWordPressを使い続けると何が起きますか？

公式に積極的なサポートを受けるのは最新版だけです。CVE-2026-87902のように4.7まで修正が配られる例もありますが、7.1.3の修正のバックポートは順次とされ、届く時期は保証されていません。PHPも古い版はセキュリティ修正が止まります。改ざんや情報漏えいの入口になるため、コアとPHPの両方を計画的に上げてください。

## 関連記事

- [WordPress保守運用とは：作業範囲・費用相場と内製か外注かの判断基準を解説](https://www.issoh.co.jp/column/details/15799/)：更新と監視を委託するときの範囲と費用
- [wp2shellとは？WordPress未認証RCE（CVE-2026-63030・CVE-2026-60137）の仕組みと影響バージョン・確認手順【2026年10月】](https://www.issoh.co.jp/tech/details/15412/)：2026年7月のコア脆弱性の仕組みと確認手順
- [xmlrpc.phpとは？無効化で止まる範囲と止まらない範囲を実装から整理](https://www.issoh.co.jp/column/details/7727/)：XML-RPCを止める範囲の決め方
- [WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説](https://www.issoh.co.jp/tech/details/13275/)：WordPressの前段に置くWAFの選び方
- [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](https://www.issoh.co.jp/tech/details/13314/)：管理者ログインに入れる認証方式の比較

---

出典: [WordPressセキュリティ対策：攻撃面ごとの設定とWP-CLIでの確認手順【2026年10月・7.1.3対応】](<https://www.issoh.co.jp/tech/details/18610/>)（株式会社一創）