Baselテーマの同梱プラグインに認証回避の脆弱性　1.19へ上げる

WordPress向けのセキュリティ製品を作るWordfenceは11月10日付で、WooCommerce向けのテーマ「Basel」に付くプラグイン「Basel Post Types」の脆弱性の公告を出した。米国立標準技術研究所（NIST）の脆弱性データベース「NVD」は、11月11日（日本時間）にこの脆弱性の記録を載せた。認証なしで、管理者を含む既存の利用者として入られ得る。1.19以降へ上げる必要がある。

1.18以前の版が当たる

公告とNVDの記録によると、対象と修正版は次のとおりだ。

• 対象: XTemosが作るプラグイン「Basel Post Types」（スラッグはbasel-post-types）の1.18以前の全版
• 修正版: 1.19
• CVE番号: CVE-2026-89324
• 深刻度: CVSS 3.1で9.8（Wordfenceの評価）。認証も利用者の操作も要らない
• 弱点の種類: CWE-287（認証の不備）
• 当たる条件: WooCommerceが有効で、テーマの設定でFacebook、Google、VKontakteのソーシャルログインの少なくとも1つに、アプリのIDと秘密の値を入れている

NVDの説明によると、プラグインは、WordPressの設定ファイルにある秘密の値の1つが定義されているかを確かめる処理で書き方を誤っていた。そのため、この値を必ず使わず、テーマのソースに書かれた固定の値で署名を確かめていた。固定の値は誰でも読めるため、ソーシャルログインから戻る時の通知を偽れば、任意の利用者として入れる。ソーシャルログインの処理には、外部の認証をつなぐ部品「Opauth」が使われている。NVDは11月11日の時点で独自の評価を付けておらず、9.8はWordfenceが付けた評価だ。公告によると、見つけたのは研究者の0xwackydawg氏だ。

プラグインの版を確かめる

Basel Post Typesは、テーマと一緒に入るプラグインだ。WordPressの管理画面の「プラグイン」の一覧で、Basel Post Typesの版を見る。WP-CLIを使っているなら、一般的なコマンド「wp plugin list」でも一覧に出る。版が1.18以前なら当たる。複数のサイトを運用しているなら、本番だけでなく検証用のサイトも見る。ThemeForestにあるテーマの5.7.2の更新の記録は、同梱のプラグインを「XTEMOS Post Types」と書いている。一覧にこの名前が出ていないかも見たい。制作会社にサイトの運用を任せている場合は、使っているテーマがBaselか、同梱のプラグインの版がいくつかを、先方に問い合わせる。

あわせて、WooCommerceが有効か、テーマの設定でソーシャルログインにアプリのIDを入れているかも見たい。NVDの説明が挙げる条件はこの2つがそろうことで、そろえば今すぐ直す対象になる。条件がそろっていたサイトは、版を上げるだけで終わらせず、利用者の一覧に見覚えの無い管理者が増えていないかも確かめたい。これは公告の求めではなく、入られ得た期間があった場合の一般的な確認だ。攻撃は既存の利用者として入る形なので、管理者が増えていなくても、入られていないとは言えない。

1.19へ上げ、手順は公式に従う

公告は、1.19かそれより新しい版へ上げるよう勧めている。公告に、上げられない場合の回避策は書かれていない。

開発元のXTemosのテーマの更新の文書は、テーマのライセンスを認証すると管理画面から更新できると書く。手動で更新する場合は、先にファイルの写しを取り、WordPressとWooCommerceも最新にするよう求めている。ThemeForestの販売ページの更新の記録では、テーマの最新版は10月22日の5.9.4で、重要なセキュリティの問題を直したとある。2023年の5.7.2の記録には、テーマと同梱のプラグインを一緒に上げることが大事だとある。ただし、どのテーマの版に1.19が付くかは、記録からは確認できなかった。テーマを上げた後に、プラグインの一覧でBasel Post Typesが1.19以上になったことを必ず確かめたい。上がっていなければ、XTemosの文書か問い合わせの窓口で、同梱のプラグインだけを上げる手順を確かめる。

NVDの説明の条件に照らすと、条件の外にあるサイトでも、1.18以前のまま後でソーシャルログインを設定すれば、その時点で当たる。

悪用の報告はまだ無い

CVE-2026-89324は、11月11日の時点で、サイバーセキュリティ・社会基盤安全保障庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っていない。悪用の報告も公告には無い。一方で、原因の仕組みはNVDの説明で誰でも読める。

SAGUSでは当たらなかった

SAGUSは、開発に使う端末と社のGitHubのリポジトリについて、WordPressとBaselを使っていないかを確かめた。端末の作業場所の設定ファイルをBasel、WordPress、WooCommerceの語で検索し、GitHubの組織も、プラグインの名前とWordPressの置き場の名前でコードを検索した。どちらにもWordPressのテーマやプラグインを使う物は無く、本番のサイトもWordPressで動いていない。このため、今回の脆弱性には当たらなかった。

編集部の見方

編集部は、Baselを使うサイトは、ソーシャルログインの設定に関わらず、今日中にBasel Post Typesの版を確かめ、1.18以前なら上げるべきだと考える。1.18以前のまま置くと、後でソーシャルログインを設定した時点で当たるからだ。テーマに同梱するプラグインは、テーマを上げても版が変わったかが見えにくい。同梱の物も含めて、版を一覧で確かめる手順を持っておきたい。