WordPressの脆弱性を確認する方法|本体・プラグインの更新と対処の手順

WordPressの脆弱性は、版の把握と公開情報との照合で確認する

脆弱性の確認は、自分のサイトで動いている版を正確に知る作業と、その版が公開の脆弱性情報で『影響を受ける版』に入るかを照らす作業の2段階です。版が分からなければ照合できず、照合しなければ更新の優先順位も決められません。

版の把握には管理画面とWP-CLIを、照合にはWordPress公式の発表、JVN iPedia、NVDを使います。外からの確認は、攻撃者と同じ立場で、自分のサイトから何が見えているかを点検する作業です。4つの方法は、分かることと分からないことがそれぞれ違います。

脆弱性とは何か: 本体、テーマ、プラグインで起きる場所の違い

脆弱性は、ソフトウェアやWebサイトの機能や性能を損なう、セキュリティ上の問題箇所です。IPAのセミナー資料『ウェブサイトの安全な運用について』は、放置するとサイトの乗っ取りや情報漏えいなどにつながるおそれがあると説明しています。Webサーバーの設定の不備も、脆弱性とみなされます。

WordPressでは、本体、テーマ、プラグインのどこでも脆弱性は見つかります。本体はWordPressのセキュリティチームが修正版を出し、多くは自動更新で届く仕組みです。プラグインとテーマは開発者ごとに対応が分かれ、管理者が更新しない限り古い版が残ります。

本体: 2026年も重大な修正が続いている

本体でも、深刻な脆弱性は見つかります。2026年7月17日のWordPress 7.0.2は、深刻度『critical』と『high』の2件を修正しました。影響を受ける版のサイトには、自動更新の仕組みで強制的に更新が配信されています。

2件のCVE番号は、CVE-2026-60137とCVE-2026-63030です。IPAは、組み合わせると遠隔でのコード実行が生じる可能性があるとして、7月22日にWordPressの脆弱性対策についての注意喚起を出しました。

9月以降も、17日の7.1.1で11件、22日の7.1.2で深刻度『critical』の1件、10月6日の7.1.3で7件のセキュリティ修正が出ています。7.1.3の7件には、XSS(クロスサイトスクリプティング)2件やSQLインジェクションの修正が含まれます。

2026年10月12日時点の最新版は7.1.3です。公式のリリース一覧は『7.1系の最新版だけが安全に使え、積極的に保守されている』と明記しています。古い系統にも修正が移植されることはありますが、公式はこれを厚意(courtesy)と位置づけ、2025年7月には4.1から4.6へのセキュリティ更新を終えました。

プラグインとテーマ: 提供元ごとに対応が分かれる

プラグインとテーマの修正版を出すのは、それぞれの開発者です。自動更新は既定で無効で、WordPress.orgのセキュリティチームが重大な脆弱性への対応として判断した特別な場合にだけ、自動で配信されます。開発が止まったものは修正版が出ないまま残り、セキュリティ上の問題などで公式ディレクトリから閉鎖されることもあります。

サーバーのPHPも、確認の対象です。WordPress公式の動作環境のページはPHP 8.3以上を推奨し、サポートが終わった古い版はサイトを脆弱性にさらすおそれがあると注意しています。

管理画面で確認する: サイトヘルス、更新画面、プラグインの詳細

管理画面では、『ツール』→『サイトヘルス』で自動更新の不調と更新待ちを、『ダッシュボード』→『更新』で更新の有無と互換性を確かめます。プラグインごとの最終更新日と対応する版を見る場所は、公式ディレクトリのページか、プラグイン一覧の『詳細を表示』です。

サイトヘルスで『致命的な問題』を確認する

サイトヘルスの『ステータス』タブは、結果を『致命的な問題』『おすすめの改善』『テスト通過』に分けて表示します。脆弱性の点検で見るのは、『バックグラウンド更新が想定通りに動作していません』『更新可能なプラグインがあります』『停止中のプラグインを削除してください』の3つです。1つ目が出ていれば、セキュリティ修正の自動更新が届いていない可能性があります。

『情報』タブには、本体の版のほか、有効と停止中それぞれのプラグインとテーマの版、自動更新の設定が並びます。『サイト情報をクリップボードにコピー』で全項目を文字で取り出せるので、点検記録に貼っておくと次回の比較に便利です。

更新画面で、更新の有無と互換性を確認する

