Jupiter X Coreの「Xでログイン」から、管理者として入られるおそれ

OVERVIEW

WordPress テーマ Jupiter X の付属プラグイン Jupiter X Core で、Jupiter X Core 4.61.0 以前に、X（旧Twitter）でログインする機能から認証をすり抜けられる脆弱性（CVE-2026-106013）が見つかりました。2026年10月28日に公開された記録によると、ログインしていない人が、そのサイトの管理者として入れるおそれがあります。深刻度の点数（CVSS）は10点満点の9.8です。

原因は、X に本人を問い合わせるときに、訪問者ではなくサイト側が登録した X のアカウントで問い合わせていたことです。修正は Jupiter X Core 4.62.0 に入っていて、Jupiter X Core 4.61.0 では直っていません。

この記事では、Jupiter X Core のどんな機能で何が起きていたのかと、なぜ別人として入れてしまったのかを、公開された脆弱性の記録から書きます。どのバージョンで直ったのかは記録に書かれていないので、WordPress.org の配布記録で確かめた結果を添えました。更新したあとに見ておく場所は、最後の節にまとめています。

Jupiter X Coreとは

Jupiter X Core は、Artbees が作る WordPress テーマ Jupiter X の機能を動かすためのプラグインです。WordPress.org の説明では、Jupiter X の機能をすべて使うには、このプラグインを入れて有効にする必要があります。WordPress.org では2019年から配られていて、有効インストールは7万以上です。

テーマの設定画面や、ヘッダー・フッターを組み立てる機能のほか、ページ編集プラグイン Elementor で使う部品（ウィジェット）もこのプラグインが足しています。今回問題になったのは、その部品の一つである「Social Login」です。ログイン画面に「X でログイン」などのボタンを出し、訪問者が X のアカウントで WordPress にログインできるようにします。

Jupiter X Core 4.61.0以前は、「Xでログイン」から管理者として入られるおそれがあった

脆弱性の記録によると、Jupiter X Core 4.61.0 以前のすべてのバージョンで、X でログインする処理から認証をすり抜けられました。ログインしていない人が、サイトに登録された X アプリの持ち主と同じメールアドレスを持つ WordPress ユーザーとして入れる、という内容です。記録は、そのユーザーが多くの場合サイトの管理者だと書いています。

X でログインできるようにするには、サイトの持ち主が X の開発者向け画面でアプリを作り、その鍵を Jupiter X Core の設定欄「X API Details」に登録します。欄は API KEY、API Secret Key、Access Token、Access Token Secret の4つです。記録が問題にしているのは、この欄にサイト側の X のアクセストークンが保存されているサイトです。X でのログインを一度も設定していないサイトにこの経路がある、とは書かれていません。

CVSS 9.8 の内訳は、ネット越しに、ログインも利用者の操作も要らずに狙えて、情報の漏れ・書き換え・停止のどれも影響が「高」という評価です。脆弱性を見つけたのは daroo さんで、記録を作ったのは WordPress のセキュリティ企業 Wordfence です。開発元には10月6日に知らされていました。

実際に狙われたかどうかについては、米国の CISA が10月29日に付けた評価で、悪用は「none（確認なし）」です。一方で同じ評価は、この脆弱性を「自動化しやすい（automatable: yes）」としています。多くのサイトを機械的に探して回る攻撃に向いた種類だ、という意味です。

原因は、訪問者本人ではなく、サイトが登録したXのアカウントで本人を確かめていたこと

Jupiter X Core は、X でログインしようとした人が誰なのかを X に問い合わせるとき、その訪問者の認証情報ではなく、サイトが保存していた X のアクセストークンを使い続けていました。記録の説明は次の流れです。

本来は、訪問者が X で「このサイトへのログインを許可する」と操作すると、訪問者本人の認証情報がサイトに渡ります。サイトはそれに切り替えてから X に「この人は誰か」を尋ね、返ってきたプロフィールで本人を確かめます。Jupiter X Core 4.61.0 以前は、この切り替えをしていませんでした。そのため問い合わせはサイト側のトークンのまま送られ、X は訪問者ではなく、X アプリの持ち主のプロフィールを返していました。

