脆弱性・CVE速報深刻度: 緊急

better-auth で、OAuth の state 値がマジックリンクとして通り、他人のアカウントにログインされる不具合（CVE-2026-114607）: 1.4.0-beta.18 以上 1.7.7 未満が対象、1.7.7 で修正

World Security 編集部2026年10月31日公開

目次（5）

要点

OAuth ログインの state 値が、マジックリンクのトークンとして受け付けられる。メールアドレスさえ知っていれば、そのアドレスの利用者のセッションを得られる（勧告の説明、当サイトでは未再現）
マジックリンクでの新規登録が有効だと、メール確認済みと誤って記録されたアカウントを作れる。disableSignUp: true では既存アカウントの乗っ取りは止まらない
対象は 1.4.0-beta.18 以上 1.7.7 未満、修正版は 1.7.7（9/30 UTC）。条件はマジックリンク有効、OAuth プロバイダー有効、state をデータベースに保存（既定）の 3 つがすべて
更新後は、更新前のマジックリンクと進行中の OAuth／SAML ログインが完了できなくなる。共有ストレージのサーバーは同時に切り替える
NVD は Deferred（自身の評価なし）、GitHub の CVSS v3.1 は 9.1、EPSS 0.42%（10/31）、KEV 掲載なし

CVE-2026-114607

Node.js 向けの認証ライブラリ better-auth で、OAuth ログインの途中で発行される state 値が、マジックリンクのトークンとして受け付けられてしまう不具合（CVE-2026-114607、GHSA-965c-763c-88jm）が公開されました。メールアドレスさえ知っていれば、そのメールを受信できなくても、そのアドレスの利用者としてログインできるおそれがあります。GitHub の深刻度は Critical、CVSS v3.1 は 9.1 です。修正版は 1.7.7（9/30 UTC に公開）です。CISA の KEV には、確認した範囲では載っていません。

何が起きるか

better-auth は、マジックリンク（メールで届くログイン用リンク）と、ソーシャル／汎用 OAuth ログインの state 値を、同じ「検証レコード」の保存先に置いていました。マジックリンクの側は、レコードが「マジックリンク用に発行されたものか」を確かめずに引き換えていました。
攻撃者は、任意のメールアドレスを指定して OAuth ログインを開始し、返ってきた state 値をマジックリンクのトークンとして使います。勧告によれば、メールの受信も、OAuth の提供元でのログインも、コールバックの完了も要りません。
結果として、既存の利用者のセッション（その利用者の権限すべて）を得られます。マジックリンクでの新規登録が有効で、そのアドレスの利用者がまだいない場合は、メール確認済みと誤って記録されたアカウントを作れます。この「確認済み」の印は、のちに本来の持ち主がログインしたときの保護を回避し、攻撃者のセッションがそのアカウントに残る可能性があります（勧告の説明）。

影響を受ける条件

次の 3 つがすべて当てはまる場合に影響を受けます（勧告の記載）。

項目	内容
対象	better-auth（npm）1.4.0-beta.18 以上 1.7.7 未満
修正版	1.7.7
弱点	CWE-287（不適切な認証）
評価	GitHub 提供の CVSS v3.1 は 9.1（AV:N/AC:L/PR:N/UI:N、機密性・完全性が高、可用性は影響なし）。NVD 自身の評価は未実施
条件 1	マジックリンクが有効で、トークンの保存が既定の plain、または hashed かつ全体の verification.storeIdentifier も hashed
条件 2	組み込みのソーシャルプロバイダー、または汎用 OAuth プロバイダーが 1 つ以上有効
条件 3	OAuth の state の保存が account.storeStateStrategy の "database"（データベースまたは副ストレージを設定している場合の既定）

state を cookie に持つ方式では、この経路は塞がれます。ただし OAuth Proxy を併用している場合は、別の条件があります（勧告の記載）。
マジックリンクの disableSignUp: true を設定しても足りません。新規アカウントの作成は止まりますが、既存アカウントの乗っ取りは止まりません（勧告の説明）。

修正の中身

修正は PR #11494（9/30 UTC にマージ。マージコミット ac54bfd）で、変更は 21 ファイルです。

マジックリンクの検証識別子と、データベースに持つ OAuth／SAML の state に、別々の接頭辞（magic-link: と auth-state:）を付けました。
マジックリンクは、引き換える前にレコードの用途と形を確かめ、合わないレコードは消費せずに拒否します。消費した結果も、セッションを発行する前にもう一度確かめます。
OAuth の state の cookie と OAuth Proxy の各ペイロードに、用途ごとに別の暗号鍵を派生させるようにしました。

リリースタグ v1.7.7 にこのマージコミットが含まれることは、比較で確認しました（ahead 2、behind 0）。データベースのスキーマ変更や利用者・アカウントの移行は要りません。

対応

better-auth を 1.7.7 以上に更新します。同じ時期にリリースされた better-auth のアダプターやプラグイン、連携も、同じ版に揃えます（勧告の記載）。
共有の検証ストレージを使う複数のサーバーは、同時に切り替えます。切り替え後は、更新前に発行したマジックリンクと、進行中の OAuth／SAML ログイン、アカウント連携は完了できないため、やり直しになります。cookie で state を持つ方式では、同じ流れを扱うノードをすべて同時に更新します。OAuth Proxy を使う場合は、本番・プレビュー・開発のすべてを同時に更新します。
verification.storeIdentifier.overrides で検証識別子を調べるカスタムのルールは、magic-link: と auth-state: の接頭辞に合わせて直します。独自のハッシュ関数は、用途の接頭辞を保ったままハッシュする必要があります。
すぐ更新できない場合の一時策（勧告の記載）: account.storeStateStrategy を "cookie" にする（OAuth Proxy を併用する場合は、先に全体の秘密鍵と異なる専用の secret を全環境で設定する）、マジックリンクの storeToken を "hashed" にして全体の storeIdentifier は未設定か plain のままにする、またはマジックリンク、あるいはソーシャル／汎用 OAuth のログインを止める。
条件に当てはまる環境で 1.4.0-beta.18 以降を使ってきた場合は、想定外のログインや、見覚えのない確認済みアカウントがないか、認証ログを見直すと安全です（本記事の推定）。

未確認の点

NVD の状態は Deferred（10/22 公開、10/23 更新）で、NVD 自身の評価はまだありません。CVSS v3.1 の 9.1 は GitHub の評価で、勧告の CVSS v4.0 の欄は値がありません。CISA の SSVC の記録（10/23）では、悪用は none、自動化は yes、技術的影響は total です。
EPSS は 0.42%（10/31 時点、百分位 0.36）で、悪用の報告は見つかっておらず、KEV 掲載もなしです。
勧告の公開は 9/30 UTC（10/22 に更新）で、NVD への CVE の公開は 10/22 です。この間の経緯は未確認です。
実際の環境での再現は確認していません。記載は勧告、NVD、修正の PR に基づきます。