WordPressプラグインのセキュリティ｜外部に鍵を渡していないか確認する手順

WordPressのプラグインは、入れた瞬間からサイトの中身を触れる立場になります。2026年8月、あるSEOプラグインが、許可を求める画面を出す前にサイトへ接続するための認証情報を発行していたと指摘され、その機能は8月31日の更新でいったん取り下げられました。ただし、機能が止まっても、すでに作られた認証情報は自動では消えません。この記事は特定の製品の危険性を判定するものではなく、プラグインが外部サービスとつながるときに何が作られ、どんな権限を持つのかを、利用者が自分で確認する方法をまとめたものです。

なお「WordPress プラグイン セキュリティ」で探している方には、「セキュリティ対策用のプラグインを選びたい」場合と、「いま入れているプラグイン自体が安全か知りたい」場合の2通りがあります。この記事は後者を扱います。

この記事でわかること

• いま開く場所： 「ユーザー → プロフィール → アプリケーションパスワード」です。管理者が複数いるサイトは全員ぶんを見ます。
• 判断の基準： WordPress本体には、個々のアプリケーションパスワードの権限を絞る仕組みがありません。「読み取り専用」はアプリ側の作りの話で、WordPressが保証している制限ではありません。
• 続けられる形： 更新を止めることではなく、誰がいつ許可したかを残せる状態にすることです。

プラグインが外部接続用の認証情報を作るとき｜2026年8月の事例

SEOプラグインが承認画面の前に接続用の認証情報を作ったと指摘され、8月31日にその機能が取り下げられました。

事例として扱うのはRank MathというSEOプラグインです。ここで並べるのは、確定している事実・指摘された内容・提供元の説明を分けたうえで、時系列にしたものです（2026年9月1日時点）。

提供元は公式ブログで、資格情報は暗号化しており自社側に保存・永続化していないこと、エージェントは読み取り専用でログイン中のユーザーの権限を超えないこと、そして何にアクセスするのかの説明が足りていなかったことは自分たちの誤りだと、責任を認める形で説明しています。機能は廃止ではなく、許可の取り方を作り直したうえで戻す予定だとしています。

一方で指摘した側は、許可を求める画面より前に発行が始まる点を問題視しています。指摘者は別のSEOプラグイン（The SEO Framework）の開発者で、競合であることを自分で明かしています。

ここで整理しておきたいのは、この件はCVEのような「脆弱性」として登録されたものではなく、侵害や改ざんが起きたという報告でもないということです。争点は、認証情報を作ること自体ではなく、それを利用者にどう説明し、どう同意を取るかにあります。したがって読者にとっての結論も「今すぐ削除」ではなく、「自分のサイトに何が作られているかを一度見る」になります。

海外発の指摘が日本語で回ってくるまでには時間差がある

2026年9月1日時点で、この件を日本語で扱った投稿はほとんど見当たりません。

海外では開発者コミュニティを中心に短期間で広がりましたが、日本語のSNS上で本件を直接論じていたのは、確認できた範囲でごく少数の実務者だけでした。つまり「日本語で情報が回ってこなかったから自分のサイトは無関係」とは言えません。プラグインは言語を問わず同じ動作をします。この時間差そのものが、運用側が自分で点検する手順を持っておくべき理由です。

アプリケーションパスワードとは何か

外部ツールがAPI経由でサイトへ接続するための鍵で、そのユーザーに許された操作ができます。

アプリケーションパスワードは、WordPressの標準機能です。スマートフォンアプリや外部ツールがサイトへ接続するときに、ログインID・パスワードそのものを渡さずに済ませるための仕組みで、悪いものではありません。管理画面へ人がログインするためのものではなく、REST APIを通じた接続に使われます。問題になるのは「誰に渡したか」と「どうやって渡したか」です。

WordPressの開発者向けドキュメントでは、外部ツールが接続を求めてきたときの流れとして authorize-application.php という承認画面が用意されています。この画面には接続を求めているアプリの名前が表示され、利用者が「承認」か「拒否」を選びます。

ただし、これが唯一の発行経路というわけではありません。プロフィール画面から自分で作ることもできますし、プログラムから発行することも想定されています。つまり今回の争点は「発行されたこと」そのものではなく、利用者への説明と同意の取り方にあります。

アプリケーションパスワード自体には「読み取り専用」の設定が無い

WordPress本体の機能として、個々のアプリケーションパスワードの権限を絞る仕組みは用意されていません。

これはWordPressの公式ドキュメントに書かれている仕様です。アプリケーションパスワードは現時点で、認証したユーザーの権限をそのまま引き継ぎます。範囲を限定する仕組みについては「将来的に含める見込み」と記載されており、いまは存在しません。

一方で、提供元は「エージェントは読み取り専用だった」と説明しています。この2つは矛盾しません。WordPress側に読み取り専用の設定が無いことと、接続するアプリの側が読むだけの作りになっていることは、別の話だからです。実際に読むだけだったかどうかは、外から検証できていません。