そのあと Jupiter X Core は、返ってきたメールアドレスだけを手がかりに WordPress のユーザーを探し、そのユーザーとしてログインさせます。X アプリを作るのはたいていサイトの持ち主か管理者なので、誰が「X でログイン」を押しても、管理者のアカウントでログインした状態になり得ました。パスワードを破られたわけではなく、本人確認の相手を取り違えていたことが原因です。

修正はJupiter X Core 4.62.0に入っていて、4.61.0の「セキュリティ修正」とは別のもの

今回の修正は、2026年10月22日に WordPress.org に出た Jupiter X Core 4.62.0 に入っています。脆弱性のデータベース NVD と、それを引いた Advisory（GHSA-5×75-7jgc-v7c2）には「Jupiter X Core 4.61.0 以前が対象」とあるだけで、修正バージョンの番号は書かれていません。そこで、WordPress.org の配布記録で、X ログインの処理を Jupiter X Core 4.60.0 と 4.62.0 で比べました。4.61.0 は変更履歴には載っていますが、配布記録には残っていません。

10月6日：開発元の Artbees に脆弱性が知らされる
10月22日：Jupiter X Core 4.62.0 を公開。X ログインの処理に、訪問者の認証情報へ切り替える処理が入る
10月27日：Wordfence が脆弱性を公開
10月28日：CVE-2026-106013 の記録と Advisory が公開される

Jupiter X Core 4.62.0 の変更履歴には「Fixed Security issue（セキュリティ上の問題を修正）」と「Social Login ウィジェットの警告を修正」が並んでいます。紛らわしいのは、ひとつ前の Jupiter X Core 4.61.0 の変更履歴にも「Fixed security issue」の一行があることです。

しかし、脆弱性の記録は Jupiter X Core 4.61.0 を対象に含めています。配布記録でも、訪問者の認証情報へ切り替える処理は Jupiter X Core 4.60.0 に無く、Jupiter X Core 4.62.0 で初めて入っています。Jupiter X Core 4.61.0 の「セキュリティ修正」は今回の件とは別で、今回の分が直っているのは Jupiter X Core 4.62.0 以上です。変更履歴の 4.61.0 の一行を見て対応済みと考えていたサイトも、もう一度更新が要ります。

Xのログインを設定していたサイトは、更新したあとに管理者の一覧を見る

X でのログインを設定していたサイトは、Jupiter X Core を 4.62.0 以上に上げたあと、WordPress の「ユーザー」画面で管理者の一覧を確かめてください。Jupiter X Core 4.62.0 の必須条件は WordPress 5.6 以上と PHP 7.0 以上で、WordPress 7.1.4 まで動作が確かめられています。WordPress 本体を 7.1.4 に上げても、Jupiter X Core のバージョンは替わりません。本体の更新については【脆弱性修正】WordPress 7.1.4がリリースされましたに書きました。

更新でふさがるのは、これから先の入口です。更新より前に誰かが管理者として入っていた場合、その間に足されたユーザーやプラグインは、Jupiter X Core を更新しても消えません。覚えのない管理者が増えていないか、入れた覚えのないプラグインがないかを見ます。狙われ得たのは、X アプリの持ち主と同じメールアドレスの WordPress ユーザーなので、そのアカウントのパスワードも変えておくと安心です。

記録が条件にしているのは、サイトに保存された X のアクセストークンです。ページに「X でログイン」のボタンを置いているかどうかには触れていません。以前に X のログインを試して、ボタンはもう外したというサイトも、設定欄にトークンが残っていれば対象と考えて更新するのがよい、と私たちは判断しています。

参考にした一次情報

Jupiter X Core のように、変更履歴の「セキュリティ修正」が続けて並んでいると、どのバージョンで何が直ったのかを変更履歴だけでは見分けられません。X でのログインのように一度設定して忘れている機能があると、自分のサイトが対象かどうかの判断も遅れます。

サイト番では、プラグインやテーマの定期更新、バックアップ、表示の確認、障害のときの復旧を、担当者が内容を見て行います。

WordPress更新などの保守管理に手が回らない場合は、是非サイト番にお任せください。