『ダッシュボード』→『更新』には、本体、プラグイン、テーマ、翻訳の更新がまとめて表示されます。更新が出ているプラグインの行に出るのは、『WordPress 7.1.3 との互換性: はい (作成者による評価)』か『未確認』の表示です。この評価は作成者の自己申告で、動作の保証ではありません。

『この更新は現在使用中の PHP のバージョンでは動作しません』と出た更新は、PHPを上げるまで適用できません。修正版が出ていても入らないため、PHPの更新を先に計画します。

プラグインの最終更新日と、対応する最新バージョンを見る

公式ディレクトリのプラグインページには、『最終更新日』『有効インストール数』『WordPress バージョン』『検証済み最新バージョン』が並びます。管理画面の『詳細を表示』でも、同じ情報が『最終更新:』『対応する最新バージョン:』として出ます。検証済みの版が現在の本体(7.1.3)から大きく遅れているものは、保守が続いているかを確かめる対象です。

公式ディレクトリは、最新3回のメジャーリリースで検証されていないプラグインに黄色の警告を、閉鎖されたプラグインに赤色の警告を表示します。赤色の警告は『このプラグインは(日付)にクローズし、もうダウンロードできません』という形です。閉鎖から60日後には、セキュリティ上の問題(Security Issue)などの理由も示されます。

使っていないプラグインとテーマを洗い出す

『プラグイン』→『インストール済みプラグイン』の『停止中』で、使っていないプラグインを絞り込みます。サイトヘルスは『停止中のプラグインは攻撃者の標的になります』と表示し、使う予定が無ければ削除を勧めています。停止はプラグインを動かさないだけで、ファイルはサーバーに残るからです。

テーマも、停止中のものを削除します。ただしサイトヘルスは、有効なテーマ、その親テーマ、デフォルトテーマ1つは残すよう案内しています。使っているテーマに問題が起きたとき、WordPressが代わりに使うのがデフォルトテーマです。

• サイトヘルスに『バックグラウンド更新が想定通りに動作していません』が出ていない
• 『ダッシュボード』→『更新』に、適用していない更新が残っていない
• 停止中のプラグインが無く、停止中のテーマは親テーマとデフォルトテーマだけ
• 最新3回のメジャーリリースで検証されていないプラグインが無い
• 公式ディレクトリで閉鎖されたプラグインが無い
• 管理者権限のユーザーが、現在の担当者だけになっている

WP-CLIで、版と配布状況を一覧にする

サーバーにSSHで入れるなら、WP-CLIで本体、プラグイン、テーマの版と更新の有無に加え、公式ディレクトリでの閉鎖と最終更新日まで一覧にできます。出力をそのまま点検記録に残せるのも利点です。

# 本体の版と、本体の更新の有無
wp core version
wp core check-update

# 更新が出ているプラグインとテーマ
wp plugin list --update=available
wp theme list --update=available

# 停止中のプラグインとテーマ(削除の候補)
wp plugin list --status=inactive
wp theme list --status=inactive

『wp core check-update』は、本体が最新なら『Success: WordPress is at the latest version.』と表示します。更新があれば、版と種類(major、minor)を表で返します。次のコマンドは、公式ディレクトリでの状態と最終更新日をプラグインごとに並べるものです。

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

# 例(表示を簡略化。名前と日付は説明用)
| name         | status   | version | update    | wporg_status | wporg_last_updated |
| example-form | active   | 3.2.1   | available | active       | 2026-09-30         |
| old-slider   | inactive | 1.4.0   | none      | closed       | 2023-05-11         |
| custom-tool  | active   | 2.0.5   | none      |              |                    |

公開の脆弱性情報と照合する: JVN iPedia、NVD、CVE、公式発表

版の一覧ができたら、本体はWordPress公式のセキュリティ発表で、プラグインとテーマはJVN iPediaやNVDで製品名を検索して照合します。読むべき項目は、影響を受ける版の範囲、修正版の番号、悪用が確認されているかの3つです。

情報源の使い分け

JVN iPediaは、国内の開発者が公開した情報、JVNで公表した情報、米国NISTのNVDの情報を集約し、日本語に翻訳したデータベースです。IPAの登録状況の報告によると、2007年4月25日に公開が始まり、2026年第1四半期までの登録は累計277,036件にのぼります。NVDは米国政府の脆弱性管理データのリポジトリで、CVEは、公開された脆弱性を特定、定義して目録にまとめるCVEプログラムの識別番号です。

