better-auth 脆弱性が2026年6〜7月、SCIM/OAuth連携で相次いで公開された。GitHub Organization「better-auth」が開発するTypeScript製認証フレームワーク（⭐29,422）のこの領域に、所有権の検証漏れに起因するGHSA（GitHub Security Advisory）が4件見つかっている。最も深刻なGHSA-rjg6-39jm-rgg4はCVSS 9.9で、企業向けSCIMプロビジョニングを有効化した瞬間にだけ開く「このIDは誰のものか」という検証漏れが共通の原因になっている。この記事はbetter-auth脆弱性の中身と、自分の環境が該当するかを判定する確認コマンドを整理する。

この記事はサプライチェーン全体の防御を扱うサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストの個別事例として、better-authのSCIM/OAuth関連GHSA4件に絞って扱う。

better-auth SCIM/OAuthクラスタの公開タイムライン。2026-07-07にSCIM関連GHSA、07-23にv1.6.25リリース、07-24にOAuth自動リンクのGHSA(CVE-2026-53516)、08-02が本記事の実測時点
GHSA公開日はGitHub API実測。better-auth/better-authは高活性リポジトリで、修正版リリースも数日以内に追随している。
30秒でわかる better-auth SCIM/OAuth脆弱性（2026年8月時点）
  • ・正体：better-auth（TypeScript製のOSS認証フレームワーク、MITライセンス、⭐29,422）に、企業向けSCIMプロビジョニングとOAuth自動リンクを足した箇所だけで見つかった所有権検証漏れのクラスタ。
  • ・件数とスコア：GHSA4件。provider-id衝突(CVSS 9.9)・非組織SCIMプロバイダのトークン再発行(8.3)・OAuth自動リンク(8.3・CVE-2026-53516)・削除後セッション残留(3.8)。
  • ・影響条件：SCIMプロビジョニングまたはOAuth自動リンクを有効化しているアプリのみ。メール/パスワード単体の利用は今回の経路の対象外。
  • ・自環境の確認：npm ls better-auth @better-auth/scimでバージョンを両方確認し、grep -rn "accountLinking" .で設定を見る。
  • ・注意：@better-auth/scimは本体と独立してバージョニングされるサブパッケージ。本体だけ見ても脆弱性の有無は判断できない。

better-authとは何か——SCIM/OAuthプロビジョニングで何が変わったか

better-authはTypeScript製のOSS認証フレームワークで、GitHub Organization「better-auth」が開発している。ライセンスはMIT、READMEに「Better Auth is a free and open source project licensed under the MIT License」と明記され、LICENSE.md原文とも一致している。GitHub API実測で⭐29,422・fork 2,761、コミット総数7,143・contributor 400〜500規模、リリース949本（最新安定版はv1.6.25、最新プレリリースはv1.7.0-rc.2）と、star数に見合う実開発量が伴っている高活性リポジトリだ。

better-auth本体はメール/パスワードやOAuthログインといった一般的な認証機能を提供するが、企業向けの導入では@better-auth/scimというサブパッケージを追加することで、Okta・Azure ADのようなIdP（アイデンティティプロバイダ）からのユーザー自動同期（SCIM＝System for Cross-domain Identity Management）を有効化できる。今回の4件のGHSAは、この「SCIMプロバイダーを登録する」「OAuthアカウントを自動リンクする」という、企業向け機能を有効化したときにだけ通る経路に集中している。

SCIM自体はbetter-auth固有の技術ではなく、IETFが標準化したプロトコルで、企業がIdP側で従業員を追加・削除するとSaaS側のアカウントも自動的に追従する仕組みとして広く使われている。IdP側から見れば「どのSCIM プロバイダーが、どのユーザーの同期を担当するか」をIDで管理しており、このIDの一意性が崩れると、同期対象そのものを取り違えるという構造的なリスクを抱える。今回の4件のうち3件はまさにこの「IDの一意性」「所有権の検証」が抜け落ちていた箇所で発生しており、SCIM/OAuthのような外部連携機能を持つ認証フレームワーク全般に共通しうる設計上の論点でもある。

読者の3つの問いへの答え
① 何ができる：better-authはメール/パスワード・OAuth・パスキー等をカバーするTypeScript認証フレームワーク。SCIMを足すと企業IdPからのユーザー自動同期にも対応する ② 何を解決する：認証基盤を自前実装せずに済ませる ③ 何を代替できる：next-auth（Auth.js）等の既存OSS認証ライブラリの選択肢の一つ

better-auth 脆弱性の内訳——4件のGHSA、公開の経緯と深刻度

