2026年8月11日、TypeScript向けのオープンソース認証フレームワーク Better Auth のSSOプラグイン（npmパッケージ @better-auth/sso）に、CVSS 8.1（High）の脆弱性が公表されました（GHSA-8c5h-wx78-2cfg）。攻撃者が自分の管理していないドメインを「所有している」と認証基盤に信じ込ませられる欠陥で、成立すると既存アカウントに攻撃者のSSO IDを紐づけたり、無関係の利用者を攻撃者の組織に加入させたりできます。修正版は @better-auth/sso 1.6.27（および1.7.0-rc.5）です。JPCERT/CCも8月13日のWeekly Reportで取り上げました。
情シスにとっての要点は、「Better Authという製品を導入した覚えがない」ままで該当しうることです。これは製品として購入・契約するものではなく、自社（または委託先）が開発したWebアプリのコードに埋め込まれる部品で、資産管理台帳には「自社開発システム」としか載りません。
この記事でわかること
- Better Authとは何で、自社のどこで動いている可能性があるか
- 2026年8月11日に公表されたSSOドメイン所有権の欠陥の中身
- 該当判定の手順と、本体パッケージだけ更新しても直らない理由
- 一部の脆弱性がCVE番号を持たず、脆弱性スキャナに出てこない構造
Better Authとは何者か
Better Authとは、TypeScript／JavaScriptで書かれたWebアプリケーションに認証・認可の機能を組み込むための、オープンソースのフレームワークです（MITライセンス）。
- 何をするものか：メール／パスワード認証、ソーシャルログイン、2要素認証、パスキー、セッション管理などを、アプリのサーバ側コードとして実装するライブラリです。
- 誰が・どんな場面で使うか：Microsoft Entra IDやOktaのような外部のIDaaSを契約して使うのではなく、自社アプリの中に認証機能を自前で持つときに開発チームが選びます。Next.js等で作る社内業務アプリ、顧客向けSaaS、管理ポータルが典型です。
- どこに組み込まれているか：単体製品として導入されるものではなく、自社や委託先が開発したWebアプリの
package.jsonに書かれている形で存在します。npmの週間ダウンロード数は本体better-authが約641万（2026年8月3日〜9日）。プラグインも@better-auth/passkey約81万、@better-auth/oauth-provider約72万、@better-auth/sso約55万と、それぞれ相応の規模があります。
つまり「うちはBetter Authを使っていない」と即断できるのは、自社でも委託でもNode.js／TypeScriptのWebアプリを一切作っていない場合だけです。心当たりがあるなら、後述の手順でリポジトリを確認してください。
そして本記事で扱う欠陥の重いものは、いずれもSSO・SCIM・組織管理といった「エンタープライズ向けプラグイン」側にあります。裏を返すと、内製アプリを自社IdPとSAML／OIDCで連携させたり、SCIMでユーザーを自動プロビジョニングしたりしている場合ほど影響が大きいという、情シス直結の話になります。
何が起きたのか：SSOのドメイン所有権が崩れる
どんな脆弱性ですか？ SSOプロバイダに登録されたドメインの所有権確認が2通りの経路で回避でき、アカウント乗っ取りや不正な組織加入につながる欠陥です。
@better-auth/sso は、SSOプロバイダに登録されたドメインを見て「このプロバイダは、そのドメインのメールアドレスを持つ利用者を代表してよいか」を判断します。ここが2つの経路で崩れました。
経路1：ドメイン検証が無効なら、未検証のまま組織に加入させられる
ドメイン検証を無効にしている場合、組織の自動割り当て処理は「プロバイダのドメインが検証済みであること」を要求しません。認証済みの組織オーナー／管理者は任意のドメインでSSOプロバイダを登録できるため、攻撃者が被害者のドメインを主張して登録しておくと、そのドメインのメールアドレスを持つ利用者がソーシャルログインでサインインしたときに、SSOプラグインがメールドメインとプロバイダを突き合わせ、攻撃者の組織に既定ロールのメンバーとして追加されます。
アドバイザリはこれを、「プロバイダのレコードを支配していること」と「そのドメインを支配していること」の混同だと説明しています。認証設計の考え方としてそのまま他製品にも当てはまる指摘です。
経路2：DNS確認の待ち時間にドメインをすり替える（TOCTOU）
ドメイン検証を有効にしていても回避できます。検証エンドポイントは非同期のDNS参照を始める前にプロバイダとドメインを読み込む設計でした。参照が完了するまでの間に、プロバイダ更新エンドポイントでドメインを別のものに書き換えられます。
攻撃者は自分が支配するドメインで検証を開始し、DNS解決を待っている間に被害者のドメインへ差し替える。参照が完了すると被害者ドメインが「検証済み」として記録される、という流れです。CWE-367（TOCTOU競合状態）に分類されています。こちらは被害者側の操作を一切必要とせず、攻撃者がプロバイダのオーナー権限を持っていれば成立します。成立すると攻撃者が支配するSSO IDを既存アカウントに紐づけられ、そのアカウントで見えるデータと操作が攻撃者に渡ります。
| 項目 | 内容 |
|---|---|
| アドバイザリ | GHSA-8c5h-wx78-2cfg（CVE番号なし） |
| 公表日 | 2026年8月11日 |
| 対象 | npm @better-auth/sso |
| 深刻度 | High（CVSS v3.1 基本値 8.1） |
| ベクタ | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-287（不適切な認証）／CWE-345（データ真正性の検証不備）／CWE-367（TOCTOU）／CWE-862（認可の欠如） |
| 影響バージョン | 1.4.8-beta.1以上1.4.8未満／1.4.9以上1.6.26以下／1.7.0-beta.0以上1.7.0-rc.4以下 |
| 修正版 | 1.4.8／1.6.27／1.7.0-rc.5 |
すぐに更新できない場合の回避策として、アドバイザリは次を挙げています。
- 信頼できない利用者が
/sso/register、/sso/update-provider、/sso/verify-domainを呼べないようゲートを設ける account.accountLinking.disableImplicitLinking: trueを設定するorganizationProvisioning.disabled: trueを設定する- 既存のプロバイダレコードを棚卸しし、信頼できないドメイン主張を削除する
8月の1件だけの話ではない
GitHubのリポジトリアドバイザリを全件取得すると、2024年12月以降で32件、うち2026年5月31日〜8月11日の約2か月半に18件が集中しています。開発元は2026年6月2日のブログで、報告のトリアージ・重点的なコード査読・自動／手動スキャン・バリアント分析・パッチ査読・リリース調整・アドバイザリ公開を担う専任のセキュリティレビュー体制を立ち上げたと説明しており、この集中はその成果の公表と読むのが自然です。放置されていた製品というより、まとめて棚卸しが行われた製品と見るべきでしょう。
直近で深刻度が高いものを抜き出します。
| アドバイザリ／CVE | 対象 | CVSS | 概要 | 修正版 |
|---|---|---|---|---|
| GHSA-rjg6-39jm-rgg4／なし | @better-auth/scim |
9.9 Critical | SCIMとSSO/SAML/OIDCが同じプロバイダID空間を共有。認証済み利用者が他プロバイダのIDでSCIMトークンを発行でき、無関係のユーザーを一覧・更新・削除できる | 1.6.22 |
| GHSA-5rr4-8452-hf4v／CVE-2026-53513 | @better-auth/sso |
9.6 Critical | プロバイダ登録時にOIDCエンドポイントを検証せずSSRF | 1.6.11 |
| GHSA-9h47-pqcx-hjr4／CVE-2026-67336 | better-auth |
8.7 High | 旧 oidcProvider／mcp プラグインの既定が安全でない。ディスカバリ文書が署名アルゴリズム none を掲載し、PKCEの plain を既定で受理 |
1.6.11 |
| GHSA-qq9h-g4jm-xgf3／CVE-2026-67327 | better-auth |
8.3 High | マジックリンク／メールOTPのサインインで事前アカウント乗っ取り | 1.6.22 |
| GHSA-g38m-r43w-p2q7／CVE-2026-53516 | better-auth |
8.3 High | OAuthの暗黙リンクによる事前アカウント乗っ取り（nOAuth系） | 1.6.11 |
| GHSA-prpr-5gj3-qqhg／なし | @better-auth/sso |
8.1 High | アカウント乗っ取りに至る4つの欠陥。SAMLアサーションの AudienceRestriction／Recipient／Destination を検証していない等 |
1.6.21 |
SCIMの9.9は「退職者が消えない」話でもある
最も重い @better-auth/scim のCVSS 9.9は、プロバイダID衝突が主軸ですが、アドバイザリには併せて「SCIMの active: false がモデル化されておらず、IdP側は成功応答を受け取るのに利用者は有効なまま残った」と記載されています。SCIM連携を「退職・異動時のアカウント無効化の自動化」として運用に組み込んでいる場合、想定していた退職者ロックが実際には効いていなかった可能性がある、という読み方になります。
もうひとつ、GHSA-prpr-5gj3-qqhgに含まれるSAMLアサーションの宛先未検証も見逃せません。1つのIdPが複数のサービスプロバイダを束ねている構成では、他のサービス宛てに発行された署名済みアサーションがそのまま受理されます。攻撃者は署名鍵を必要としません。自社IdPを複数の内製アプリに繋いでいるほど当てはまる話です。
自社が該当するかをどう確かめるか
① パッケージが入っているか
リポジトリで次を確認します。package.json とロックファイル（package-lock.json／pnpm-lock.yaml／yarn.lock）に better-auth または @better-auth/ を含む行があれば該当候補です。
npm ls better-auth @better-auth/sso @better-auth/scim @better-auth/oauth-provider @better-auth/stripe @better-auth/passkey委託開発の場合は、開発ベンダーに同じ確認を依頼してください。ここは情シス単独では確認できない領域なので、依頼の文面にパッケージ名をそのまま書いて渡すのが確実です。
② 本体だけ上げても直らない
Better Authはプラグインが別々のnpmパッケージとして配布されています。開発元も6月のブログで「トップレベルの better-auth だけでなく、直接インストールしているBetter Authのパッケージをすべて更新すること」と明記しています。better-auth を最新にしても @better-auth/sso が古いままなら、今回の欠陥は残ります。
執筆時点の最新は各パッケージとも1.6.29（2026年8月14日公開）で、今回の修正（1.6.27）を含みます。
③ 1.4系に留まっていると修正版が示されていない
@better-auth/sso には release-1.4 というdist-tagがあり、その最新は1.4.22（2026年3月16日公開）です。GHSA-8c5h-wx78-2cfgの影響範囲「1.4.9以上1.6.26以下」は、この1.4.22を含みます。一方でアドバイザリが挙げる修正版は1.4.8／1.6.27／1.7.0-rc.5の3つで、1.4.9以降の1.4系に対する修正版は示されていません。
つまり1.4系で運用を固定している場合、これは「パッチを当てる」作業ではなく1.6.27以降への移行として計画する必要があります。マイナーバージョンをまたぐぶん互換性検証が要るので、工数の見積もりが変わります。
④ SSO／SCIMを繋いでいるか
今回もっとも重い欠陥はSSOとSCIMのプラグイン側にあります。内製アプリを自社IdPとSAML／OIDCで連携している、あるいはSCIMでユーザーを自動プロビジョニングしているなら優先度は上がります。逆にこれらのプラグインを導入していなければ、本記事の主題である8c5hの影響は受けません（ただし本体側の欠陥は別途確認が必要です）。
脆弱性スキャナが鳴らない可能性がある
ツールが何も言っていないから大丈夫、と言えますか？ 本件については言えません。公開状況を各データベースに直接照会した結果は次のとおりです（2026年8月16日時点）。
| 参照先 | 照会時点の状態 | 実務への影響 |
|---|---|---|
| GitHubのリポジトリ内アドバイザリ | 32件すべて公開 | リポジトリのSecurityタブを直接見れば分かる |
| GitHub Global Advisory Database | GHSA-8c5h-wx78-2cfg と GHSA-prpr-5gj3-qqhg が未収載（API照会で404） | Dependabot／npm audit が反応しない |
| OSV.dev | 同じ2件が未登録（404） | OSV-Scanner・Trivy・Grype等が反応しない |
| CVE番号 | 上記2件に加え、CVSS 9.9のGHSA-rjg6-39jm-rgg4にもCVE番号が無い | CVE番号ベースの管理台帳・報告フォーマットに載せられない |
| NVD | CVE-2026-67327・CVE-2026-67336等は2026年8月1日に登録されたが、状態は Received（未解析）でCPEの構成情報が0件 | SBOMとCPEを突き合わせる方式のツールが製品に紐づけられない |
整理すると、CVE番号で追う運用でも、SCAツールに任せる運用でも、今回もっとも重い部分が取りこぼされうるということです。しかも取りこぼされるのは軽微なものではなく、CVSS 9.9のSCIMと8.1のSSO乗っ取り2件という逆転が起きています。CVSSスコアで対応順を決めている組織ほど、スコアが付与されていないがゆえに検討の土俵にすら上がりません。
CVE番号の有無は「危険度」ではなく採番の事務手続きの進み具合を反映しているにすぎない、ということです。実際、5月31日公表分の多くは約2か月後の8月1日にまとめて採番されており、その時点でもNVD側の解析は済んでいません。
現場目線の課題
正直なところ、この種のネタは情シスにとって一番動きにくい部類です。脆弱性の所在が「自社で買った製品」ではなく「自社で作ったアプリの中身」にあるため、確認するにも直すにも開発チームか委託先を動かす必要があります。資産管理ツールのインストール済みソフト一覧をどれだけ眺めても @better-auth/sso は出てきません。しかも認証まわりのライブラリ更新は回帰試験の範囲が広く、「動いているから触らない」が最も起きやすい場所です。
それでも、SSOやSCIMを自社IdPに繋いだ時点で、そのアプリは「開発部門の持ち物」から「全社のID基盤の一部」に変わっています。IdPと繋いだ内製アプリの一覧と、その依存関係を誰が見ているのかを把握しておくこと自体が、今回の一番の打ち手だと考えます。個々のCVEを追う前に、まずその名簿を作るほうが効きます。
情シスはどうすべきか
自前でチェックリストを増やすより、公的機関の指針を軸に開発ベンダーと共通言語を持つほうが早く進みます。
- IPA「安全なウェブサイトの作り方」 … セッション管理・認証まわりの設計上の注意がまとまっています。委託仕様書やレビュー観点にそのまま使えます。
- IPA「中小企業の情報セキュリティ対策ガイドライン」 … 開発を外部に出している組織ほど、委託先の脆弱性対応の取り決めが効いてきます。
- IPA「対策のしおり」 … アカウント乗っ取り系のリスクを非技術部門に説明する際の材料になります。
SSOそのものの仕組みや運用上の勘所はSSO（シングルサインオン）とは？仕組みと運用の勘所で解説しています。認証プラグイン側の欠陥という点ではWordPress SSOプラグインに認証回避の脆弱性、同じJavaScriptエコシステムの事例としてはNext.jsに9件の脆弱性、認証回避やSSRF、OSS部品の棚卸しという観点ではBouncy Castleに脆弱性22件 証明書検証に欠陥も併せてご覧ください。
まとめ
- 2026年8月11日、
@better-auth/ssoにドメイン所有権の検証を回避できる脆弱性（CVSS 8.1）が公表されました。修正版は1.6.27（最新は1.6.29）。直近2か月半で18件のアドバイザリが集中しており、最も重いのは@better-auth/scimのCVSS 9.9です。 - 該当判定は製品名ではなくリポジトリの依存関係で行います。本体
better-authだけを更新してもプラグインは直りません。1.4系には修正版が示されておらず、1.6.27以降への移行が必要です。 - もっとも重い3件はCVE番号を持たず、うち2件はGitHub Global Advisory DatabaseにもOSV.devにも未登録です。Dependabotや
npm auditが沈黙していることは、安全である根拠になりません。
出典
- GHSA-8c5h-wx78-2cfg: SSO domain ownership flaws can enable account takeover and unauthorized organization membership
- GHSA-rjg6-39jm-rgg4: @better-auth/scim account takeover and stale access via SCIM provider-id collision
- GHSA-prpr-5gj3-qqhg: @better-auth/sso account takeover via multiple SSO flaws
- better-auth/better-auth Security Advisories（全件一覧）
- Better Auth 公式ブログ「Security update: June 2026」（2026年6月2日）
- JPCERT/CC Weekly Report 2026-08-13【14】Better Authに複数の脆弱性
- NVD: CVE-2026-67327／CVE-2026-53513
- IPA「安全なウェブサイトの作り方」
※本記事のダウンロード数・バージョン公開日・各データベースへの登録状況は、2026年8月16日時点でnpmレジストリおよび各データベースのAPIに直接照会した結果に基づきます。
