Better AuthのExpo連携で認証回避｜更新後に旧署名の失効を確認

Better AuthのExpo連携を使う認証サーバーでは、公開された認可プロキシがサーバー自身の発行していない値に署名し、第三者によるアカウントの乗っ取りにつながる問題が修正されました。開発元が11月3日に公表した個別勧告 GHSA-4wq4-2ppv-q3hgによると、対象版のサーバーでExpoプラグインを登録している場合は、better-auth本体と@better-auth/expoをそろえて更新してください。脆弱なエンドポイントへ到達できた環境では、更新後にアプリケーションの秘密鍵も切り替えます。

この署名の問題は、11月4日にCVE-2026-121802としても掲載されました。問題があるのは、モバイルアプリに組み込んだログイン画面そのものではなく、ブラウザーへの受け渡しを助けるサーバー側の処理です。同じ認証APIをWeb版とモバイル版で共有していれば、モバイル向けに追加した経路が、Web版でも使うアカウントに影響します。アプリストアへの再申請やクライアントの配布を待つ前に、現在トラフィックを処理している認証サーバーを調べる必要があります。

サーバーでexpo()を登録しているか

開発元は、サーバーで@better-auth/expoのexpo()を登録する構成を影響判定の出発点にしています。Expo向けパッケージの影響範囲は1.4.0-beta.6以上かつ1.7.16未満、または1.8.0-beta.0以上かつ1.8.0-beta.5未満です。修正版は安定系列の1.7.16と、ベータ系列の1.8.0-beta.5です。個別勧告には本体パッケージの範囲も載っていますが、本体の版だけでこのExpo経路の有無は決まりません。依存関係とサーバーのプラグイン登録を両方確認します。

具体的には、モノレポのモバイルアプリ側だけでなく、認証ハンドラーを構成するファイルと、認証サービスが使うロックファイルを開きます。開発環境と本番でプラグインを条件付き登録している場合は、本番の分岐を確認します。npmで管理していれば、認証サービスのディレクトリで npm ls better-auth @better-auth/expo を使って解決された版を確認できます。ローカルの結果は配備済みコンテナの版を証明しないので、稼働中のリビジョンは別に照合します。

次に、認証APIのベースパス配下にある /expo-authorization-proxy が、どのホスト名から到達可能だったかを調べます。公開Webアプリの同一オリジンにマウントされた経路、モバイル専用API、直接アクセスできるオリジン、検証用の別名ホストは分けて考えます。主ドメイン側だけで制限していても、同じ認証サービスや秘密鍵を使う別の入口が公開されていれば、そちらの履歴も対象です。実際の利用者がExpoログインを使ったかどうかより、攻撃者が経路を呼べたかが優先です。

なぜ署名が別の認証処理に通ったのか

通常、ソーシャルログインで使うstateは、サーバーが始めた認可処理と戻ってきた応答を結び付ける値です。修正前のプロキシは、呼び出し側が渡した認可URLからstateを取り出し、自分が発行した値かを確認せずに署名付きCookieとして返しました。秘密鍵そのものを攻撃者が読む必要はなく、公開処理に署名を作らせるだけで成立する点が、この問題の要点です。

開発元によれば、同じアプリケーション秘密鍵を使うメール関連のトークンと、セッションCookieキャッシュの一部にも署名が通る構造でした。勧告が示す主な影響は、第三者が利用者のメールアドレスを知っていると、その利用者の操作を必要とせずになりすまし、登録メールアドレスを変更できることです。セッションCookieキャッシュを有効にした環境では、利用者IDを知る第三者がその利用者として行動できる経路もあります。後者を使っていない場合も、前者の理由で対応対象からは外れません。勧告の深刻度はCriticalで、CVSS 3.1は9.1です。これは攻撃条件と影響の評価であり、被害件数を示す値ではありません。

同じ勧告は、プロキシから任意の外部HTTPSサイトへ遷移できた問題と、trustedOriginsのワイルドカードが意図した範囲の外に一致し得た問題も扱います。ワイルドカードの問題には実際にワイルドカードを設定していることが条件になりますが、その設定がなくても署名の問題は残ります。修正版はサーバーが発行した有効期限内のstateだけを署名し、遷移先を構成されたプロバイダーの認可エンドポイントのオリジンに制限します。ワイルドカードの照合も、URLを解析してスキーム、ホスト、パスを判定する方式に変わっています。

更新と秘密鍵の切り替えを一つの作業として計画する

Better Authのリリース案内では、今回の配布で12件の問題を修正し、関連するBetter Authパッケージを一緒に更新するよう求めています。本記事が扱うのはExpoの勧告です。認証サービスで使うパッケージを列挙し、採用中の系列の修正版へまとめて上げてロックファイルを更新します。ビルドに固定した依存関係を使い、配備後はイメージやデプロイの識別子を記録して、旧版のレプリカが入口に残っていないことを確かめます。

