「AutomatorWP」のWebhooksに認可回避の脆弱性　管理者を乗っ取られ得る

米国立標準技術研究所（NIST）の脆弱性データベースNVDに11月14日14時18分（日本時間）、WordPressの自動化プラグイン「AutomatorWP」の有料のWebhooksアドオンの脆弱性「CVE-2026-126173」が載った。当たるのはアドオンの1.4.4以前で、Webhookで受けた値で利用者のパスワードを更新する自動化を組んだサイトだ。条件がそろうと、認証なしで管理者を含む利用者のパスワードを変えられ、アカウントを乗っ取られ得る。アドオンを1.4.5に上げ、自動化の設定とログを確認する。

1.4.4以前と特定の設定が条件

NVDの記載では、対象と深刻度は次のとおりだ。

• 対象: AutomatorWPのWebhooksアドオン（有料のPROのアドオン）
• 当たるバージョン: 1.4.4以前の全部
• 直ったバージョン: NVDの記載に無い（開発元の変更履歴の最新は1.4.5）
• CVE番号: CVE-2026-126173
• 深刻度: CVSS 3.1で9.8（米Wordfenceの評価。11月14日の時点でNVD自身の評価は無い）
• 弱点の種類: CWE-862（認可の確認が無い）

AutomatorWPは、WordPressのプラグイン同士をつなぎ、コードを書かずに作業を自動化する。Webhooksアドオンの紹介ページによると、アドオンは外部のサービスからWebhookでデータを受けて自動化を始めるトリガーと、外へデータを送るアクションを足す。受ける側のトリガーは、ログインしていない訪問者向けの自動化にも使える。

番号を振ったのはセキュリティ企業のWordfenceだ。Wordfenceの説明を引くNVDの記載によると、アドオンは要求を送った者にその操作の権限があるかを確認していなかった。

ただし、入れただけでは当たらない。NVDは、Webhookでデータを受けるトリガーと、利用者を更新するアクションを組み合わせた自動化を条件に挙げる。トリガーでは受けた値の1つを利用者のIDとして扱い、アクションでは更新先の利用者のIDを空にし、パスワードにWebhookで受けた値を当てる設定だ。NVDは、これを開発元が文書で案内している正規の設定だとしている。

アドオンと自動化を確認する

まず管理画面のプラグインの一覧でAutomatorWPのWebhooksアドオンのバージョンを見る。無料版のAutomatorWPだけを入れたサイトは、このアドオンが無いので当たらない。

アドオンが1.4.4以前ならAutomatorWPの自動化の一覧を開く。開発元の説明書によると、Webhookのトリガーでは、受ける値ごとに必須かどうかや、利用者のIDとして扱うかを決める。トリガーに利用者のIDの値を持ち、アクションでパスワードを変える自動化があれば、条件に当たるかを1つずつ見る。説明書では、ログインした利用者向けの自動化で、誰の操作とみなすかを3つから選ぶ。ログイン中の利用者、受けた値の中の利用者のID、受けた値の中のメールアドレスだ。今回の条件に当たるのは、受けた値の中の利用者のIDで決める設定だ。

アドオンを1.4.5に上げる

開発元の変更履歴では、Webhooksアドオンの最新は1.4.5だ。Webhookの保護を強める「Protect Webhook」という機能を足したとある。NVDは直ったバージョンを挙げていないが、1.4.4以前が当たるとしており、1.4.5に上げるのが先だ。上げた後は、プラグインの一覧で1.4.5と出ることを確認する。説明書には、受ける値に必須の印と決まった値を付け、合言葉のように使う方法も載っている。ただし、この方法が今回の脆弱性を防ぐかは、NVDにも開発元の変更履歴にも記載が無い。NVDの記載に、すぐ上げられない時の回避策は無い。

悪用は確認できていない

CVE-2026-126173は、11月14日の時点で米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っておらず、NVDの記載にも悪用の確認は無い。

当たる設定を動かしていたサイトは、受けたWebhookのログを確認する。説明書によると、AutomatorWPのメニューの「Webhooks logs」に、Webhookを送ってきた元のURL、送られた値、割り当てた利用者が残る。覚えのない受信や、パスワードが変わった利用者が無いかを確認する。見つかった時はログを消さずに残し、該当する利用者のパスワードを変え直す。

SAGUSでは当たらなかった

SAGUSは、本番のサイトとRolloutのサイトに、WordPressのログイン画面とAutomatorWPのファイルのパスを問い合わせ、どれも404だった。開発に使う端末の作業場所も、依存関係と設定のファイルとPHPのファイルをgrepでプラグインの名前の語で検索し、見つからなかった。端末にはPHPもWordPressの管理コマンドも入っていない。SAGUSはWordPressもこのプラグインも使っておらず、今回の脆弱性には当たらなかった。

編集部の見方

開発元が案内する正規の設定の組み合わせで穴が開いた点を、編集部は重く見る。Webhookは外から届く入口で、受けた値で利用者を書き換える設定は、送り手を確かめる仕組みと組で考える必要がある。ノーコードの自動化は作った本人のほかは中身を見ないことが多い。バージョンを上げるだけでなく外から値を受けて権限やパスワードを変える自動化が無いかを、定期的に一覧で見直す工程を持ちたい。