400万サイトで動くプラグインの、ヘルプ画面
Rank MathはWordPress向けのSEOプラグインで、400万を超えるサイトで稼働している。日本の制作会社や受託運用の現場でも、Yoast SEOと並んで選択肢に上がる名前だ。
8月26日前後にリリースされたバージョン1.0.277で、同プラグインは約12件のセキュリティ問題を修正した。同じアップデートで、「Support Agent」と呼ばれるAI機能も追加されている。問題になっているのは後者である。
指摘されている挙動
別のSEOプラグイン「The SEO Framework」の開発者であるSybre Waaijer氏が指摘した内容は、具体的だ。
無料のRank Mathアカウントに接続した状態のサイト管理者がプラグインの「Help & Support」セクションを開くと、その瞬間にWordPressのApplication Passwordが生成される。Application Passwordは操作しているユーザーに紐づくため、開いたのが管理者権限のユーザーであれば、生成される認証情報も管理者権限を継承する。そしてそのパスワードは、Rank Mathの親会社であるgroup.one（WP Rocketの運営元でもある）のサーバーへ送信される。以後、同社のAIエージェントはサイト上でユーザーに代わって操作できる状態になる。
該当ファイルとして名指しされているのは vendor/groupone/wap-client/includes/class-app-password-manager.php である。
Waaijer氏はこう書いた——プラグインは事前に尋ねない。「Terms & Conditions」のボックスはあるが、それがパスワードの生成と送信を止めることはない。転送はボックスが表示される前に始まっている、と。
同氏は、過去に類似のケースを「バックドア」と分類したことに触れつつ、今回については判断を読者に委ねると書いている。これは慎重な留保だ。理由は次節にある。
Application Password自体は、正規の仕組みである
WordPressのApplication Passwordは、WordPressコアの機能だ。アプリケーション単位の失効可能な認証情報を発行するための仕組みで、プラグイン開発者向けのガイドラインも用意されている。使うこと自体は何ら不正ではない。
争点は使い方にある。
WordPress公式のドキュメントが定めるフローには、認可画面がある。プラグインが自らを名乗り、ユーザーに接続内容が提示され、承認か拒否を選ぶ機会が与えられる。仕様上、Application Passwordがプラグインに渡されるのは、ユーザーが承認したあとである。
さらにWordPress.orgのプラグインガイドラインは、外部サーバーとの通信について明示的な同意を要求している。第7項——プラグインは同意なくユーザーを追跡してはならない。ユーザーのプライバシー保護の観点から、プラグインは明示的かつ承認された同意なしに外部サーバーへ接続してはならない。同意はオプトイン方式、つまりサービスへの登録か、プラグイン設定内のチェックボックスで取ることが想定されている。
そしてApplication Passwordは、本来「レビューでき、失効できる」ものとして設計されている。個別に失効できるからこそ、ユーザーの本体パスワードを変えずに1つの連携だけを切れる。
指摘によれば、Rank Mathが生成するこの認証情報は、プロフィール画面に「WAP – Rank Math Support Agent」として現れるが、Help & Supportタブを閉じても失効せず、有効期限もなく、Support Agent機能自体をオフにする設定もないという。設計思想の要である「取り消せること」が、実装で薄まっている格好だ。
対応状況と、確認できていないこと
WordPress.orgにはバージョン1.0.277.1が8月27日付で掲載されており、リリースノートには、Help & SupportのAIアシスタントとApplication Passwords（Application Passwordsが無効化されている場合）に関する問題を修正した旨が記載されている。指摘を受けて何らかの修正が入ったことは確認できる。
一方で、Rank Math側の公式な説明や反論は、本稿執筆時点で確認できていない。同社のフォーラムに立っていた大きなスレッドが削除されたという利用者の指摘もあるが、当誌としてその経緯を検証できていない。現時点でこれは「告発」の段階の話であり、確定した事実として扱うべきではない。
なお、Search Engine Journalは同誌の推奨プラグインリストにRank Mathを含めていない理由として脆弱性の履歴を挙げている。同誌の集計では2024年に7件、2025年に4件、2026年はここまでで3件の脆弱性が発見されており、直近には未認証のStored XSSも含まれる。
これはRank Mathだけの話ではない
ここからが本題だと筆者は考えている。
AIエージェントを製品に載せると、必ず権限が要る。「サイトを見て直してくれるサポート」を実現するには、そのエージェントがサイトに対して書き込める必要がある。読み取りだけでは、できることが極端に減る。だからベンダーは権限を欲しがるし、機能要件としてはそれで正しい。
問題は、ユーザーが認識する同意と、システムが取得する権限の粒度がずれることにある。ユーザーの認識は「ヘルプを開いた」。システムが取得したのは「管理者権限の、期限のない認証情報」。この距離が、今回の反発の中身のすべてだ。
同じ距離は、今後あらゆるマーケティングツールに現れる。CMS、フォーム、CDP、広告運用ツール、解析タグ——いずれもAIエージェント機能を載せようとしており、載せた瞬間に同じ設計問題に直面する。当誌が先日報じたShopifyのWebMCP一括展開も、方向は違うが「サイト側のインターフェースをエージェントに開く」という同じ地層の話である。
違いは、WebMCPが読み書きの範囲をプラットフォーム側で定義しているのに対し、今回の件は既存の管理者権限をそのまま持っていった点にある。前者は設計であり、後者は流用だ。この差は、事故が起きたときの被害範囲の差になって現れる。
今日やること（WordPressを運用しているなら）
- Application Passwordの棚卸し。 WP管理画面 → ユーザー → プロフィール → アプリケーションパスワード。「WAP」で始まるものがあれば、意図した連携かを確認する。Rank Mathを使っていて「Help & Support」を開いた記憶があるなら、失効させる。
- 失効は連携の停止を意味すると理解しておく。 サポート機能が使えなくなる可能性はある。それを承知の上で判断する。
- 保守契約の責任分界を確認する。 受託でサイトを運用している場合、プラグインによる権限取得は「クライアントのサイトへの第三者アクセス」である。契約上どちら側の責任になるのか、今のうちに整理しておく。
- プラグイン更新のリリースノートを読む習慣を作る。 今回、セキュリティ修正12件という良いニュースと、問題視された機能が同じリリースに入っていた。更新を止めるのは悪手だが、読まずに当てるのも危うい。
AIエージェントが便利になるほど、それが持つ鍵は太くなる。誰にどの鍵を渡したかを一覧できる状態を保つことが、これから数年のWeb運用の基礎体力になる。