本文へ移動
English version →
重大 9.8 急ぎ度: 早めに

Jupiter X Coreの認証回避の脆弱性、4.61.0以前が対象

WordPressプラグインのJupiter X Coreに、Xのソーシャルログインを悪用して認証なしで管理者になりすませる脆弱性が見つかりました。4.61.0以前を使うサイトが対象です。版の確認と更新を済ませ、更新できない間はXでのログイン機能を止めてください。

CVE-2026-106013 公開 生成 AI で作成
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSS v3は9.8で、認証なしにサイト管理者として入られるおそれがありますが、KEVへの掲載など実際の悪用を示す情報は確認できていないため、数日以内の更新を目安にします。

関係があるか

Jupiter Xのテーマと一緒にJupiter X Coreを入れているWordPressサイトが対象です。コーポレートサイトや店舗サイトなど、管理画面に外部からアクセスできる構成はすべて当てはまります。

製品影響を受ける版直った版
Jupiter X Core(WordPress向けプラグイン、提供元はartbees) 4.61.0以前のすべての版 4.61.0より新しい版。具体的な版番号はベンダーの告知で確認してください。

確かめ方

  1. 1WordPressの管理画面で、プラグインの一覧からJupiter X Coreの版を確認します。4.61.0以前なら対象です。
  2. 2WP-CLIが使えるなら、wp plugin get jupiterx-core --field=version で版を確認できます。
  3. 3複数のサイトを預かっている場合は、各サイトの版を洗い出します。ステージング環境や使っていない旧サイトも見落とさないでください。
  4. 4フォームにXのソーシャルログインを設定しているかも確認します。設定の有無と影響の関係はunknownsに挙げたとおり未確定なので、設定がなくても更新は必要です。

何が起きたか

Jupiter X Coreに、Xのアカウントでログインする機能を悪用すると、パスワードを知らなくてもWordPressの管理者として入れてしまう脆弱性が見つかりました。

原因は、ログインしに来た訪問者を確認する処理にあります。受付で訪問者の名札ではなく、社長の名札を見て通してしまうようなものです。プラグインはXに「この人は誰か」と問い合わせる際、訪問者の認証情報に切り替えず、サイト運営者が登録してあるアクセストークンのまま署名していました。そのためXが返すのは訪問者ではなく、Xアプリの所有者のプロフィールになります。

プラグインはそのプロフィールのメールアドレスだけを手がかりにWordPressのアカウントを探し、一致したユーザーのログインを成立させます。Xアプリの所有者は通常サイト管理者なので、結果として管理者権限が渡ります。分類はCWE-287(不適切な認証)です。

Wordfenceの情報には、修正を反映したとみられるソースの変更履歴が付いています。対象はXのソーシャルログインを処理するtwitter.phpです。

攻撃の流れ

  1. 1

    ログイン開始

    未ログインの訪問者が、XのソーシャルログインでWordPressのログイン処理を始めます。

  2. 2

    Xへの問い合わせ

    プラグインが訪問者の認証情報に切り替えないまま、プロフィール取得の問い合わせを送ります。

  3. 3

    運営者の情報が返る

    運営者のトークンで署名されているため、Xは訪問者ではなくXアプリ所有者のプロフィールを返します。

  4. 4

    管理者でログイン

    プラグインが所有者のメールアドレスと一致するWordPressユーザーを探し、そのアカウントでログインさせます。

公開されている情報をもとにした流れの例です。

どう悪用されるか

悪用に必要な前提は少なく、CVSSの評価では、ネットワーク経由で、認証も利用者の操作も要りません。攻撃の難しさも低いとされています。サイトの公開ページにアクセスできる第三者なら、条件が揃った場合に試せる状況です。

成功すると、攻撃者はXアプリ所有者のメールアドレスに対応するWordPressユーザーとしてログインします。多くのサイトではそれが管理者です。管理者になれば、投稿や固定ページの書き換え、プラグインやテーマの追加、ユーザーの作成や削除、サイト設定の変更といった操作がすべて可能になります。サイトの改ざんや、マルウェアの設置、訪問者や会員の情報の閲覧にもつながります。

CVSSの評価では、機密性・完全性・可用性のいずれも影響は高とされています。