4件はいずれも「所有権の束縛漏れ」という共通の根本原因で括れるとGHSA側の記載から読み取れる。CVSSスコアは大きく分かれており、深刻度に応じた優先順位付けが必要だ。

4件のGHSAのCVSSスコア比較。GHSA-rjg6が9.9、GHSA-j8v8とGHSA-g38mが8.3、GHSA-2vg6が3.8
スコアはGHSA原文のCVSS値をそのまま使用（丸めなし）。
GHSA 内容 CVSS
GHSA-rjg6-39jm-rgg4 SCIMプロバイダのprovider-id衝突によるアカウント乗っ取り・古いアクセス残留 9.9
GHSA-j8v8-g9cx-5qf4 非組織SCIMプロバイダで所有権バインディングが欠落、アカウント/プロバイダ乗っ取り 8.3
GHSA-g38m-r43w-p2q7（CVE-2026-53516） OAuthの暗黙的（implicit）アカウントリンクによる先回り乗っ取り 8.3
GHSA-2vg6-77g8-24mp ユーザー削除後もセッションが残留 3.8

最も深刻なGHSA-rjg6-39jm-rgg4は、攻撃者が自分の管理下にあるSCIMプロバイダに、被害者組織側のprovider-idと衝突するIDを設定できてしまうという内容だ。次点のGHSA-j8v8-g9cx-5qf4は、組織に所属しない（non-org）SCIMプロバイダに対してもトークンの再発行が可能だった不備、GHSA-g38m-r43w-p2q7はOAuthログイン時の自動アカウントリンクを悪用した先回り乗っ取りを扱う。GHSA-2vg6-77g8-24mpだけは前者3件と性質がやや異なり、ユーザー削除の後処理でセッションが破棄されずに残る不備だ。

なお、better-authは2026年5〜7月にこの4件以外にもSSO・Stripeプラグイン・OAuthプロバイダ関連の複数のGHSAを発行している。この記事はSCIM/OAuthによるアカウント乗っ取り系の4件に対象を絞り、他の脆弱性群は扱わない。

なぜ所有権が検証されないのか——攻撃の仕組み

4件のうち3件（provider-id衝突・非組織プロバイダ・OAuth自動リンク）は、いずれも「同期・リンクする対象が本当に正しい持ち主のものか」を検証しない箇所で発生している。

SCIM/OAuthを有効化した瞬間に開く所有権の穴。SCIM有効化→プロバイダ登録→ユーザー同期→所有権未検証という4段階と、想定されていた前提と実際に起きたことの対比
3件のGHSAに共通する構図。「プロバイダIDは衝突しない」「新規SCIMプロバイダは組織所属」「OAuthリンクは本人操作のみ」という前提が、それぞれ別の箇所で崩れていた。

最も深刻なGHSA-rjg6-39jm-rgg4を例に、GHSA記載の内容を整理する。