影響を受ける版と修正版を照らし合わせる

照合の要は、自分の版が影響を受ける版の範囲に入るかどうかです。範囲は『以上』と『未満』で書かれることが多く、『未満』の側に書かれた版が修正版にあたります。

たとえばIPAの注意喚起は、CVE-2026-63030の影響を受ける版を6.9.0から6.9.4と7.0.0から7.0.1とし、修正版を6.9.5と7.0.2としています。NVDのデータでも、6.9以上6.9.5未満と、7.0以上7.0.2未満が影響範囲です。6.9.4のサイトは該当し、6.9.5に上げれば該当しなくなります。

1. 版を書き出す本体、プラグイン、テーマの名前と版を一覧にします。前の節のWP-CLIの出力をそのまま使えます。
2. 製品名で検索するJVN iPediaとNVDでプラグイン名やテーマ名を検索し、本体はWordPress公式のセキュリティ発表を読みます。
3. 範囲と照らす影響を受ける版の範囲に自分の版が入るかを確かめ、入っていれば修正版の番号を控えます。
4. 優先順位を決めるログインせずに狙えるものと、悪用が確認されているものから先に、更新の予定を入れます。

深刻度は点数だけでなく、攻撃の条件で読む

深刻度の表記は、評価する側によって変わります。9月22日の7.1.2で直った脆弱性(CVE-2026-87902)は、WordPress公式の発表では『critical』です。一方、CVSS v3の基本値は8.1で、JVN iPediaの表示は『重要』でした。

点数より先に読むのは、攻撃の条件です。JVN iPediaの『攻撃に必要な特権レベル: 不要』は、ログインせずに狙えることを示します。『参考情報』に米国CISAの『Known Exploited Vulnerabilities Catalog』が載っていれば、実際の悪用が確認された脆弱性です。

CVE-2026-87902は公表から3日後の9月25日に、CVE-2026-63030は公表から4日後の7月21日に、このカタログへ追加されました。2件とも、公表から悪用の確認まで数日しかありませんでした。

外から見える情報を確認する: 版の露出と公開ファイル

外からの確認では、自分のサイトに対して、第三者が取得できる版の情報と公開ファイルを調べます。版を隠しても脆弱性は直りませんが、何が見えているかを知ると、点検の漏れに気づけます。

標準の設定で版が出る主な場所は、ページの<head>、フィード、CSSやJavaScriptのURLです。<head>には『<meta name="generator" content="WordPress 7.1.3">』が出て、フィードのgeneratorにも同じ版が入ります。版の指定が無いCSSやJavaScriptのURLに付く『?ver=』も、本体の版と同じ値です。

ルートにあるreadme.htmlは、現在の版では版番号そのものを載せていません。ただし、WordPressで作られたサイトであることと動作要件が分かるため、公開しておく理由はありません。プラグインのCSSやJavaScriptに付く番号や同梱の説明ファイルからも、プラグインの版が推定されることがあります。

# 自分が管理するサイトにだけ実行します
# トップページとフィードに、版が出ていないか
curl -s https://example.com/ | grep -io '<meta name="generator"[^>]*>'
curl -s https://example.com/feed/ | grep -io '<generator>[^<]*</generator>'

# readme.html が公開されているか(200なら公開、404なら非公開)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/readme.html

# 例(出力)
<meta name="generator" content="WordPress 7.1.3">
<generator>https://wordpress.org/?v=7.1.3</generator>
200

当社の無料のWebサイトのセキュリティチェックは、URLを入れるだけで、本体、プラグイン、テーマの版と既知の脆弱性、配布終了の有無を確かめます。readme.htmlやxmlrpc.phpの公開、REST APIでユーザー名の一覧が取れるかも、調べる対象です。診断は公開ページの取得やDNSの照会に限られ、攻撃の通信は送らないため、ログイン後の画面や管理画面の内側は対象外です。

wp-config.phpのバックアップや.git、.envなど、公開してはいけないファイルの確認方法は.gitや.envが公開されていないか確認する方法で扱っています。フォルダの中身が一覧で見えるディレクトリリスティングも、アップロード用のフォルダ(wp-content/uploads)で、サーバーの設定によって起きることがあります。

更新の前の準備と、更新の順序