エンドポイントへ到達できた環境では、開発元は更新後の秘密鍵ローテーションを案内しています。コードの更新で新たに不正な署名を作らせる経路は塞がりますが、更新前に作られた署名は、旧鍵で引き続き検証できる間は有効になり得ます。新しい鍵を設定したという作業記録だけで終えず、旧鍵で署名された値が対象の検証経路で通らないことを終了条件にします。公式の設定リファレンスにある旧鍵を保持する仕組みは、暗号化データの復号を継続するための設定です。暗号化データの移行と問題のある署名の失効は別々に確認してください。

運用上は、未修正のインスタンスが残ったまま新しい鍵を読ませない順序が重要です。旧版へ新しい鍵を配って公開経路が残れば、その新しい鍵で再び署名を作られる可能性があります。逆に、同じ認証サービスの中で旧鍵と新鍵を使うインスタンスが同時に応答すると、ログインの開始とコールバックが別の個体に届いたときに失敗することがあります。配備方式に合わせ、旧版へのルーティングを外し、修正版と鍵の世代がそろった状態で認証を受け付けるようにします。認証を一時停止できない場合は、切り替え前に対象経路を絞れるか検討します。

鍵を変えると、利用者が進行中だったOAuthログインを最初からやり直す必要が出る場合があります。Better Authのstate_invalidの説明も、開始とコールバックの間に鍵が変わると状態を復号できない場合があるとしています。運用担当者は、想定される再ログインの案内と、切り替え直後に失敗した利用者への問い合わせ対応を用意します。すでに発行されたセッションや成立したメールアドレス変更を、鍵の切り替えだけで元に戻せるとは考えないでください。

更新前に取れる暫定措置と限界

Expoのソーシャルログインを使っていなければ、開発元はサーバーのexpo()プラグインを外す方法を案内しています。使っている場合の暫定策は、当該経路へのリクエストで、authorizationURL内のstateが英大文字・英小文字・数字・ハイフン・アンダースコアだけの32文字に一致しない場合に拒否することです。プロキシで適用するなら外側のURL全体に対する部分一致で済ませず、実際にサーバーへ渡るパラメーターと同じ解釈で判定できるかを確認します。公式の暫定策が対象にするのは署名の問題だけで、リダイレクトやワイルドカードの修正を代替しません。

認証を止める判断では、経路の遮断とサービス全体の遮断を区別します。経路を使わない環境なら対象機能の無効化を先に検討できます。依存する環境では、入口での一時制限が本来のログインを妨げないか、テスト用のクライアントで確かめます。リリース案内にはVercelでのWAF保護も記載されていますが、開発元はそこでも更新を勧めています。自社運用の環境や別経路にも同じ保護があると仮定しないでください。

更新後は正規のログインと拒否の両方を見る

検証環境では、実際に使うプロバイダーごとにExpoアプリからログインを開始し、システムブラウザー、認証API、アプリへの復帰まで一巡させます。続いてWeb版のログイン、メールアドレス変更、ログアウト後の再ログインを確認します。SSOのプロバイダーだけが更新後に失敗する場合、開発元はそのプロバイダーのオリジンをtrustedOriginsに加えるよう案内しています。公式のExpo連携ガイドを参照し、アプリ復帰用のスキームとSSO側のオリジンを区別して、必要なものだけを登録します。動作を戻す目的で広いワイルドカードへ変えると、許可範囲の見直しが難しくなります。

拒否側は、管理下の検証環境と専用アカウントで、期限切れやサーバー未発行のstateが受理されないこと、構成していない外部オリジンへ送られないこと、旧鍵で署名した検証用の値が通らないことを確認します。Cookieキャッシュを有効にしている構成は、その設定を再現した上でセッションの有効性を調べます。アクセスログや検証記録にCookie、認可コード、署名済みトークンの生値を残す必要はありません。対象経路、時刻、リクエスト識別子、結果コードなどを記録し、利用者データを含まない形で照合します。

過去の到達範囲から調査対象を決める

開発元の個別勧告で確認できるのは、成立条件、影響と修正です。公開されていた自社環境で悪用がなかったかは、手元の記録から別に判断します。まず脆弱な版と設定を使い始めた時期、外部から到達できた期間、修正版への切り替え時刻、旧鍵が受理されなくなった時刻を並べます。入口のログが残る期間と、実際に調査できる期間が一致しなければ、その空白を明示します。

対象経路への普段と異なるリクエストに加え、直後のメールアドレス変更、アカウント復旧、想定外のセッションや管理操作がないかを照合します。認証ログだけでは追えない操作は、アプリ側の監査ログや変更履歴と合わせます。単発のアクセスや異常な値だけで侵害を断定せず、同じアカウントに対する操作の時系列を確認します。異常な変更が確認できた場合は、該当セッションの無効化やアカウントの復旧を、通常のインシデント対応に沿って進めます。

作業の完了は、修正版への更新、公開されていた場合の旧署名の失効、正規ログインの再確認を別々に記録して判断します。ログインが戻っただけでは旧署名の拒否を証明できず、旧署名を拒否できたことだけでも更新前に成立した操作の調査は終わりません。Webとモバイルで認証基盤を共有しているなら、両方の担当が同じ切り替え時刻と確認結果を参照できるようにします。