2026.10.20 セキュリティ

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のリリース告知（2026年9月22日）は、深刻度criticalの脆弱性1件を修正したと伝えています。中身はGitHubのセキュリティアドバイザリ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）には2026年9月25日に追加され、米連邦機関への対応期限は3日後の9月28日でした。公表から3日で実悪用の一覧に載った計算です。月1回の手動更新では間に合いません。

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

WordPress 7.1.3（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）の仕組みと影響バージョン・確認手順で扱っています。ここでは、次の脆弱性に備える更新の設定に進みます。

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

公式の更新ドキュメントによると、既存のサイトはマイナー版の自動更新が既定で有効です。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は、既定で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も、使っていないプラグインはシステムから削除するよう書いています。無効化で止めず、削除まで進めてください。

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

wp core verify-checksumsは、インストール済みのファイルをWordPress.orgが公開するチェックサムと照合します。照合時にWordPress本体を読み込まないため、改ざんされたコードを動かさずに検査できる仕組みです。プラグイン側はwp 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の解説は、アプリケーション層のプラグインでログイン試行を制限すると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プラグイン（2026年10月時点で0.17系、有効インストール10万以上）は、認証アプリのTOTP、メールでのコード、バックアップコードに対応しています。管理者には認証アプリを使わせ、メール方式は避けます。メールアカウントが乗っ取られていると、2つ目の要素として機能しないためです。

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

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

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

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

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

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

DISALLOW_FILE_EDITと権限644・755・440による書き換え防止設定

wp-config.phpの公式解説にある定数のうち、すぐ入れてよいのは次の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マニュアルのコア設定によると、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のサポート表では、8.2系のセキュリティ修正は2026年12月31日で終わります。8.4系か8.5系への移行計画は今から立てる時期です。8.5の変更点はPHP 8.5の変更点と新機能まとめにまとめています。

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

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

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

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

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

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

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

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

よくある質問

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の両方を計画的に上げてください。