利用者にとって重要なのは、どちらが正しいかではなく、渡した鍵に「読むだけ」という制限を後からかける手段がサイト側には無いという点です。制限をかけられない以上、渡すかどうかを渡す前に決めるしかありません。

プラグインとAPI接続では、リスクの性質が違う

プラグインはサイトの内部で動き、API接続はサイトの外から決められた入口を通ります。

WordPressのプラグインは、テーマや本体と同じ場所で動きます。インストールした時点でファイルもデータベースも触れる位置にいます。「プラグインを入れる」という行為は、機能を足すことであると同時に、そのプログラムの作り手を信頼すると決めることでもあります。

これに対してアプリケーションパスワードによる接続は、REST APIという決められた入口を通り、各機能ごとの権限チェックを経て動きます。管理画面へ人がログインするのとは違います。「管理者と同じことが何でも遠隔でできる」わけではありません。

そのうえで今回の論点は、内部で動くプログラムが外部のサーバーへ接続用の鍵を渡したという点にあります。プラグインが中で動くことと、その鍵が社外へ出ることは、リスクの質が別です。前者は作り手を信頼するかどうかの話ですが、後者は「その鍵の保管場所が攻撃されたらどうなるか」という、信頼とは別の問題を持ち込みます。

いま自分のサイトを点検する手順

管理画面の「ユーザー → プロフィール」を開き、アプリケーションパスワードの一覧に心当たりのない行がないかを確認します。

作業は数分で終わります。プラグインを消す必要はありません。順番に見ていきます。

手順5がいちばん飛ばされます。 アプリケーションパスワードは利用者単位で管理されているため、経営者・担当者・制作会社・退職済みのアカウントがそれぞれ持っている可能性があります。自分のプロフィールが空でも、別の管理者の画面に残っていれば鍵は生きています。

なお、アプリケーションパスワードは管理者だけの機能ではありません。HTTPSで動いていれば、編集者や投稿者の権限でも発行できます。今回の件を確認する目的なら管理者から見るのが効率的ですが、「管理者の画面が空だったから全部きれい」とまでは言えません。

当社サイト（aidaim.co.jp）で同じ手順を実行したところ、登録されていたアプリケーションパスワードは1件だけで、自社の運用ツール向けに発行したものでした。最終使用日も直近の日付で、発行元・用途とも説明がつく状態です。今回話題になったプラグインは導入していません。「見に行って、説明がつく件数だけだった」ことを確認できたという状態が、点検のゴールです。

取り消していいものと、取り消すと止まるもの

名前と最終使用日から用途が説明できないものは取り消して構いません。取り消してもサイトの表示は壊れません。

判断に迷ったときは、次の順で考えます。まず名前を見て、どのツール向けかが分かるか。分かるなら残します。分からない場合、最終使用日が空欄なら誰も使っていないので取り消して問題ありません。最終使用日が入っていて用途が不明なものが、いちばん優先して調べる対象です。

取り消しは元に戻せませんが、壊れるとしても「そのツールから接続できなくなる」だけで、サイトの表示や記事が消えることはありません。接続できなくなったツールは、正規の承認画面から発行し直せば復旧します。心配して残すより、取り消して様子を見るほうが安全側です。

プラグインが外部に何を送ってよいかの基準を決める

外部へ鍵や情報を渡す機能は、誰がいつ許可したかを記録に残せる形でしか入れない、という線で決めます。

「怪しいプラグインを入れない」という基準は、実務では機能しません。今回の件は、2026年9月時点でWordPress.orgの表示が400万件以上という定番プラグインで起きています。怪しいかどうかではなく、何を外に出す機能なのかで判断する必要があります。

3段目が今回の件に当たります。2段目と3段目は「送るデータが多いか少ないか」の差ではなく、外へ出すのがデータなのか、サイトを操作できる鍵なのかという別の軸です。判断の軸は「信用できる会社か」ではなく、許可した記録が残るかです。記録が残っていれば、あとから見直せます。残らない形で渡した鍵は、渡したこと自体を誰も知らないまま残り続けます。

入れる前に見る5項目

導入の判断は、機能の魅力ではなく、更新され続けるかと、外と何をつなぐかで決めます。

事件が起きてから探すのでは間に合いません。次の5つを、インストールボタンを押す前に見てください。

• 最終更新日： 1年以上更新されていないものは、WordPress本体の変更に追随できなくなっている可能性があります。
• 対応バージョン： いま使っているWordPressのバージョンで動作確認されているか。
• 開発元： 個人か企業か、他にどんな製品を出しているか。買収で開発元が変わることもあります。
• 外部サービスとの接続： アカウント登録やAPI連携を求めるものは、何が外へ出るのかを確認します。
• 必要な権限： 管理者権限や認証情報の発行を求めるものは、上の表の3段目として扱います。

すでに入っているプラグインについても、同じ5項目で見直せます。特に開発元が変わったプラグインは、入れたときの判断がそのまま通用しません。

更新を承認制にするか、自動に任せるか

すべてを承認制にする必要はなく、外部へ権限を渡す可能性がある種類だけを人が通す形にします。