今すぐやること

  1. 1

    Jupiter X Coreの版を確認する

    管理画面のプラグイン一覧か、WP-CLIで版を調べます。4.61.0以前なら次の手順に進みます。

    wp plugin get jupiterx-core --field=version
  2. 2

    修正版に更新する

    ベンダーの告知を確認し、修正版のJupiter X Coreに更新します。本番に当てる前にステージングで表示とフォームの動作を見ておくと、更新後のトラブルを減らせます。

  3. 3

    更新できないサイトは回避策を先に入れる

    更新に時間がかかるサイトでは、回避策の項に書いた手順で、Xでのログインを先に止めます。

  4. 4

    管理者アカウントとログインの履歴を見直す

    心当たりのない管理者の追加、見覚えのないプラグインやテーマ、最近の不審なログインがないかを確認します。ログインの痕跡がXログイン由来かどうかは判別しにくい場合があります。更新前の期間も含めて確認してください。

  5. 5

    不審な形跡があれば管理者の認証情報を入れ替える

    不審なログインが見つかったら、管理者のパスワードを変更し、ログイン中のセッションを破棄します。そのうえで、改ざんされたファイルがないかも調べます。

すぐ更新できないとき

すぐに更新できないときは、フォームやログインの設定からXのソーシャルログインを外し、ログインボタン自体を表示しないようにします。設定の項目名はテーマの版や構成で異なる場合があります。Xでのログインをそもそも使っていない場合も、念のため設定が残っていないかを確認してください。それでも更新までの間は、管理画面へのアクセスを社内のIPアドレスなどに絞ると、被害を受ける範囲を小さくできます。

背景

Jupiter Xは、企業サイトやオンラインストアを組み立てるために使われるWordPressのテーマで、Jupiter X Coreはそのテーマに付属して、フォームなどの機能を提供するプラグインです。今回の脆弱性があるのは、そのうちフォームのモジュールに含まれるソーシャルログインの処理です。サイトの見た目を決めるテーマの一部として入るため、管理者が単独のプラグインとして意識していないことがあります。

ソーシャルログインは、外部サービスに「この訪問者は誰か」を問い合わせ、その答えをもとに自サイトのアカウントを決めます。今回は、問い合わせを訪問者の認証情報で行うべきところを、サイト運営者のものを使い続けていたことで答えが取り違えられました。外部サービスの答えを正しい本人のものとして信用する作りでは、問い合わせの署名にどの認証情報を使ったかを、確認する側がきちんと管理しているかどうかが、そのまま安全性に直結します。

よくある質問

Q.更新したあと、管理者のパスワードも変えるべきですか。
A.この脆弱性はパスワードを盗むものではなく、ログイン処理を迂回するものです。パスワードが漏れたという説明もありません。そのため、不審なログインや不審な管理者の追加が見つからなければ、パスワードの変更は必須ではありません。形跡がある場合は、パスワードの変更とセッションの破棄を行ってください。

まだ分かっていないこと

  • 修正版の具体的な版番号は、ここで挙げた情報からは特定できません。ベンダーの告知とWordPressのプラグインページで確認してください。
  • この脆弱性を悪用した実際の攻撃が確認されているかは分かっていません。
  • Xのソーシャルログインを有効にしていないサイトでも、同じ経路で影響を受けるのかは説明されていません。確認が取れるまでは、対象の版であれば影響を受けるものとして扱うのが安全です。

この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。

影響パッケージ

種類パッケージ影響を受ける版直った版
artbees Jupiter X Core
4.61.0 以前
—
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

The Jupiter X Core plugin for WordPress is vulnerable to Authentication Bypass via the Twitter/X Social Login handler in all versions up to and including 4.61.0. The vulnerability exists within the verify_twitter_callback function because after exchanging the visitor's oauth_verifier for their access token, the handler never calls setOauthToken() to reassign the returned credentials to the TwitterOAuth client, causing the subsequent account/verify_credentials API call to remain signed with the site operator's stored Access Token and Access Token Secret rather than the authenticating visitor's token. This causes the X API to return the profile of the X application owner instead of the signing-in visitor, and the plugin then resolves and authenticates a WordPress account solely by matching that owner's email address via wp_set_auth_cookie(), allowing unauthenticated attackers to gain authenticated access as the WordPress user whose email corresponds to the X app owner, who is typically the site administrator.

出典: CVE.org (CVE Program・cvelistV5) NVD

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく