next-auth 脆弱性が2026年7月23日、Auth.jsの名称で知られるTypeScript製認証ライブラリ（GitHub Organization「nextauthjs」開発、⭐28,314）で2件同時に公開された。片方のGHSA-8fpg-xm3f-6cx3は「設定にエラーがあるときだけ認可チェックが全リクエストを通してしまう」というfail-open型のバグで、v5のベータ版が対象。もう片方のGHSA-7rqj-j65f-68whは「メールアドレスをUnicode正規化する前にバリデーションしてしまう」順序ミスで、v4系と@auth/coreが対象になる。2件は影響バージョンも根本原因も異なるが、どちらも「エラーが起きるほど守りが緩くなる」という同じ設計思想の裏返しという点で共通する。この記事は2件のGHSAの中身と、自分の環境が該当するかを判定する確認コマンドを整理する。
この記事はサプライチェーン全体の防御を扱うサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストの個別事例として、next-authのfail-open系GHSA2件に絞って扱う。
- ・正体：next-auth（Auth.js、TypeScript製・ISCライセンス・⭐28,314）で見つかった認可バイパス系のGHSA2件。同日（2026-07-23）に公開された。
- ・GHSA-8fpg-xm3f-6cx3：v5ベータ（5.0.0-beta.0〜5.0.0-beta.31）が対象。設定エラー時に認可チェックがfail-openし、全リクエストを通してしまう。
- ・GHSA-7rqj-j65f-68wh：v4系（4.10.3〜4.24.14）または@auth/core（0.1.0〜0.41.2）が対象。メールの正規化前バリデーションでマジックリンクが別人に届く可能性がある。
- ・自環境の確認：
npm ls next-auth @auth/coreでバージョンを両方確認し、影響範囲と照合する。 - ・注意：2件ともGitHub Advisory Database上のseverityは「critical」だが、CVSSの数値スコアは未算出（捏造しない）。
next-auth 脆弱性の正体——next-auth（Auth.js）とは何か、2件のGHSAで何が起きたのか
next-authはNext.js向けに作られたTypeScript製の認証ライブラリで、OAuthログイン・メールマジックリンク・セッション管理までを一括で提供する。GitHub Organization「nextauthjs」が開発している。v5以降はブランド名を「Auth.js」に統合し、フレームワーク非依存のコアロジックを@auth/coreパッケージに切り出した上で、Next.js向けラッパーとしてnext-authパッケージを維持する構成になっている。ライセンスはISCで、LICENSE原文の「ISC License / Copyright (c) 2022-2024, Balázs Orbán」という表記とREADMEの「## License」セクションの記載が一致している。
GitHub API実測（2026-08-02取得）では⭐28,314・fork 4,043、コミット総数3,964・contributor 400〜500規模、リリース1,877本（最新は[email protected]、2026-07-20公開）と、star数に見合う実開発量が伴っている高活性リポジトリだ。pushed_atは2026-07-22で、GHSA公開（07-23）の直前まで開発が動いていたことになる。next-auth本体は2018年創業以来のメジャーライブラリでv4系が長期安定運用中だが、今回のGHSA-8fpg-xm3f-6cx3が影響するのはv5系のベータ版限定という点が最初の見落としどころだ。
① 何ができる：next-auth（Auth.js）はOAuth・メールマジックリンク・クレデンシャル認証等を一括で扱えるTypeScript製認証ライブラリ ② 何を解決する：認証基盤を自前実装せずに済ませる ③ 何を代替できる：better-auth等の既存OSS認証フレームワークの選択肢の一つ
タイムライン：2件のGHSAが同日公開されるまで
next-authのfail-open系GHSA2件は、影響バージョンも原因も異なるが、公表日（開示日）は同じ2026-07-23だった。次の年表はGitHub API・Advisory Databaseの実測に基づく。
| 日付 | 出来事 |
|---|---|
| 2026-07-20 | [email protected] リリース（GHSA-7rqj-j65f-68wh の修正版に相当するバージョン） |
| 2026-07-22 | 最終コミットpush（pushed_at: 2026-07-22T19:42:19Z、GitHub API実測） |
| 2026-07-23 | GHSA-8fpg-xm3f-6cx3・GHSA-7rqj-j65f-68wh が同日公開 |
| 2026-08-02 | 本記事の実測時点（⭐28,314・fork 4,043） |
修正版のリリース（07-20）がGHSA公開（07-23）より前という順序は、公開前に修正版を出してから開示するという一般的な脆弱性対応の流れと矛盾しない。ただしこの記事執筆時点でGHSA-8fpg-xm3f-6cx3側の修正が具体的にどのバージョンで取り込まれたかはGHSA原文に明記が薄く、対象がv5ベータのみである点だけが確実な事実として押さえられる。
GHSA-8fpg-xm3f-6cx3：「存在するかどうか」だけを見る認可チェックの罠
next-auth v5（Auth.js）が公式に推奨するミドルウェアの書き方は、auth()を呼び出して返り値の有無を見る「existence-based」な認可チェックだ。GHSAの記載を要約すると、この!!authのような存在チェックは、正常時であれば「ログイン済みならオブジェクトが返り、未ログインならnull/undefinedが返る」という前提の上に成り立っている。
ところが認可設定にエラーが起きたとき、auth()はこの前提を破り、ユーザー情報の代わりにエラー情報を含んだオブジェクトを返すことがある。JavaScriptの評価では、中身が何であれオブジェクトはtruthy（真）と評価されるため、!!authのような存在チェックは「エラーオブジェクトが返ってきた」場合でもtrueになってしまう。つまり、設定が壊れているという本来なら弾くべき異常事態が、逆に「認証済みユーザーのリクエスト」として扱われ、保護されているはずのルートへのアクセスが素通りする。
（具体的な誘因はデプロイ環境ごとに異なる）"] --> B["auth()がユーザー情報の代わりに
エラー情報を含むオブジェクトを返す"] C["ミドルウェアの認可チェック
!!auth で存在の有無だけを判定"] B --> C C --> D["エラーオブジェクトもtruthy
→ 認証済みと誤判定"] D --> E["保護されるはずのルートに
未認証のリクエストが素通り
fail-open"]
この脆弱性の対象はnext-auth v5のベータ版（5.0.0-beta.0〜5.0.0-beta.31）のみで、v5の正式安定版やv4系は対象外だ。GitHub Advisory Database上のseverity表記は「critical」だが、CVSSの数値スコアは本記事執筆時点で算出されていない（cvss.score: null）。もう一つ見落としやすいのは条件付きの脆弱性であるという点だ。設定が正常に動いている間は無害で、「配置がおかしくなった瞬間」にだけ牙を剥く。平常時のログだけを見て「異常なし」と判断せず、設定変更時・デプロイ時のテストで意図的にエラーを起こして挙動を確認する必要がある。
next-auth v5がこの「existence-based」なチェックを推奨してきた背景には、Next.jsのミドルウェア（middleware.ts）からauth()を呼び出すだけで保護ルートを宣言できる、というシンプルさの追求がある。従来のv4系ではセッション取得とルート保護の記述がAPIルートごとに分散しがちだったのに対し、v5はミドルウェア1箇所に集約することで実装ミスを減らす狙いがあった。今回のGHSAは、この「シンプルにするための集約」が、逆に単一障害点（この1箇所の判定さえ壊れれば全体が壊れる）を生んでいたことを示す例でもある。集約すること自体は良い設計判断だが、その集約ポイントが「存在するかどうか」という緩い判定基準に依存していた点が今回の弱点になった。
GHSA-7rqj-j65f-68wh：正規化順序ミスで起きるマジックリンク誤送信
もう一件のGHSA-7rqj-j65f-68whは、v4系（4.10.3〜4.24.14）または@auth/core（0.1.0〜0.41.2）が対象で、GHSA-8fpg-xm3f-6cx3とは影響範囲も原因のレイヤーも異なる。こちらはメールアドレスによるパスワードレスログイン（マジックリンク）機能に関わるバグだ。
GHSAのタイトルが示す通り、原因は「メールアドレスの正規化（Unicode normalization）よりも先にバリデーションを実行してしまう」という処理順序のミスにある。本来は、ユーザーが入力した文字列をUnicode正規化してから妥当性チェック・DB照合を行うのが安全な順序になる。ところが今回の実装は逆で、正規化前の文字列でバリデーションが通過し、その後に正規化されたアドレスがDB照合やメール送信に使われる。Unicodeには見た目がほぼ同一でもコードポイントが異なる文字（同型異字・ホモグリフ）が存在するため、正規化の過程でこうした文字が「別の見た目」から「同一の宛先」へ変換され得る。結果として、攻撃者が細工したメールアドレスでマジックリンクをリクエストすると、正規化後には別のユーザーのメールアドレスと一致してしまい、本来届くはずのないログインリンクが意図しない宛先に送られる可能性がある。
Unicode正規化には一般にNFC・NFD・NFKC・NFKDという4種類の正規化形式があり、Webアプリケーションの文字列比較では見た目の同一性を吸収するためにNFC相当の正規化がよく使われる。メールアドレスのような「人間が入力し、システムが一意な宛先として扱う」文字列は、この正規化のタイミングを1箇所に固定し、バリデーション・DB照合・送信のすべてが同じ正規化後の値を参照する設計が定石とされる。今回のGHSA-7rqj-j65f-68whは、バリデーションだけが正規化前の値を見ていたために、この「1箇所に固定する」という定石から部分的に外れていたケースと整理できる。メール正規化順序のミスはnext-auth固有の問題というより、パスワードレス認証や招待メールのように「文字列としてのメールアドレスが直接セキュリティ境界に関わる」実装全般で起こりうる典型パターンでもある。
| 項目 | GHSA-8fpg-xm3f-6cx3 | GHSA-7rqj-j65f-68wh |
|---|---|---|
| 対象バージョン | next-auth 5.0.0-beta.0〜5.0.0-beta.31 | next-auth 4.10.3〜4.24.14 / @auth/core 0.1.0〜0.41.2 |
| 原因のレイヤー | 認可チェックのfail-open構造 | メール正規化の実行順序ミス |
| 発火条件 | 認可設定にエラーが起きたとき | マジックリンク認証を使用しているとき |
| 一言でいうと | 「検証してから正規化」ではなく設定エラー時に検証自体が無効化 | 「検証してから正規化」の順序で正規化前の文字列を通してしまう |
2件は「検証と正規化・エラー処理の順序」という同根の設計課題を、それぞれ別の箇所で踏んだ結果と整理できる。ただし影響を受けるバージョン・条件はまったく別物なので、「next-authの脆弱性」とひとまとめにせず、自分が使っているバージョンとどちらのGHSAに該当するかを個別に確認する必要がある。
自分の環境がnext-auth 脆弱性に該当するか——確認コマンドと対策
# ① next-auth本体と @auth/core を両方確認する（片方だけでは不十分）
npm ls next-auth @auth/core
# ② バージョンを対象範囲と照合する
# next-auth が 5.0.0-beta.0〜5.0.0-beta.31 → GHSA-8fpg-xm3f-6cx3の対象
# next-auth が 4.10.3〜4.24.14、または @auth/core が 0.1.0〜0.41.2 → GHSA-7rqj-j65f-68whの対象
# ③ 認可ミドルウェアの存在チェックパターンを洗い出す（fail-open対策）
grep -rn "!!auth\b\|req.auth\b" middleware.ts src/
③のgrep結果に!!authや!!req.authのような存在チェックが見つかった場合は、設定エラー時にその判定がどう振る舞うかを個別に確認する必要がある。特にv5ベータを使っている場合、この存在チェックのパターンこそがGHSA-8fpg-xm3f-6cx3の直接の対象になる。
構成ごとに該当有無を整理すると次のようになる。
| 構成 | 該当する可能性 | 理由 |
|---|---|---|
| next-auth v5ベータ（5.0.0-beta.0〜5.0.0-beta.31）を使用 | 高い | GHSA-8fpg-xm3f-6cx3の対象範囲に直接該当 |
| next-auth v5の正式安定版（5.0.0以降）を使用 | 低い | GHSA-8fpg-xm3f-6cx3の対象バージョン範囲外 |
| next-auth 4.10.3〜4.24.14、または@auth/core 0.1.0〜0.41.2を使用し、マジックリンク認証を有効化 | 高い | GHSA-7rqj-j65f-68whの対象範囲かつ発火条件に該当 |
| 上記v4範囲だが、メール認証（マジックリンク）を使わずOAuth等のみ | 低い | 発火条件（マジックリンク経路）が成立しない |
| [email protected]以降、かつv5は安定版のみ使用 | 該当なし | 両GHSAの対象バージョン範囲外 |
対策とアップデート手順
対策は基本的にバージョンアップが中心になるが、GHSAごとに確認すべき点が異なる。
・next-auth v5利用者：安定版（5.0.0以降）へのアップデートを優先する。ベータ版を本番環境で使い続けている場合はGHSA-8fpg-xm3f-6cx3の対象である可能性が高く、対策の緊急度も上がる
・next-auth v4 / @auth/core利用者：[email protected]以降、または@auth/coreの修正済みバージョンへアップデートする。マジックリンク認証を使っている場合はGHSA-7rqj-j65f-68whの対象になりうるため優先度を上げる
・認可ミドルウェアの見直し：!!authのような存在チェックのみに依存している箇所は、設定エラー時にどう振る舞うかをステージング環境で意図的に壊して確認する。GHSAは具体的な回避策（workaround）の詳細までは明記していないため、確実な対策はバージョンアップと、設定エラー時の挙動をテストで確認することの2点になる
・デプロイ後の動作確認：認可設定を変更・デプロイした直後は、意図的に不正な設定値を投入して「保護されたルートが正しく拒否されるか」を確認する運用を組み込む
・マジックリンクの送信先ログ確認：v4系・@auth/core利用時は、マジックリンクの送信先メールアドレスと入力値が一致しているかを監査ログで定期的に照合する
パッチ適用だけでなく、認可チェックのロジックそのものを「存在するかどうか」ではなく「正常な値かどうか」を見る形に見直すことが、同種のfail-open構造を再発させないための実務上のポイントになる。
認証OSSの比較——better-authの同時期脆弱性との違い
next-authと並んで使われるbetter-authでも、同時期に別系統の脆弱性が公表されている。better-auth 脆弱性｜SCIM/OAuthでアカウント乗っ取り、CVSS9.9のGHSA4件で扱ったSCIM/OAuth関連の4件と、今回のnext-auth 2件は原因のレイヤーが異なる。
| 項目 | next-auth（Auth.js） | better-auth |
|---|---|---|
| ライセンス | ISC | MIT |
| ⭐ Star数 | 28,314 | 29,422 |
| 今回の脆弱性の性質 | fail-open型の認可バイパス／Unicode正規化前検証 | SCIM/OAuthでの所有権検証漏れによるアカウント乗っ取り（最大CVSS 9.9） |
| 影響が及ぶ条件 | v5ベータ使用、またはマジックリンク認証使用 | SCIMプロビジョニングまたはOAuth自動リンクを有効化している場合 |
| CVSS数値 | 未算出（severity表記のみ） | 最大9.9（数値スコアあり） |
next-auth側は「エラーが起きたときに拒否すべきものを許可してしまう」という認可の設計ミス、better-auth側は「誰の所有かを検証していない」という所有権の束縛漏れに近い。どちらも企業向け機能や柔軟な設定を提供するために増えた分岐が原因になっている点は共通している。
導入判断の実務面でも違いがある。better-authはSCIM/OAuth自動リンクという特定機能を有効化したときだけリスクが顕在化するため、メール/パスワード認証だけの既存導入への影響は限定的だ。一方next-authのGHSA-8fpg-xm3f-6cx3はv5のベータ版というバージョン全体が対象になっており、機能の有効/無効に関わらず認可ミドルウェアを使っている以上は当てはまる。「機能単位のリスク」か「バージョン単位のリスク」かという切り分けは、優先度をつける際の実務的な判断材料になる。
なお、AWS API MCPサーバーで見つかったAWS MCPサーバーのfail-open脆弱性CVE-2026-16584｜deny設定が黙って無効化も同じ「fail-open」という構造だが、対象プロダクトはMCPサーバー側のポリシー実行系であり、認証ライブラリ側の今回のGHSAとは別対象だ。「エラー時にどちらへ倒すか」という設計判断がプロダクトの種類を問わず繰り返し起きているテーマであることがうかがえる。トークンや認証情報を狙う攻撃全般への多層防御という切り口ではトークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターンも参考になる。
まとめ
next-authのfail-open系GHSA2件は、影響バージョンも根本原因も別物だが、いずれも「エラーが起きたときにどちらへ倒すか」という設計判断の裏返しだった。v5ベータを使っている場合はGHSA-8fpg-xm3f-6cx3、v4系または@auth/coreでマジックリンク認証を使っている場合はGHSA-7rqj-j65f-68whの対象になりうるため、まずnpm ls next-auth @auth/coreでバージョンを確認し、対象範囲と照合するところから始めるのが実務的な順序だ。
next-authのfail-open系脆弱性は2件。GHSA-8fpg-xm3f-6cx3はv5ベータ（5.0.0-beta.0〜5.0.0-beta.31）限定で、認可設定のエラー時に「存在するかどうか」だけを見るチェックが全リクエストを通してしまう。GHSA-7rqj-j65f-68whはv4系・@auth/coreが対象で、メール正規化前のバリデーションによりマジックリンクが別人に届く可能性がある。npm ls next-auth @auth/coreでバージョンを確認し、grep -rn "!!auth\b\|req.auth\b" middleware.ts src/で存在チェックのパターンを洗い出した上で、該当するGHSAの修正版へアップデートする。
参照ソース
・GHSA-8fpg-xm3f-6cx3（Auth.js: Configuration errors can cause existence-based auth checks to fail open） — fail-open認可バイパスの一次情報
・GHSA-7rqj-j65f-68wh（Auth.js: Email normalizer validates the address before Unicode normalization） — マジックリンク誤送信バグの一次情報
・next-auth 公式リポジトリ — star/fork/ライセンス/リリース実測の取得元
・Auth.js 公式セキュリティポリシー — 脆弱性報告プロセスの一次情報