当社の事例では、案件によって扱いを分けています。表示や整形だけのプラグイン、本体のマイナー更新のように、放置するほうが危険なものは自動更新のままにします。一方で、外部サービスと連携する種類や、機能追加を伴う大きな更新は、更新内容を見てから反映する運用にします。全部を止めると、今度は脆弱性の修正が当たらないまま放置されるので、そちらのほうが事故になりやすいためです。

今回の件も、実際には「セキュリティ修正を多数含む更新」と「新機能の追加」が同じバージョンに同居していました。自動更新を全部切っていた場合、セキュリティ修正のほうも当たっていなかったことになります。切るか切らないかの二択にしないことが、実務的な答えです。

プラグインは何個までなら安全か

個数に安全な上限はなく、危ないのは「誰も中身を見ていないプラグインが何個あるか」です。

「プラグインは入れすぎないほうがいい」とよく言われますが、10個だから安全で20個だから危険、という線はありません。問題になるのは、入れた理由を誰も説明できないプラグインが残っている状態です。前の制作会社が入れたもの、一度試して使わなくなったもの、機能が本体に取り込まれて不要になったものが、更新だけされ続けている。この状態のほうが個数より危険です。

点検のときは、有効化されているプラグインを一覧で出し、それぞれ「何のために入っているか」を1行で言えるかを確かめてください。言えないものが削除の候補です。

次に同じことが起きたときに気づける状態にする

気づける状態は、点検の担当と頻度を決めて、記録に残すことでしか作れません。

今回のような件は、個別のプラグインを消しても繰り返されます。別のプラグインが同じ設計を採るかもしれないからです。手を入れるべきはプラグインではなく、気づける状態になっているかどうかです。

頻度は、対象によって分けます。脆弱性の情報やセキュリティ更新の通知は、届いた時点で対応するものです。ここでいう月に一度は、一覧を開いて、用途が説明できない鍵やユーザーが増えていないかを確かめる作業のことで、当社が保守で回すときの目安です。パスワードを毎月作り直すという意味ではありません。 説明がつく鍵はそのまま残します。当社が最低限として見るのは3つ。アプリケーションパスワードの一覧、管理者権限のユーザーが増えていないか、身に覚えのない投稿や固定ページがないか。この3つを、日付と担当者を書いた記録として残していきます。

記録に残す意味は、犯人探しではありません。次に何かが起きたときに「いつまでは正常だったか」が分かることです。これがないと、異常に気づいた時点で、いつから起きていたのかを調べる手段がなくなります。サイトの改修やリニューアルのタイミングも同じ考え方で進めます（ホームページ改修とは？リニューアルとの違い・費用・SEO注意点、Chatworkとサーバー乗っ取りの原因と確実なセキュリティ対策）。

自分で点検するか、任せるか

毎月の点検を続けられる担当者がいないなら、外に出したほうが結果的に安く済みます。

判断の材料は、費用よりも「続けられるか」です。点検そのものは難しくありませんが、続かないと意味がありません。3か月に一度気が向いたときに見る運用は、見ていないのと変わりません。

社内で回す場合は、担当者を1人決めて、月初に固定の作業として入れてください。「気づいたときにやる」にすると必ず止まります。

一方、次のどれかに当てはまる場合は、自力で判断せず外部に見てもらったほうが安全です。身に覚えのない投稿や管理者アカウントがすでに増えている／サイトが改ざんされている疑いがある／バックアップを取っていない、または戻せるか確かめたことがない／管理画面に入れる人が誰なのか分からない。この状態で操作を進めると、原因を消してしまって調べられなくなることがあります。

よくある質問

まとめ

WordPressのプラグインは、入れた時点でサイトの内側にいます。今回の件で確認しておきたいのは、次の4点です。

• 状況： 話題になった機能は2026年8月31日の更新でいったん取り下げられています。ただし、発行済みの認証情報は自動では消えません。
• 仕組み： WordPress本体には、個々のアプリケーションパスワードの権限を絞る機能がありません。「読み取り専用」はアプリ側の作りの話で、サイト側でかけられる制限ではありません。
• 点検： 「ユーザー → プロフィール → アプリケーションパスワード」を、管理者権限を持つ全員ぶん見ます。数分で終わります。
• 体制： 手を入れるべきはプラグインではなく、月に一度その一覧を見る担当と、見た記録がある状態です。

騒ぎが収まったあとに残るのは、鍵の一覧と、それを誰も見ていないという状態です。見る場所は1つしかありません。今日のうちに開いてみてください。

参考情報

• Make WordPress Core「Application Passwords: Integration Guide」
• WordPress REST API Handbook「Authentication」
• WordPress.org「Rank Math SEO 更新履歴（1.0.277／1.0.277.1／1.0.277.2）」
• Rank Math「Why the Rank Math Support Agent Is Temporarily Paused」
• Search Engine Journal「Rank Math WordPress Plugin Accused Of Secretly Taking Admin Access」
• アイダイム「ホームページ改修とは？リニューアルとの違い・費用・SEO注意点を解説【2026年版】」
• アイダイム「Chatworkとサーバー乗っ取りの原因と確実なセキュリティ対策」