更新の基本は、バックアップを取って戻せることを確かめ、検証環境で試してから、本番で1つずつ行うことです。公式のUpgrading WordPressも、手動更新の最初の3段階を、データベースのバックアップ、全ファイルのバックアップ、バックアップの検証としています。

バックアップは戻せることまで確かめる

バックアップに要るのは、データベースとファイル(少なくともwp-contentとwp-config.php)の両方です。取っただけで終えず、検証環境へ実際に戻し、ページが表示されるかまで確かめます。サーバー会社のバックアップを使う場合は、保存期間と戻し方を事前に確認しておきます。

# 例: WordPressの設置フォルダで実行し、公開フォルダの外(~/backups)へ書き出す
mkdir -p ~/backups
wp db export ~/backups/db-20261012.sql
tar -czf ~/backups/files-20261012.tar.gz wp-content wp-config.php

バックアップのファイルを公開フォルダの中に置くのは危険です。外から取得されるおそれがあり、データベースには会員情報や問い合わせの内容も含まれます。保存先と消す時期まで決めておきます。

検証環境で先に試す

検証環境(ステージング)は、本番と同じ版の本体、プラグイン、テーマ、PHPを揃えた複製です。ここで更新し、表示、問い合わせフォーム、会員機能、決済を操作してから本番に移ります。検証環境にはベーシック認証などをかけ、検索結果に載らないようにします。

使い終えた検証環境や旧サイトも、点検の対象です。IPAは、不要になったページを残すと管理が及ばず、脆弱性が見つかったときに影響を受けるおそれがあるとして、不要になった時点で非公開にするよう勧めています。

本体、プラグイン、テーマの順に1つずつ更新する

公式の手動更新の手順は、本体のファイルを入れ替えたあとに、更新されたプラグインとテーマを入れる流れです。本体の大型更新の前には、更新画面の互換性の表示で、各プラグインが新しい版に対応しているかを確かめます。脆弱性が公表されているものがあれば、その更新が最優先です。

まとめて更新すると、不具合が出たときに原因を特定できません。1つ更新するごとに表示を確かめれば、原因をその場で切り分けられます。

1. 更新の内容を読む変更履歴とセキュリティ発表で、修正の内容と対象の版を確かめます。
2. バックアップを取るデータベースとファイルを公開フォルダの外へ保存し、戻せることを確かめます。
3. 検証環境で試す同じ更新を検証環境で行い、主要な画面と機能を操作します。
4. 本番を1つずつ更新するアクセスの少ない時間に、本体、プラグイン、テーマの順で進めます。
5. 表示と機能を確かめるトップページ、問い合わせフォーム、会員機能、決済を実際に操作します。
6. 記録を残す日時、対象、更新前後の版、理由(CVE番号など)、確認の結果を書き残します。

修正版が無い、更新できないときの判断

修正版が無いときは、そのプラグインを使い続ける必要があるかと、開発が続いているかの2点で判断します。使わないものは削除し、使うものは『待つ』か『置き換える』かを選びます。

攻撃の兆候を確認する: 不審な管理者、改ざん、見覚えのないファイル

兆候は、ユーザー、ファイル、外からの見え方の3か所で確かめます。WordPress公式のFAQ My site was hackedは、侵害の明確な兆候を挙げています。検索エンジンの警告、サーバー会社によるサイトの停止、許可していないユーザーの作成、目に見える改ざんなどです。

• 見覚えのない管理者アカウントが無い(登録日も見る)
• 本体のファイルが、公式の配布物と一致する
• wp-adminやwp-includesに、本来無いファイルが無い
• .htaccessと、テーマのindex.php、header.php、footer.php、functions.phpに覚えのない変更が無い
• 検索結果やブラウザに、危険なサイトの警告が出ていない
• サーバー会社から、迷惑メールの送信やサイトの停止の連絡が来ていない

# 管理者権限のユーザーと登録日を一覧にする
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 本体のファイルを、公式のチェックサムと照合する
wp core verify-checksums

# 公式ディレクトリのプラグインを、配布物と照合する
wp plugin verify-checksums --all

本体の照合で『File doesn't verify against checksum』と出たファイルは、公式の配布物から書き換えられています。『File should not exist』は、本来無いファイルがあるという意味です。wp-content(テーマ、プラグイン、アップロード)は本体の照合の対象外で、プラグインの照合も公式ディレクトリにあるものに限られます。

