LaravelのTokenGuardに認証回避の脆弱性、MySQL・MariaDBの一部の構成で他人として認証されるおそれ。Sanctumとの見分け方と11系以前の扱い

TokenGuardは、要求に含まれるAPIトークンを取り出し、そのトークンを持つ利用者をデータベースから探す仕組みです。トークンは、URLのクエリや送信された値のapi_token、Authorization: Bearerヘッダーなどから読み取ります。[1][6]

Laravelのアドバイザリによると、MySQL・MariaDBの一部の構成で、文字列でない形に細工した値を送ると、認証の検索の処理で正しく扱われず、本来は失敗するはずの問い合わせが別の利用者の行に一致します。攻撃者は、相手のAPIトークンを知らないまま、既存の利用者として認証されるおそれがあります。そのガードで守ったルートでは、認証の回避とアカウントの乗っ取りにつながります。どの構成が対象かは、アドバイザリに記載がありません。[1]

修正は、TokenGuardが受け取ったトークンが文字列かを確かめ、文字列でなければ検索しないようにしたものです。修正のコミットのテストでは、配列の値を送る例が使われています。[5]

次の条件がそろう環境が対象です。[1]

• 標準のトークン方式のAPIガード（TokenGuard）でルートを守っている。config/auth.phpのguardsに'driver' => 'token'がある
• データベースがMySQLまたはMariaDBで、影響を受ける構成になっている（具体的な構成はアドバイザリに記載なし）
• laravel/frameworkが13.29.0未満、または12.68.0未満

11月1日に確かめた時点で、米CISAの悪用が確認された脆弱性の一覧（KEV、10月30日版）には載っていません。CVEの記録に米CISAが付けた評価（SSVC、10月28日）も、悪用は「なし」です。[2][3]

攻撃のコード（PoC）として公開されたものは確認できませんでした。ただし、修正のコミットのテストに、問題を起こす入力の形が載っています。今後30日に悪用される見込みの推定（EPSS）は0.78%です（10月31日時点）。深刻度は、LaravelとCVEの採番機関のGitHubの評価でCVSS 4.0の9.2（緊急）です。NVDは11月1日時点で分析待ちで、独自の値を付けていません。[4][5][7]

今回の修正版は13.29.0と12.68.0で、12.68.0は8月25日、13.29.0は8月26日（いずれも日本時間）にPackagistで公開されています。公表が修正版の公開から約2か月後だったため、すでに上げている環境もあります。同じ時期のLaravelのアドバイザリも直る版は、13系が13.30.0、12系が12.69.0です。13.30.0・12.69.0では、APP_DEBUG=trueのときのエラー画面のXSS（CVE-2026-102279、低）が直っています。[1][8][9]

推奨する版は、Laravelのリポジトリで公表されたアドバイザリと、Packagistで公開済みの版から出しました（11月1日確認）。13系はPHP 8.3以上、12系はPHP 8.2以上が必要です。更新の前に、Laravelのリリースノートで変更点を確かめてください。[1][8][10]

1. composer.lockに記録されたlaravel/frameworkの版を確認します。

   ターミナル

   composer show --locked laravel/framework

2. TokenGuard（ドライバーtoken）のガードがあるか、どのルートがそのガードを使っているかを確認します。

   ターミナル

   grep -n "'driver'" config/auth.php
   grep -rn "auth:api\|guard('api')" routes app

3. 推奨する版へ上げます。13系なら13.30.0以上、12系なら12.69.0以上になるよう、composer.jsonの指定を確かめてから実行します。

   ターミナル

   composer update laravel/framework --with-dependencies
   composer show --locked laravel/framework

4. Packagistに登録された脆弱性の情報で、他に残っているものがないかを確かめます。

   ターミナル

   composer audit --locked

5. 本番に反映したあと、実際に動いているLaravelの版を確かめます。コンテナイメージやデプロイ先でも同じ確認をします。

   ターミナル

   php artisan --version

Laravelのアドバイザリには、回避策の記載がありません。対応は修正版への更新です。[1]

TokenGuardを使っていないアプリ（'driver' => 'token'のガードが無いアプリ）は、この脆弱性の条件に当てはまりません。その場合も、同じ版で直る他の脆弱性のために、上の表の版へ上げることを勧めます。

LaravelのAPI認証には、標準のTokenGuard（ドライバーtoken）のほかに、Sanctum（ドライバーsanctum）やPassportがあります。アドバイザリが対象として挙げるのはTokenGuardだけです。SanctumはLaravel\Sanctum\Guardという別のクラスで、personal_access_tokensの表からトークンを探します。[1][6][11]

Sanctumを使っていても、古いガードの設定がconfig/auth.phpに残っていて、一部のルートだけがそちらで守られていることがあります。auth:apiなどのミドルウェアの指定が、どのガードを指しているかを手順で確かめます。

アドバイザリは影響範囲を「12.68.0未満」としており、11系以前も対象に含まれますが、11系以前の修正版は記載していません。Laravelのサポートの方針では、セキュリティの修正の提供は11系が2026年3月12日、10系が2025年2月4日に終わっています。[1][12]

なお、Laravelのリポジトリでは、11系の11.56.1（8月25日公開）と10系の10.50.4（10月27日公開）のTokenGuardに、同じ文字列の確認が入っています。これはアドバイザリが示す修正版ではなく、他の脆弱性の修正も保証されないため、12系以上へ移るまでのつなぎとして扱います。[8][13]

脆弱性の公表・更新一覧で、PHPの関連情報を調べることもできます。