LaravelのTokenGuardで認証回避｜APIのガードとDB構成から更新対象を確認

LaravelでAPIを公開している場合、ログイン画面が正常に動くことだけでは今回の問題を判断できません。確認すべきなのは、保護されたAPIがどの認証ガードを使い、受け取った資格情報をどのDBへ照合しているかです。

Laravelが公表したCVE-2026-114509は、組み込みのTokenGuardを使う標準的なトークン認証APIで、別の既存ユーザーとして認証されるおそれがある脆弱性です。本サイトでは未掲載だったため、構成の切り分けと更新判断を整理します。今日新しく発表された問題ではありません。

確認できた脆弱性と日付

一次資料のLaravel：Token-based API guard Auth Bypassには、初回公表日として2026年10月19日が表示されています。重要度はCritical、CVSS 4.0の基本値は9.2です。本記事の確認日は10月25日であり、記事公開日や確認日を脆弱性の公表日として扱いません。

提供元によると、MySQL／MariaDBの特定のDB構成で、細工された文字列以外の資格情報を渡すと、認証の照合が意図しないユーザーレコードに一致する可能性があります。攻撃者は対象ユーザーの有効なAPIトークンを知らなくても、影響するガードが保護するルートで本人として扱われるおそれがあります。

一次告知が示す修正境界は、12系が12.68.0、13系が13.29.0です。それぞれの系列でこの版以上が修正版として示されています。12.68.0未満の12系を13系向けの数値だけで判定しないでください。古い系列や独自バックポートは、保守元へ修正の有無を照会する必要があります。

確認した告知には、実環境での悪用を確認したという記述はありません。本記事も悪用確認済みとは扱いません。また、DBの詳細条件や全構成の安全性は告知だけでは確定できないため、「MySQLなら必ず侵害される」「別のDBなら無条件に安全」とは断定しません。

ガード名と認証方式を分けて調べる

Laravel公式ドキュメント：Authenticationでは、ガードは要求ごとの認証方式、プロバイダーは永続ストレージからユーザーを取得する方法として説明されています。設定の入口はconfig/auth.phpです。ルートで指定するガード名は設定キーであり、名前にapiが含まれるだけではTokenGuardかどうかは分かりません。

まず対象APIのルートとミドルウェアを一覧化し、使用するガード、そのドライバー、ユーザープロバイダー、接続先DBを一組で確認します。通常のブラウザー画面、モバイル向けAPI、管理API、旧バージョンのAPIで方式が異なることもあります。公開していないつもりの経路も、ロードバランサーや別ホストから到達できないかを調べます。

SanctumやPassport、独自JWTガードを使用しているという情報だけで全体の調査を終えないでください。同じアプリに旧TokenGuardの経路が残る可能性があるためです。一方、今回の告知を根拠に、それら別実装にも同じ脆弱性があると広げることはできません。実際に問題のガードを使う経路を特定するのが先です。

• 対象ルート：URL・HTTPメソッド・外部公開範囲・扱うデータを記録する。
• 認証方式：ガード名だけでなく実装クラスやドライバーを確認する。
• 照合先：ユーザープロバイダー、DB製品、接続先と関連設定を確認する。
• 実行版：リポジトリの指定値、ロックされた版、稼働環境の版を照合する。

優先するのは認証を通過した後の影響が大きいAPI

以下の優先順位は、一次告知の影響を自社へ当てはめる本サイトの提案です。外部公開され、TokenGuardを使い、顧客情報の取得や権限変更、APIキー発行などへ届く経路を優先してください。単なる利用者数だけでなく、なりすまされた場合に何ができるかで対応順を決めます。

例えば、注文照会だけのAPIと、管理者追加やデータ一括出力を許すAPIでは、同じ認証回避でも調査対象が変わります。これは説明用の仮想例で、今回それらの機能が実際に悪用されたという報告ではありません。管理画面に二要素認証があっても、別のトークン認証APIの検査を代替するとは限りません。

認証された利用者への認可が正しくても、最初の本人確認で別人として扱えば、その別人に許された操作へ到達する可能性があります。認可を追加すれば更新が不要になるという問題ではありません。認証回避の修正と、対象・操作ごとの認可の確認を分けて進めます。

更新はロックファイルから実行環境まで確認する

本サイトでは、開発・検証環境で次の確認から始めることを提案します。Composer公式：コマンドラインとauditの説明を参照し、インストール済みの版とロックファイルの版を区別してください。コマンドを本サイトで対象環境に実行したわけではありません。

composer show laravel/framework
composer show --locked laravel/framework
composer audit

composer.jsonの制約を書き換えただけでは、稼働中の依存関係は更新されません。対応する系列の修正版以上へ依存関係を解決し、ロックファイルの差分をレビューし、同じ成果物を検証して本番へ配布します。無関係なパッケージを大量に更新する場合は、互換性の確認範囲も増えるため変更を把握できる単位で進めます。

composer auditの結果は有用ですが、データベースへの告知反映や例外設定によって見え方が変わります。警告がないことだけを修正済みの証拠にせず、一次告知の修正境界と実際の版を比較します。逆に、版の警告が出たことだけで侵害を断定することもできません。

Laravel公式ドキュメント：Deploymentは、デプロイ時の設定キャッシュと長時間動作サービスの再読み込みを扱っています。自社の配布手順に従い、設定の反映と、Octaneなどアプリケーションを保持するプロセスの入れ替えを確認します。単に一台のCLIで新しい版を表示できても、全インスタンスのHTTP要求が同じ成果物を使っているとは限りません。

正しいトークンの成功と不正な入力の拒否を対にする

更新後の完了条件は、正規ユーザーが利用できることに加え、不正な資格情報で別のユーザーとして扱われないことです。本サイトでは、許可された検証環境に会員A・会員Bと架空データを用意し、同じ保護APIを通して確認する方法を勧めます。本番の利用者情報を試験用に使う必要はありません。

• 正しいトークン：発行した本人だけとして認証され、期待する操作ができる。
• 無効・欠落したトークン：認証済みユーザーにならず、保護された情報を返さない。
• 仕様外の型：数値・真偽値・配列など、APIが許していない形式で認証が成功しない。
• 利用者の分離：Aの資格情報でBのデータ取得や管理操作が許可されない。
• 副作用：拒否応答でも、DB更新や外部送信が先に起きていない。

どの形式を受け付けるかは自社APIの契約と実装に合わせます。ここで挙げた型は防御確認の観点であり、それぞれが今回の脆弱性を確実に再現する攻撃文字列だという意味ではありません。HTTPステータスだけでなく、認証されたユーザーID、応答内容、保存結果を照合してください。

ログに資格情報そのものを追加する方法は避けます。試験ケースIDや追跡用ID、認証結果、参照されたユーザーの内部識別情報など、アクセス権を絞った記録で対応付けます。失敗時にSQLやDB接続情報を外部へ表示しないことも確認します。

更新までの暫定策には期限と解除条件を置く

直ちに更新できず、影響するガードと公開経路が確認できた場合は、そのAPIの外部公開を一時停止する、接続元を業務上必要な範囲へ限定するなどの措置を検討します。これは本サイトの運用提案であり、提供元が全構成に保証する回避策ではありません。利用者への影響と復旧手順を合わせて決めてください。

文字列以外を拒否する検査を加える場合も、認証処理より前で確実に適用される必要があります。通常のコントローラー内の検証が、認証ミドルウェアより先に動くとは限りません。経路や形式ごとに検査漏れがないことを確認できなければ、暫定パッチだけで安全と判断しないでください。

WAFはアプリ側のユーザー照合やDB構成をそのまま理解するものではありません。特定の文字列を遮断したことだけで修正完了にはせず、期限、担当者、対象経路、正規利用の確認、解除条件を記録します。新しい認証方式へ急いで全面移行するより、まず修正版の適用で今回の穴を塞ぐ判断が必要です。

不審な認証成功があれば侵害確認を追加する

OWASP：Authentication Cheat Sheetは、認証機能のログと監視、認証失敗の記録・確認を推奨しています。今回の影響条件に当てはまる環境では、公開期間中の認証結果と、その後の重要操作を時系列で照合することを本サイトは提案します。利用者が認識しない情報取得、資格情報追加、権限変更、一括出力などがないかを調べます。

失敗が少ないから安全とは限りません。認証回避では成功として記録される可能性があるため、成功時刻、アクセス元、実行した操作、対象ユーザーの普段の利用といった複数の情報を組み合わせます。逆に、見慣れないIP一つだけで侵害や特定攻撃者を断定しないでください。

不審な操作が確認された場合は、関連ログを保全し、影響する資格情報やセッションの失効範囲を判断します。失効を実際に検証する考え方は、既存記事のログアウト後も使えるセッションを残さないための失効設計にまとめています。これは10月18日確認の一般対策で、今回の脆弱性の修正を代替するものではありません。

APIの機能・対象ごとの認可を継続して点検する場合は、管理APIの認可と点検手順も参照してください。今回の優先課題はTokenGuardの影響判定と更新です。そのうえで、修正済みの認証を通った利用者にも過大な操作を許していないかを確認します。

対応完了として残す記録

担当者は、影響するガードの有無、DB構成、修正前後の版、配布した成果物、全インスタンスの反映時刻、拒否テストの結果、侵害確認の実施範囲を残します。対象外と判断した経路についても、ガード実装と確認日を記録すれば、後日の構成変更で再評価できます。

今回確認した一次告知から修正版は確認できますが、すべてのDB条件や悪用状況の全体像までは確定できません。CISAの告知一覧は取得時に403となり、今回の新着調査では未確認です。本記事は定期的な資料確認に基づくもので、常時監視や全情報源の網羅を意味しません。