better-authに発見された重大な脆弱性とは？

認証ライブラリ`better-auth`のOAuth自動リンク機能に、アカウント乗っ取りを可能にする重大な脆弱性（GHSA-g38m-r43w-p2q7 / CVE-2026-53516）が報告されました。この脆弱性は、攻撃者が事前に登録したアカウントに、被害者のOAuth認証情報を紐付けさせることで、被害者のアカウントを乗っ取ることを可能にします。

これは、2023年のMicrosoft「nOAuth」や2020年の「Sign in with Apple」のJWT欠陥と同種のもので、『事前アカウント乗っ取り（Pre-account hijacking）』と呼ばれるカテゴリに分類されます。

脆弱性の詳細と攻撃シナリオ

この脆弱性は、`better-auth`のOAuthコールバックにおける自動リンク処理`handleOAuthUserInfo`に存在します。通常、OAuthプロバイダがメールアドレスを検証済み（`email_verified: true`）と主張する場合、`better-auth`はローカルデータベース上のユーザーアカウントにそのOAuth情報を自動的にリンクします。

問題は、この自動リンクの際に、ローカルデータベース上のユーザーアカウントの`emailVerified`フィールド（つまり、`better-auth`が独自にメールアドレスの検証を行ったか）が`true`であるかを適切にチェックしていなかった点にあります。

具体的な攻撃シナリオは以下の通りです。

1. 攻撃者が、被害者のメールアドレスを使って`better-auth`アプリケーションにサインアップします（例: `/sign-up/email`）。この時、通常はメールアドレスの検証が行われるまでは`emailVerified: false`の状態です。

2. 次に、被害者自身がそのメールアドレスで、設定されているOAuth/SSOプロバイダ（Google, GitHubなど）を通じてログインを試みます。

3. `better-auth`は、OAuthプロバイダからの`email_verified: true`という情報のみを信用し、ローカルの`emailVerified`が`false`であるにも関わらず、攻撃者が作成したアカウント（被害者のメールアドレスが登録されている）に被害者のOAuth情報を自動的にリンクしてしまいます。

4. このリンク処理の際、ローカルの`emailVerified`フラグが`true`に更新されてしまいます。これにより、攻撃者は被害者のOAuthアカウントにアクセスできるだけでなく、攻撃者が設定したパスワードを使って、`better-auth`のパスワードログイン機能からもアカウントにアクセスできるようになります。`emailAndPassword.requireEmailVerification: true`が設定されていても、この脆弱性によってバイパスされてしまいます。

あなたのアプリケーションは影響を受けますか？

以下の全ての条件を満たす場合、あなたのアプリケーションはこの脆弱性の影響を受けます。

1. `better-auth`のバージョンが`1.6.11`未満であるか、または`next`プリリリース版を使用している。

2. `betterAuth({ ... })`の設定で`emailAndPassword.enabled: true`が有効になっている。

3. 少なくとも1つのOAuthまたはSSOプロバイダ（組み込みのソーシャルプロバイダ、`genericOAuth(...)`、または`@better-auth/sso`経由のプロバイダ）が設定されている。

4. `account.accountLinking.disableImplicitLinking`が`true`に設定されていない。

5. `account.accountLinking.enabled`が`false`に設定されていない。

今すぐ取るべき対策

最も推奨される対策は、**`better-auth@1.6.11`以降のバージョンへアップグレードすること**です。このバージョンでは、暗黙的なリンクを行う際に、ローカルユーザーの`emailVerified`が`false`である場合にはリンクを拒否するよう修正されています。

新しい設定項目として`account.accountLinking.requireLocalEmailVerified`が追加され、デフォルトで`true`になっています。これにより、ローカルでメール検証が行われていないアカウントへのOAuthリンクがブロックされます。もし、OAuth経由でサインアップするユーザーのメールアドレス検証を`better-auth`側で必須としたくない場合は、このオプションを`false`に設定できますが、これは一時的なオプションであり、将来のバージョンで削除される予定です。

緊急時の回避策（アップグレードが困難な場合）

直ちにアップグレードができない場合は、以下のいずれかの設定変更で脆弱性を軽減できます。ただし、これらの回避策はユーザーエクスペリエンスに影響を与える可能性があります。

1. **暗黙的なリンクを無効にする**: `account.accountLinking.disableImplicitLinking: true`を設定します。これにより、アカウントリンクは、ユーザーが既にログインしている状態で明示的に`/link-social`エンドポイントを使用した場合のみ許可されるようになります。

2. **アカウントリンク自体を完全に無効にする**: `account.accountLinking.enabled: false`を設定します。これは脆弱性を完全に防ぎますが、ユーザーが複数のログイン方法（パスワードとOAuthなど）を同じアカウントに紐付ける機能を失います。

注: `emailAndPassword.requireEmailVerification: true`の設定だけでは、攻撃者が乗っ取った後に`emailVerified`が`true`に昇格してしまうため、この脆弱性に対する有効な対策とはなりません。

まとめ

`better-auth`におけるこの脆弱性は、ユーザーのアカウント乗っ取りに直結する非常に危険なものです。開発者の皆様は、影響を受ける条件を確認し、速やかにバージョンアップや回避策の適用を検討してください。

セキュリティは継続的な取り組みです。利用しているライブラリの脆弱性情報を常にチェックし、最新の状態に保つことが重要です。