2026年10月、JavaScript／TypeScriptでWebサービスのログイン機能を作るための部品「Better Auth（ベターオース）」に、他人のアカウントにログインできてしまう脆弱性（＝システムの安全上の欠陥）が公表されました。深刻度はCVSSで9.1〜9.3（緊急）と評価されています。Better Authは、週に約1,700万回ダウンロードされている人気の部品です。
「うちの会員サイトはNext.jsで作ってもらった。ログイン部分に何を使っているかなんて知らないけど、関係あるの？」
先に結論をお伝えします。影響を受けるのは、Better Authを使い、「メールのリンクでログイン（マジックリンク）」と「Googleなど外部アカウントでログイン」の両方を有効にしているサービスです。修正版（1.7.7以降）はすでに出ています。まずは、ログイン機能にBetter Authを使っているか、使っているならバージョンと設定を、開発会社に確認しましょう。
この記事では、公式の情報をもとに何が問題なのかを整理し、発注者が開発会社に確認したいことを、チェックリストと質問例つきで解説します（内容は2026年10月30日時点の情報に基づきます）。
Better Authの脆弱性、公式情報の要点
この脆弱性は、Better Authの開発元がGitHub上で公開したセキュリティ情報（アドバイザリ）と、CVEの公式記録で公表されています。同じ問題に、2つのCVE番号が付いています。
| 項目 | 公式情報の内容 |
|---|---|
| 対象 | Better Auth（npmの部品名 better-auth）。TypeScriptでログイン・認証の機能を作るための部品 |
| 起きること | 攻撃者が、相手のメールアドレスさえ分かれば、メールを受け取らずにその人としてログインできる。アカウントが無い場合は「メール確認済み」の偽アカウントを作られるおそれもある |
| 攻撃する側の条件 | ログインしていない第三者でも可能 |
| 影響を受ける条件 | ①マジックリンク（メールのリンクでログインする機能）が有効 ②Googleなど外部アカウントでのログイン（OAuth）が有効 ③ログインの途中の情報をデータベースに保存する設定（データベースを使っている場合の初期設定）——がすべてそろっている場合 |
| 影響を受けるバージョン | 1.4.0-beta.18以上、1.7.7未満 |
| 修正版 | 1.7.7以降（npmでは2026年9月30日に公開。10月30日時点の最新は1.7.14） |
| 深刻度 | CVSS v4.0 で 9.3（CVE-2026-110862）／CVSS v3.1 で 9.1（CVE-2026-114607）。いずれも緊急 |
📰 出典：npm「better-auth」（各バージョンの公開日）
修正版の1.7.7は、脆弱性が公表される前の9月30日に公開されていました。つまり、10月に入ってから最新版に更新しているサービスは、すでに修正が入っている可能性があります。一方、長く更新していないサービスや、1.4系・1.6系など古い系列を使い続けているサービスは、影響を受ける範囲に入ります。
執筆時点で、米国CISAの「実際に悪用が確認された脆弱性」の一覧（KEV）には載っておらず、悪用の公式な報告はありません。
CVE番号やCVSSの点数の読み方は、次の記事で解説しています。
どんなサービスが影響を受けるのか
ログイン機能に「Better Auth」を使っているか
Better Authは、Next.jsやNuxtなど、JavaScript／TypeScriptで作るWebサービスで、会員登録やログインの機能を作るために使われる部品です。発注者からは、どの部品を使っているかは見えないので、開発会社に確認する必要があります。
「メールでログイン」と「外部アカウントでログイン」の両方があるか
今回の問題は、次の2つのログイン方法を両方とも有効にしている場合に起きます。
| ログイン方法 | 画面の例 |
|---|---|
| マジックリンク | 「メールアドレスを入力すると、ログイン用のリンクが届く」方式 |
| 外部アカウント（OAuth） | 「Googleでログイン」「GitHubでログイン」などのボタン |
どちらか一方だけなら、今回の条件には当てはまりません。ただし、細かい設定によって条件が変わるため、最終的には開発会社に確認してください。
似た問題はLaravelでも
ログインの仕組みをすり抜けられる問題は、先日、PHPのフレームワークLaravelでも公表されています。部品やフレームワークの「ログイン機能」は、問題があったときの影響が大きい部分です。
発注者にとって何が変わるか／変わらないか
ここからは、公式情報をもとにした筆者の見解です。
変わらないこと：今すぐサービスを止める段階ではない
修正版はすでに出ており、悪用の公式な報告もありません。対象のサービスでも、修正版への更新が対応の中心になります。
変わること1：対象なら、修正版への更新を急ぐ
対象になる場合、攻撃者は会員のメールアドレスを知っているだけで、その会員としてログインできてしまいます。会員の個人情報や購入履歴、管理者の権限などがあるサービスでは、情報漏えいや不正な操作につながりかねません。対象と分かったら、通常の定期メンテナンスを待たず、1.7.7以降（できれば最新版）への更新を開発会社と相談しましょう。
開発元は、更新するまでの回避策として、ログインの途中の情報をCookieに保存する設定に変える、マジックリンクか外部アカウントのログインのどちらかを止める、などを挙げています。ただし、設定によっては別の注意点があるため、どの回避策を使うかは開発会社に判断してもらいましょう。なお、開発元は「新規登録を止めるだけでは、既存のアカウントの乗っ取りは防げない」としています。
変わること2：更新後に、ログインのやり直しが必要になる
開発元によると、更新前に送ったログイン用のリンクや、途中だったログインは、更新後は使えなくなります。利用者にとっては「届いたリンクが使えない」ことになるので、更新のタイミングや、問い合わせへの案内を開発会社と決めておくと安心です。また、更新までの間に、身に覚えのないログインや、不自然な「メール確認済み」のアカウントが作られていないか、記録（ログ）を確認してもらいましょう。
Node.jsで作ったシステムの更新の考え方は、次の記事も参考にしてください。
「『ログインに何の部品を使っているか』『どのログイン方法を用意しているか』は、サービスの設計書に書いてもらっておくと、今回のような脆弱性のときにすぐ判断できます。」
今やるべきこと・まだ様子見でいいこと
| 区分 | 内容 |
|---|---|
| 今やること | 自社のサービスのログイン機能に、Better Authを使っているか開発会社に確認する |
| 今やること | 使っている場合、バージョンと、マジックリンク・外部アカウントのログインを有効にしているかを確認する |
| 対象なら急ぎ | 1.7.7以降（できれば最新版）に更新する。すぐ更新できない場合は、開発元の回避策を開発会社に検討してもらう |
| 対象なら早めに | 身に覚えのないログインや、不自然な「メール確認済み」のアカウントが無いか、記録を確認してもらう |
| 様子見でよい | ログインの仕組みの作り直しの検討（今回の対応が落ち着いてからで遅くありません） |
発注者がやること チェックリスト
- ☐ 自社のサービスのログイン機能に、どの部品を使っているか把握した
- ☐ Better Authを使っている場合、バージョンを確認した
- ☐ マジックリンクと、外部アカウント（Googleなど）のログインを有効にしているか確認した
- ☐ 対象の場合、1.7.7以降への更新をいつ行うか決めた
- ☐ 更新前に送ったログイン用リンクが使えなくなることへの、利用者への案内を決めた
- ☐ 身に覚えのないログインや不自然なアカウントが無いか、記録の確認を依頼した
開発会社への質問例
- 「当社のサービスのログイン機能には、どの部品を使っていますか？Better Authですか？」
- 「Better Authを使っている場合、バージョンはいくつですか？1.7.7以降に更新されていますか？」
- 「メールのリンクでログインする機能と、Googleなどでログインする機能は、両方とも有効になっていますか？」
- 「対象になる場合、いつ更新できますか？更新までの間の回避策はありますか？」
- 「更新前に、身に覚えのないログインや不自然なアカウントの作成がなかったか、記録で確認できますか？」
まとめ
ログイン機能の部品「Better Auth」に、メールアドレスを知っているだけで他人としてログインできるおそれのある脆弱性（CVE-2026-110862／114607、CVSSで9.1〜9.3）が公表されました。対象は、マジックリンクと外部アカウントのログインを両方有効にしているサービスで、修正版の1.7.7以降はすでに出ています。
発注者がやるべきことは、ログイン機能にBetter Authを使っているか、使っているならバージョンとログイン方法の設定を開発会社に確認し、対象なら更新を急ぐことです。更新後にログイン用リンクが使えなくなることへの案内や、不審なログインの確認もあわせて相談しましょう。
あわせて読みたい関連記事
