better-authの脆弱性、OAuthのstateをMagic Linkとして使われ他人としてサインインされるおそれ（CVE-2026-114607、修正は1.7.7）

攻撃者は、ねらった相手のメールアドレスで社外のOAuthサインインを始め、返ってきたstateの値を、そのアドレスのMagic Linkサインインの確認に送ります。better-authは、OAuthのstateとMagic Linkのトークンを同じ保存先に同じ識別子で記録していたため、Magic Linkの処理が両者を区別できませんでした。結果として、攻撃者はメールを受け取れることを証明しないまま、その利用者としてサインインできます。[1]

深刻度は、CVEの採番機関であるGitHub（GitHub_M）の評価でCVSS 3.1の9.1（緊急）です。この問題には、VulnCheckが別にCVE-2026-110862を採番し、CVSS 4.0で9.3（緊急）と評価しています。弱点の分類はCWE-287（不適切な認証）です。[1][3][4]

アドバイザリは、次がすべて当てはまる構成を対象としています。独自のハッシュ関数を使っている場合は、Magic LinkとOAuthのstateが同じ保存値にならないかを確かめます。

• better-authが1.4.0-beta.18以上、1.7.7未満である。[1]
• Magic Linkプラグインが有効で、トークンの保存が既定のstoreToken: "plain"、または"hashed"かつ全体のverification.storeIdentifierも"hashed"になっている。[1]
• 組み込みのソーシャルログイン、またはGeneric OAuthが有効である。[1]
• OAuthのstateをデータベースに保存している（account.storeStateStrategy: "database"。データベースまたはセカンダリストレージを設定したときの既定）。stateをCookieに保存している場合、この経路は塞がれます（ただし後述のOAuth Proxyの条件に注意）。[1]

対象の場合、認証していない攻撃者が、相手のメールアドレスを知っているだけでその利用者のセッションを得て、アカウントの権限をすべて使えます。メールボックスやOAuth提供元へのアクセスは要りません。Magic Linkでの新規登録が有効で、そのアドレスの利用者がまだいなければ、「メール確認済み」と誤って記録されたアカウントを作られます。確認済みのメールアドレスやドメインを信頼して権限を与えるアプリでは、影響が広がります。[1]

2026年11月1日時点で、米国のCISAが公開している「悪用が確認された脆弱性の一覧（KEV）」には載っていません。

今後30日以内に悪用される確率の推定値（EPSS）は0.4%です（2026-11-01時点）。見込みは高くない部類ですが、推定値で、悪用されないことを保証するものではありません。

アドバイザリに再現用のコード（PoC）の公開はありません。KEVには載っておらず、実際の悪用の報告もありません。[1]

修正版は1.7.7です。1.4.0-beta.18以上1.7.7未満が影響を受けます。配布元（npm）で公開済みの版で、確認日は2026年11月1日です。1.7.7はアドバイザリと同じ2026年10月1日（日本時間）にnpmで公開されています（アドバイザリ本文には公表時点で未公開とありますが、収録までに公開されました）。更新の前に、提供元のリリースノートで変更点を確かめてください。[1][7][8]

1.7.7は、今回のMagic Linkの問題と同時に、OAuth Proxyで別人としてサインインできる問題（高）も直しています。[1][8][10]

1. 使っている版と、どのパッケージが連れてきているかを確認します。依存はpackage-lock.json・yarn.lock・pnpm-lock.yamlにも記録されています。

   ターミナル

   npm ls better-auth

2. 対象の構成かを設定で確かめます。Magic Linkの指定、storeToken、verification.storeIdentifier、account.storeStateStrategyの指定を探します（指定が無ければ既定値で判断します）。

   ターミナル

   grep -rn -E "magicLink|storeToken|storeStateStrategy|storeIdentifier" --include="*.ts" --include="*.js" .

3. 1.7.7以上へ更新します。別に入れている@better-auth/のアダプター・プラグインも同じ版にそろえます。

   ターミナル

   npm install better-auth@1.7.7

4. 間接依存で入っている場合は、package.jsonのoverridesで版を固定して入れ直します（yarnはresolutions、pnpmはpnpm.overrides）。

   package.json

   "overrides": {
     "better-auth": "1.7.7"
   }

5. 更新後の版を確かめます。更新すると既存のMagic Linkと途中のサインインは無効になるため、利用者への案内も用意します。

   ターミナル

   npm ls better-auth

更新できるまでの間は、アドバイザリが挙げる次のいずれかで緩和します。[1]

• account.storeStateStrategyを"cookie"にする。OAuth Proxyを使う場合は、先に各環境の全体用の秘密鍵とは別の専用secretを、関係するすべての環境に設定します（共有したままだと別の乗っ取り経路が開きます）。[1]
• Magic LinkのstoreTokenを"hashed"にし、全体のverification.storeIdentifierは未設定か"plain"にする。[1]
• Magic Link、またはソーシャル・Generic OAuthのサインインを止める。[1]

Magic LinkのdisableSignUp: trueだけでは足りません。新しい確認済みアカウントの作成は止まりますが、既存アカウントの乗っ取りは防げません。[1]

更新すると、それまでに発行したMagic Linkと、処理の途中だったOAuthサインインのstate・SAMLの途中状態は使えなくなります。利用者はサインインやアカウント連携をやり直すことになります。データベースのスキーマ移行は要りません。[1][8]

別に入れている@better-auth/のアダプター・プラグイン（例：@better-auth/drizzle-adapter）は、本体と同じ版にそろえて更新します。検証用の保存先を共有する複数のサーバーや、OAuth Proxyに参加するすべての環境（本番・プレビュー・開発）は、同じタイミングで切り替えます。混在すると途中状態をやり取りできません。[1][8]

1.6系から上げる場合は、1.7系で入った設定・スキーマの変更（アカウントのissuer必須化、Generic OAuthの書き換え、OIDC/MCPプラグインの分離など）があります。1.7系に修正版が出ているため、1.6系に留まったままの対処はありません。提供元の1.7アップグレード手順に沿って進めます。[9]

脆弱性の公表・更新一覧で、JavaScript / TypeScriptの関連情報を調べることもできます。