CVE-2026-1490: CleanTalkのDNS逆引きスプーフィングによる認証バイパス
概要
- CVE: CVE-2026-1490
- プラグイン: Spam protection, Honeypot, Anti-Spam by CleanTalk
- 影響バージョン: 全バージョン <= 6.71
- 修正バージョン: 6.72 以降
- CVSS: 9.8 (Critical)
- 認証: 不要(未認証の攻撃者が実行可能)
- 種別: DNS逆引きスプーフィングによる認証バイパス+任意プラグインインストール
Spam protection, Honeypot, Anti-Spam by CleanTalkは、WordPressサイトのスパム対策として広く使われているプラグインで、約20万件のアクティブインストール数を持ちます。2026年2月、このプラグインに致命的な認証バイパスの脆弱性が発見されました。サーバー間通信の正当性をDNS PTRレコード(逆引き)のみで検証しているという根本的な設計ミスにより、攻撃者はDNSを操作するだけでCleanTalkの公式サーバーになりすますことができます。認証をバイパスした後、攻撃者はWordPressリポジトリから任意のプラグインをインストールでき、既知の脆弱性を持つプラグイン経由で間接的なRCEへ到達することも可能です。
何が起きたか
脆弱性の根本原因は、checkWithoutToken 関数における認証ロジックの設計上の欠陥です。
CleanTalkはクラウドベースのスパム判定を提供するため、プラグインはCleanTalkのサーバーからのリクエストを受け付ける内部APIエンドポイントを持ちます。このエンドポイントを保護するために、プラグインは2種類の認証方式を実装しています。
- 通常フロー: APIキーを含む暗号学的なトークンで認証する
checkWithoutTokenフロー: APIキーが設定されていないまたは無効な場合に使われるフォールバック。送信元IPのPTRレコード(逆引きDNS)を参照し、cleantalk.orgドメインに解決されるかどうかのみで信頼を判断する
問題は後者です。PTRレコードの解決は、CleanTalkのサーバーが本当にそのIPを所有していることを証明しません。PTRレコードは所有するIPアドレスのISPまたはホスティングプロバイダが設定するものであり、攻撃者が管理するIPに対してISPや自前のDNSサーバーで *.cleantalk.org のPTRレコードを設定することは技術的に可能です。
暗号学的な署名やHMACではなく、DNSという外部から操作可能な仕組みに依存したことが、認証を完全に無力化しました。
さらに深刻なのは、このフォールバックがAPIキーを未設定または無効なまま運用しているサイトで自動的に有効になる点です。プラグインを新規インストールし、APIキーを設定し忘れた状態は珍しくなく、20万インストールの一部は常にこの条件に該当していると考えられます。
攻撃の仕組み
攻撃フロー:
-
脆弱なサイトの特定: CleanTalk Anti-Spamを使用しているWordPressサイトを特定する。プラグインのバージョンはHTMLソースや
readme.txtのパスで確認できる場合がある。ただし脆弱性はAPIキーが無効または未設定のサイトにのみ有効であるため、後続のステップでAPIキーの有無を確認する。 -
攻撃者サーバーにPTRレコードを設定する: 攻撃者が制御するIPアドレス(VPSなど)に対して、ISPまたは自前のRDNSサービスを通じてPTRレコードを設定する。
; 攻撃者が制御するIPのPTRレコード設定(例: 198.51.100.7)
7.100.51.198.in-addr.arpa. IN PTR trusted.cleantalk.org.
PTRレコードの設定はISPや一部のクラウドプロバイダのコントロールパネルから可能であり、特別な権限は不要。
- CleanTalkの内部エンドポイントを呼び出す: 攻撃者のIPから対象サイトの CleanTalk エンドポイントへリクエストを送信する。プラグインはPTRルックアップを実行し、攻撃者のIPが
trusted.cleantalk.orgに解決されることを確認して認証を通過させる。
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.example.com
X-Forwarded-For: 198.51.100.7
Content-Type: application/x-www-form-urlencoded
action=cleantalk_check_without_token&plugin_action=install_plugin&plugin=some-plugin-with-cve
- PTRレコードの検証ロジックを内部で確認:
checkWithoutToken関数は以下の処理を実行するが、暗号署名は一切要求しない。
// 脆弱な検証コード(概念的な再現)
function checkWithoutToken($ip) {
$hostname = gethostbyaddr($ip); // PTR逆引き
if (strpos($hostname, 'cleantalk.org') !== false) {
return true; // 認証通過 — 署名・トークン検証なし
}
return false;
}
gethostbyaddr() は外部のDNSサーバーに問い合わせるため、攻撃者が制御するPTRレコードに基づいた結果を返す。
- 任意プラグインのインストール: 認証を通過したリクエストで、WordPressリポジトリから任意のプラグインをインストールさせる。ターゲットとして有効なのは、既知のRCE・SQLi・ファイルアップロード脆弱性を持つ古いバージョンのプラグインを意図的に指定するケース。
plugin_action=install_plugin&plugin=contact-form-7&version=5.3.1
- 脆弱なプラグインを経由したRCE: インストールされた脆弱なプラグインの既知の脆弱性を利用して、Webシェルの設置やOSコマンド実行を行う。CleanTalkの認証バイパスはこの連鎖の起点に過ぎない。
この攻撃で重要な点は、対象サイトへの事前のアクセスや認証情報が一切不要であることです。必要なのはCleanTalkプラグインが有効でAPIキーが無効な状態と、攻撃者が制御するIPのPTRレコードのみです。
実際の被害
- 約 20万サイトがCleanTalk Anti-Spamを使用しており、そのうちAPIキーが無効または未設定のサイトが攻撃対象
- 認証は完全にバイパスされるため、事前の認証情報やセッションは不要
- 任意プラグインのインストールにより、サーバー全体へのRCEチェーンを構成できる
- スパム対策プラグインという性質上、セキュリティ対策として信頼しているサイト管理者が攻撃に気づきにくい
- 攻撃フローを自動化することで、大量のサイトを短時間でスキャン・攻撃することが可能
- インストールされた悪意あるプラグインが削除されない限り、持続的なバックドアとして機能し続ける
修正と教訓
修正: バージョン 6.72 で修正されました。checkWithoutToken のPTRベース認証が削除または強化され、リクエストの正当性を暗号学的なトークンまたはAPIキーで検証するよう変更されました。CleanTalk Anti-Spamを使用しているすべてのサイトは、直ちに 6.72 以上へアップデートし、有効なAPIキーを設定することが必要です。
教訓:
-
DNSは認証の根拠にならない: PTRレコードはIPアドレスの所有権を証明しません。DNSは攻撃者が操作可能な外部システムであり、暗号学的な保証を持ちません。サーバー間通信の認証には、HMACやRSA署名などの暗号学的な手法を使用すること。
-
フォールバック認証は本番環境に存在してはならない: 「APIキーが無効な場合に緩い検証で代替する」という設計は、フォールバックパスそのものが攻撃経路になります。認証が成立しない場合は処理を拒否することが正しい設計です。
-
gethostbyaddr()を信頼しない: PHPのgethostbyaddr()を含む逆引きDNS解決の結果は、外部のDNSインフラに依存しており改ざん可能です。送信元の正当性検証には使用しないこと。 -
プラグインのインストールAPIは厳重に保護する: WordPressのプラグインインストール機能は、サーバー上でのコード実行と等価です。このAPIを外部から呼び出せるエンドポイントに公開する場合、多層の認証と権限チェックが不可欠です。
-
デフォルト設定を安全側に設計する: APIキー未設定という「未完了のセットアップ状態」で最も緩い認証が有効になる設計は、セキュリティのデフォルト原則(Secure by Default)に反します。APIキーがなければ機能を無効化するか、管理者に明示的な警告を表示する設計が求められます。
Nyambushでの検出
NyambushはWordPressプラグインのバージョンを自動的に検出し、脆弱性データベースと照合します。CleanTalk Anti-Spamのバージョンが 6.71 以下の場合、CVSSスコア 9.8 の「Critical」警告を即座に表示します。
さらに、Nyambushはプラグインの設定状態を分析し、APIキーが無設定または無効の可能性がある場合には追加のリスク警告を表示します。この脆弱性はAPIキーが有効なサイトには影響しないため、アップデートと合わせてAPIキーの設定確認も推奨します。
継続監視モードでは、プラグインが 6.72 以上に更新されるまで Critical アラートを維持し、修正を確認した時点でアラートを解除します。20万サイトという規模を考慮すると、自動化された攻撃が急速に展開される可能性が高く、パッチ適用の遅延は大きなリスクとなります。