前々回・前回の記事では、PHP 本体と「更新するのは誰か」を扱った。この記事は、更新の担い手が サイト管理者である層 の中でも、最も入れ替わりが多く、最も数が多いプラグインの話。個別のプラグイン名・CVE 番号・件数はあえて書かない。数字は調査会社ごとに集計の仕方が違い、日々変わるためだ。確かめる場所は記事の最後に挙げる。
プラグインは「他人が書いたコードを、自分のサイトの権限で動かす」仕組み
WordPress プラグインは、本体と同じ PHP プロセスで、本体と同じ権限で動く。つまり、プラグインに脆弱性があれば、その影響範囲は「そのプラグインの機能」にとどまらず、サイト全体 に及びうる。
補足: 脆弱性とは、作り手が意図しなかった動きを外部から引き出せてしまう不具合のこと。すべてが直ちに被害につながるわけではないが、条件がそろうと、第三者が管理者権限を得たり、ファイルを置いたりできてしまう。
この記事では、脆弱性の「性質」を3つの軸で整理し、そのうえで「持たない」「早く知る」「早く当てる」の順に手を打つ考え方を書く。
軸1: 認証が要るか、要らないか
脆弱性の深刻さを大きく分けるのが、悪用にログインが必要かどうか だ。
| 種類 | 悪用に必要なもの | 危険度の考え方 |
|---|---|---|
| 認証不要（unauthenticated） | 何も要らない。URL にアクセスできれば試せる | 非常に高い。世界中から機械的に試される |
| 低権限の認証が必要 | 購読者などのアカウント | 会員登録を開放しているサイトでは実質的に認証不要に近い |
| 管理者権限が必要 | すでに管理者であること | 低め。ただし別の脆弱性と連鎖する余地はある |
認証不要の脆弱性が重く扱われるのは、攻撃の前提条件が「そのプラグインが入っている」ことだけ だからだ。狙われる側がどれだけ注意深く運用していても、対象のバージョンが入っていれば試行の対象になる。
注意したいのは「会員登録を開放しているサイト」だ。購読者アカウントが誰でも作れるなら、「低権限の認証が必要」な脆弱性も、事実上は誰にでも試せる。
軸2: 公開から試行までの速さ
脆弱性が公表されると、修正版と同時に、何が直されたかが差分から読み取れるようになる。そのため、公表後に機械的な試行が急に増える傾向があると、セキュリティ各社が報告している。具体的な時間は調査によって異なるので、この記事では数値を挙げない。ただし Patchstack は自社ページで、新しい脆弱性が「数時間で」大規模に悪用されるようになっていると述べている（2026-10-30 時点で確認）。
ここから言えるのは、「月に1回まとめて更新する」という運用は、認証不要の重大な脆弱性に対しては、窓が空きすぎる可能性があるということだ。重大な更新だけは待たずに当てる、という例外を設けておくとよい。
軸3: その脆弱性は「いまも入っているコード」にあるか
ここが、この記事の中心になる。
プラグインを 無効化 しただけでは、ファイルはサーバーに残る。脆弱性の種類や作りによっては、WordPress が読み込んでいなくても、そのファイルに直接アクセスされて悪用される場合がある。「使っていないから大丈夫」ではなく、使っていないものは置かない のが基本になる。
加えて、無効化されたプラグインは、管理画面で更新通知が目立ちにくく、更新されないまま長く放置されがちだ。「入っているが誰も見ていないコード」は、攻撃面だけが残る。
棚卸しの手順
WP-CLI で、読み取りだけを行うコマンドから始める。
# 無効化されているプラグインの一覧
wp plugin list --status=inactive
# 更新が出ているプラグイン
wp plugin list --update=available
# 全体を、状態・バージョン・更新有無つきで見る
wp plugin list --fields=name,status,version,update
この出力を見て、次の順に判断する。
- 無効化されたまま残っているもの: 将来使う予定が具体的にないなら、削除する候補にする
- 更新が出ているもの: 更新履歴（changelog）に「security」「vulnerability」といった記述がないかを確認し、あれば優先する
- 最終更新が長期間止まっているもの: 作者が保守をやめている可能性がある。代替を探すか、機能自体が本当に必要かを見直す
- 似た機能が重複しているもの: 一つにまとめられるなら、プラグインの数を減らせる
削除する前に、必ずバックアップを取る。削除は元に戻せないので、順序は「バックアップ → 確認 → 削除」になる。
# 削除の例（バックアップ取得後に、1つずつ）
wp plugin delete <プラグインのslug>
テーマも同じで、使っていないテーマ（親テーマとして必要なものを除く）は、置いておく理由が薄い。
「早く知る」ための手段
プラグインの脆弱性は、次のような場所で公開される。
- Wordfence Intelligence（脆弱性データベースと週次レポート）
- Patchstack の脆弱性データベース
- 各プラグインの changelog（WordPress.org のプラグインページ）
自分が使っているプラグインの名前で定期的に検索するか、通知を受け取れる仕組みを使うとよい。ただし、これらの情報は 公表された後 のものだ。公表前に悪用されるケースもあるため、通知を待つだけでなく、そもそもの数を減らしておく意味がある。
責任の線も確認しておく
プラグインは、前回の記事で整理したとおり、事業者ではなく サイト管理者の担当 だ。自動更新を有効にしていなければ、通知が出ているだけで何も起きない。複数サイトを預かる場合は、サイトごとに「入っているプラグイン」「更新の状況」「自動更新の設定」を表にしておくと、通知を受けたときに該当サイトを短時間で洗い出せる。
まとめ
- プラグインの脆弱性は、本体と同じ権限で動くため、サイト全体に影響しうる
- 認証不要の脆弱性は、前提条件が「入っていること」だけなので、特に重く扱う
- 無効化してもファイルは残る。使わないものは 削除 する
wp plugin list --status=inactiveと--update=availableで、読み取りだけの棚卸しから始める- 削除前にはバックアップを取る。公表情報の確認先を決めておく
今日できる一手は、wp plugin list --status=inactive を1回実行して、出てきた一覧を見ること。それだけで、攻撃面を減らす最初の候補が見つかる。