flowchart TD A["攻撃者
自分のSCIMプロバイダに
被害者側と同一のprovider-idを設定"] --> B["better-auth
provider-idの一意性を
組織をまたいで検証していない"] B --> C["ID衝突が成立
攻撃者のプロバイダが
被害者の同期対象と一致"] C --> D["同期処理が実行される
アクセス権が攻撃者側に渡る"] D --> E["アカウント乗っ取り
CVSS 9.9"]

SCIMプロバイダーIDは本来、組織内で一意であることを前提に同期処理が組まれる。しかしprovider-idの一意性チェックが組織をまたいだ検証になっていなかったため、攻撃者は自分の管理下にあるSCIMプロバイダに被害者側と衝突するIDを設定するだけで、同期先を乗っ取れる状態になっていた。GHSA-j8v8-g9cx-5qf4も構図は近く、「組織に所属しないSCIMプロバイダはそもそも信頼できないはず」という前提が、トークン再発行の経路では検証されていなかった。GHSA-g38m-r43w-p2q7（CVE-2026-53516）はOAuthログイン時の話で、新規OAuthアカウントを既存のメール/パスワードアカウントへ自動的にリンクする挙動が既定で有効なままだと、攻撃者が被害者のメールアドレスで先にOAuthアカウントを作成し、被害者が後からログインした瞬間にリンクが成立してしまう。

GHSA-2vg6-77g8-24mp（ユーザー削除後のセッション残留、CVSS 3.8）は上記3件とは根本原因が異なる。所有権検証の問題ではなく、削除処理のクリーンアップ漏れなので、対策も別に扱う必要がある。

この3件に共通するのは、「削除」や「新規作成」のような一見単純な操作の裏で、複数のテーブル・複数のプロバイダをまたいだ整合性チェックが必要になるという点だ。SCIMプロバイダーの追加・OAuthアカウントのリンク・ユーザーの削除は、いずれも単一のレコードを触るだけの操作に見えて、実際には「この操作の対象は本当にこのユーザー（またはこの組織）に紐づいているか」という所有権の再確認を伴う。GHSA記載の内容を見る限り、この再確認のロジックが機能ごとにばらつきがあったことが、4件のGHSAという形でまとまって表面化した背景にあると読み取れる。

自分の環境が該当するか——3つの確認コマンド

SCIMやOAuth自動リンクを使っていなければ今回の経路は成立しないが、「使っているかどうか」自体は設定を見ないとわからない場合が多い。特にOAuth自動リンクは多くの認証フレームワークで既定挙動として組み込まれているため、明示的に有効化した記憶がなくても、ソーシャルログインを1つでも導入していれば対象になりうる。以下の3コマンドを順番に実行し、該当有無を機械的に判定する。

自分の環境が該当するか3コマンドで判定するフロー。npm ls→バージョン比較→grep accountLinkingの3段階
①だけでは判定できない。@better-auth/scimは本体と独立してバージョニングされるサブパッケージのため。
# ① better-auth本体と @better-auth/scim を両方確認する（片方だけでは不十分）
npm ls better-auth @better-auth/scim

# ② package.json / lockfile 上のバージョンが 1.6.22 未満、または 1.7.0-beta.10 未満か確認
#    （個別GHSAごとの正確な修正バージョン番号はGHSA原文を参照）

# ③ OAuthの自動アカウントリンク設定を確認（CVE-2026-53516 / GHSA-g38m-r43w-p2q7の対象）
grep -rn "accountLinking" .

③のgrep結果でdisableImplicitLinkingが設定されていない、あるいは自動リンクを許可する設定のままになっている場合は、OAuth側の見直しが必要になる。@better-auth/scimはbetter-auth本体とは別にバージョニングされるサブパッケージという点が今回いちばん見落とされやすい。本体だけ最新化していてもSCIM側が古いままというケースがあり得るため、npm lsでは必ず両方を指定して確認する。

3つのコマンドの結果を組み合わせると、自分の構成が今回のGHSA4件のどれに該当するかが絞り込める。構成ごとの該当有無を整理すると次のようになる。

構成 該当する可能性 理由
@better-auth/scimを導入し、自組織以外のSCIM プロバイダーも許可している 高い GHSA-rjg6・GHSA-j8v8のprovider-id衝突／非組織プロバイダの経路に該当
@better-auth/scimを導入し、SCIM プロバイダーを自組織のみに限定している 中程度 GHSA-j8v8の経路は縮小するが、GHSA-rjg6のID衝突自体は別途確認が必要
OAuthソーシャルログインを使い、accountLinkingが既定（自動リンク有効）のまま 高い GHSA-g38m-r43w-p2q7（CVE-2026-53516）に該当
OAuthログインのみでdisableImplicitLinkingを有効化済み 低い 自動リンクの経路自体が塞がれているため対象外
メール/パスワード認証のみ、SCIM・OAuth自動リンクとも未使用 該当なし 今回の4件が使う同期・リンク経路そのものが存在しない
ユーザー削除機能を使っている GHSA-2vg6のみ該当の可能性 所有権検証とは別系統。削除後のセッション破棄を個別に確認

better-auth 脆弱性への対策とアップデート手順

対策は大きく2段階になる。1段階目はバージョンのアップデート、2段階目は設定変更だ。

・アップデート：better-auth本体・@better-auth/scimともに、GHSAが修正済みとしているバージョン以上へ上げる。本記事執筆時点（2026-08-02）の最新安定版はv1.6.25（2026-07-23公開）で、v1.7.0系はまだrc（プレリリース）段階のため、本番環境には安定版を選ぶのが基本になる
・OAuth自動リンクの設定変更：GHSA-g38m-r43w-p2q7（CVE-2026-53516）はアップデートだけでは終わらない。accountLinkingの設定でdisableImplicitLinkingを有効にするか、プロバイダごとにリンクを許可制へ切り替える必要がある
・SCIMプロバイダの棚卸し：組織に所属しない（non-org）SCIM プロバイダーが登録されていないか確認し、心当たりのないプロバイダーは削除する（GHSA-j8v8-g9cx-5qf4対策）
・provider-idの重複確認：既存のSCIMプロバイダー一覧を洗い出し、他組織と衝突しうるIDを使い回していないか確認する（GHSA-rjg6-39jm-rgg4対策）
・ユーザー削除フローの見直し：GHSA-2vg6-77g8-24mp対策として、ユーザー削除時にセッションも確実に破棄されるか確認する

パッチ適用と設定変更のうち、設定変更（OAuth自動リンクの無効化・SCIMプロバイダーの棚卸し）は既定値の見直しなのでアップデートだけでは自動的に反映されない。両方を実施して初めて対策が完了する。すでに不審なSCIM同期やアカウントリンクの形跡が見つかった場合は、対象アカウントのセッション・APIトークンを無効化した上で、影響範囲の洗い出しを優先するのが一般的な事後対応の流れになる。

認証OSSの比較——next-authの同時期脆弱性との違い

better-authと並んで使われるnext-auth（Auth.js）でも、同時期に別系統の脆弱性が公表されている。両者は原因のレイヤーが異なる。

項目 better-auth next-auth（Auth.js）
ライセンス MIT ISC
⭐ Star数 29,422 28,314
今回の脆弱性の性質 SCIM/OAuthでの所有権検証漏れによるアカウント乗っ取り（最大CVSS 9.9） fail-open型の認可バイパス・Unicode正規化前検証という別系統の脆弱性
影響が及ぶ条件 SCIMプロビジョニングまたはOAuth自動リンクを有効化している場合 認可ロジックの設定に依存

better-auth側は「誰の所有かを検証していない」という所有権の束縛漏れ、next-auth側は「本来拒否すべき状態を許可してしまう」という認可の設計に近い。どちらもフレームワークが企業向け機能や柔軟な設定を提供するために増えた分岐が原因になっている点は共通している。

導入を検討する側にとっての実務上の違いもある。better-authはSCIM/OAuth自動リンクという特定の機能を有効化したときだけリスクが顕在化するため、単純なメール/パスワード認証だけで使っている既存導入への影響は限定的だ。一方でnext-authはNext.js特化という位置づけ上、認可ロジックの設定ミス自体がより広い範囲の実装に及びうる。どちらのOSSを使っている場合でも、「今回の脆弱性がどの機能を有効化したときに顕在化するのか」を個別に確認してから対応の優先度を判断する必要がある。

なお、トークンや認証情報を狙う攻撃全般への多層防御という切り口ではトークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターン、OAuthトークンが窃取される別経路の実例としてはClaude CodeのMCP通信ハイジャックでOAuthトークンが窃取される攻撃｜検知・対応・防御の手順も参考になる。「既定の設定・構成ミスが未認証の攻撃者に深いところまで触らせてしまう」という構図自体は、GitHub Actions pull_request_targetの設計ミス：フォークPRで認証情報が漏洩するCVSS10.0脆弱性とも共通する。

まとめ

better-authは実開発量・活性度ともに規模に見合ったOSSであり、脆弱性そのものは「機能を追加した分だけ検証すべき境界が増える」という、企業向け拡張を持つ認証フレームワークに共通するリスクの表れといえる。SCIMやOAuth自動リンクを使っていない導入であれば今回の経路は成立しないため、まずは自分の構成がどの機能を有効化しているかを洗い出すところから始めるのが実務的な順序だ。

better-authのSCIM/OAuth脆弱性4件は、いずれも「このIDは誰の所有か」を検証しないまま同期・リンクする箇所に集中していた。最も深刻なGHSA-rjg6-39jm-rgg4（CVSS 9.9）はSCIMプロバイダのprovider-id衝突が原因で、企業向けSCIMプロビジョニングを有効化しているアプリが対象になる。まずnpm ls better-auth @better-auth/scimで本体とサブパッケージ両方のバージョンを確認し、grep -rn "accountLinking" .でOAuth自動リンクの設定を見る。アップデートだけでなく、disableImplicitLinkingの設定変更とSCIMプロバイダの棚卸しまで実施して初めて対策が完了する。

参照ソース

・GHSA-rjg6-39jm-rgg4（@better-auth/scim: account takeover and stale access via SCIM provider-id collision, CVSS 9.9） — SCIMプロバイダID衝突による乗っ取りの一次情報
・GHSA-j8v8-g9cx-5qf4（@better-auth/scim: Account/provider takeover via missing owner binding on non-org SCIM providers, CVSS 8.3） — 非組織SCIMプロバイダのトークン再発行不備
・GHSA-2vg6-77g8-24mp（Stale sessions persist after user deletion, CVSS 3.8） — ユーザー削除後のセッション残留
・GHSA-g38m-r43w-p2q7 / CVE-2026-53516（Account takeover via OAuth implicit linking, CVSS 8.3） — OAuth自動リンクによる先回り乗っ取り
・better-auth 公式リポジトリ — star/fork/ライセンス/リリース実測の取得元