侵害が疑われるときの初動

侵害が疑われたら、状況を記録して現状の複製を取り、サーバー会社や保守会社に連絡してから、すべての入口のパスワードを変えます。削除や上書きを急ぐと原因の手がかりが消えるため、順番が大切です。

1. 状況を記録する侵害を疑った理由、気づいた日時とタイムゾーン、直近に入れたプラグインや変更を書き出します。
2. 現状の複製を取る感染していても、掃除の前に今の状態を丸ごと保存します。原因の調査と、作業に失敗したときの比較に使います。
3. 関係先に連絡するサーバー会社と保守会社に連絡します。共用サーバーでは、被害がほかのサイトに及んでいることもあります。
4. 入口をすべて閉じる全ユーザーのパスワードと、FTPやSFTP、サーバーの管理画面、データベースのパスワードを変えます。wp-config.phpの認証用ユニークキーを入れ替えると、ログイン中の全員が締め出されます。
5. 本体を同じ版で入れ直すwp-adminとwp-includesを、同じ版の公式の配布物で置き換えます。テーマとプラグインも、公式ディレクトリや提供元から取り直します。
6. 侵入口を塞ぐ原因と考えられるプラグインやテーマを更新するか、削除します。
7. もう一度パスワードを変えるきれいになったことを確かめてから、すべてのパスワードを再度変えます。
8. 影響を確かめて知らせるログで被害の範囲を確かめ、利用者や取引先に影響があれば連絡します。

復旧後は、wp-config.phpに『define( 'DISALLOW_FILE_EDIT', true );』を書きます。管理画面からテーマとプラグインのファイルを編集できなくなり、管理者アカウントを乗っ取られても、コードを書き換えられる被害を抑えられます。

自社で切り分けるのが難しい場合は、IPAの情報セキュリティ安心相談窓口や、JPCERT/CCのインシデント対応依頼が公的な相談先です。診断や復旧の進め方は、当社のお問い合わせ窓口でも相談を受け付けています。

自動更新の使い分け

本体のセキュリティ修正(マイナー版)の自動更新は止めずに使い、プラグインとテーマは影響の大きさで自動と手動を分けます。自動に任せた部分も、版が上がったかの点検は欠かせません。

WordPress 5.6以降の新規インストールでは、Gitなどで管理している場合を除き、本体はマイナー版と大型更新の両方が既定で自動です。5.6より前に入れたサイトは、設定を変えていなければマイナー版と翻訳だけが自動になっています。プラグインとテーマの自動更新は5.5で加わった機能で、一覧の『自動更新を有効化』から個別に切り替える形です。

// wp-config.php の例1: 本体の自動更新をマイナー版だけにする
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// 例2: 大型更新も含めて自動にする(例1とどちらか一方だけを書く)
// define( 'WP_AUTO_UPDATE_CORE', true );

自動更新は既定で1日2回実行され、結果は管理者にメールで届きます。ただしIPAは、環境や設定によって自動更新が有効でなかったり、失敗したりする可能性を挙げ、管理画面で版が上がったかを確かめるよう求めています。

点検の頻度、担当、更新の記録を決める

点検を続けるこつは、頻度ごとに作業を分け、担当者を決めることです。IPAも、自組織で使うソフトウェアを把握し、脆弱性がある版でないかを定期的に確認するよう求めています。

担当は、主担当と代理の2人を決めます。サーバー会社や制作会社に保守を任せている場合は、IPAが勧めるとおり事業者の作業範囲を確かめ、足りない部分を自社で受け持ちます。たとえば本体の自動更新はサーバー会社、プラグインの更新は制作会社、点検記録の確認は自社、という分け方です。

更新の記録は、作業ごとに次の項目を残す形で十分です。記録があれば、不具合や侵害が起きたときに、いつ何を変えたかを後からたどれます。

• 日時と作業者
• 対象(本体、プラグイン名、テーマ名)
• 更新前と更新後の版
• 更新の理由(CVE番号、注意喚起のURL)
• 確かめた画面と機能、その結果
• 問題が出たときの対応(戻した、保留した、など)

月1回の外からの確認に使える道具の1つが、当社の無料のセキュリティチェックです。WordPress以外も含めたサイト全体の点検項目は、Webサイトのセキュリティチェック項目30選にまとめています。

WordPressの脆弱性確認でよくある質問