Laravel 脆弱性｜TokenGuardの認証回避、12.68.0と13.29.0で修正・当てはまる条件と確認手順

Laravel は Composer で取り込む依存パッケージの一つです。依存関係から入る攻撃と防御の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事は、この件で自分のアプリが当てはまるかを確かめ、当てはまったら何をするかに絞ります。

Laravel 脆弱性 GHSA-f9x3 の時系列（タイムライン）

日時は GitHub のアドバイザリと、laravel/framework のタグが指すコミットの日時（UTC）です。

アドバイザリには、悪用の有無と公開された攻撃コードの記載がありません。本記事が確かめた範囲でも、悪用の報告は見当たりませんでした。修正版の公開から公表まで約8週間ありました。12.x・13.x で 8月26日以降に laravel/framework を更新していたアプリは、公表の前に修正版になっています。

何が起きたか：Laravel TokenGuard が文字列でないトークンを照会に渡していた

TokenGuard はリクエストから受け取った API トークンで利用者のテーブルを照会し、一致した行の利用者として認証するガードです。アドバイザリによれば、MySQL/MariaDB の構成では、攻撃者が細工した「文字列でない」資格情報の値が照会の中で誤って扱われ、認証が失敗するはずのところで意図しない利用者の行に一致しえました。

修正はガードの2か所で、照会の前に値が文字列かどうかを確かめるものです（コミット 8dbb08b の差分から抜粋）。

-        if (! empty($token)) {
+        if (is_string($token) && ! empty($token)) {
             $user = $this->provider->retrieveByCredentials([

validate() も同じく、文字列でない値なら照会せずに false を返すようになりました。どの値でどの行に一致するのかは、アドバイザリが公表していないため本記事も書きません。

攻撃者が得るものと、できることは次のとおりです。アドバイザリは影響を「影響を受けるガードで守られたすべてのルートでの、認証回避とアカウントの乗っ取り」としています。

認証が通った後の認可の作りによって、被害の広さが変わります。利用者ごとのデータの切り分けはIDOR（認可漏れ）の見つけ方｜2アカウントのテストとコードレビューで「他人のデータが見える」を潰すで扱っています。

Laravel 認証まわりの別件との見分け方

検索すると、名前の似た別件が混ざって出てきます。Passport にも TokenGuard という同じ名前のクラスがあり、取り違えやすい点です。

GHSA-5wcm の修正コミット（12.x は 50a7970）は、12.45.0 で入った JSON:API リソースの関連を読み込む処理を変えています。framework の 2 件はどちらも 12.68.0 で直るので、12.x は更新を一度で済ませられます。

影響を受ける条件：Laravel API 認証に token ドライバーを使っているか

4つの条件がそろうと影響を受けます。迷いやすいのは2つ目と3つ目です。

・token ガードはいまの雛形には無い：laravel/laravel の config/auth.php は、2021年8月のコミット（v8.6.0）で api ガードの token ドライバーを外し、Sanctum に置き換えた。それより前に作ったアプリを版だけ上げてきた場合は、設定が残っていることがある
・定義と利用は別：ガードは呼ばれたときに作られる。auth:api のミドルウェア、既定のガード（defaults.guard）、Auth::guard('api') のどれかで使っていれば当てはまる
・Sanctum と Passport は別のガード：Sanctum はアドバイザリに挙がっていない。Passport は上の表の別件を確かめる

対策：Laravel アップデートで 12.68.0 か 13.29.0 以降へ

composer.json の制約が ^12.0 や ^13.0 なら、composer update laravel/framework で修正版まで上がります。上げた後は composer.lock をコミットし、本番に配備された版を次の節のコマンドで確かめます。

更新できない間の考え方

・token ガードを使わない：そのガードで守る API を止めるか、Sanctum などへ移す。設計の変更なので、すぐには難しいことが多い
・ガードの手前で拒む：トークンとして読む入力が文字列でない要求を、TokenGuard より前のミドルウェアで拒む。修正と同じ考え方だが、本記事はこの方法を試していない
・WAF で稼ぐ：期限を切った仮想パッチの運用は仮想パッチとは｜修正版を当てるまでの数日をWAFで稼ぐ手順と、IDORやカーネルなどWAFでは守れない脆弱性にまとめた

トークンの再発行では塞がりません。攻撃者は相手のトークンを知らずに認証できるので、塞ぐのは本体の更新です。アドバイザリは侵害の痕跡（IOC）を示していません。影響範囲の版で token ガードを公開していたなら、そのガードで守られた API の監査ログを見て、利用者が覚えのない操作をしていないかを確かめます。

自システムの確認コマンド：版と token ガードの使い方を見る

アプリのリポジトリのルート（composer.json のあるディレクトリ）で実行します。どれも読み取りだけのコマンドで、見ているのは「影響を受ける版か」と「token ガードを使う構成か」です。攻撃を受けたかどうかの判定ではありません。

1. laravel/framework の版

git fetch --all --prune
composer show --locked laravel/framework | grep -E '^versions'
git show origin/main:composer.lock | grep -A1 '"name": "laravel/framework"'
php -r '$v = ltrim($argv[1], "v"); $fixed = version_compare($v, "13.0.0", ">=") ? "13.29.0" : "12.68.0"; echo $v, (version_compare($v, $fixed, "<") ? " は影響範囲（{$fixed} 未満）" : " は {$fixed} 以降"), PHP_EOL;' "$(composer show --locked laravel/framework | awk '/^versions/ {print $NF}')"

2行目は作業ツリーの composer.lock の版、3行目は配備するブランチの版です（origin/main は自分の配備ブランチに置き換える）。4行目はアドバイザリの修正版と比べた結果を1行で出します。

2. token ガードを使っているか、DB は何か

sed -n "/'defaults' => \[/,/^    \],/p; /'guards' => \[/,/^    \],/p" config/auth.php | grep -E "=> \[|'guard'|'driver'"
grep -rnE "auth:api|guard\(['\"]api['\"]\)|TokenGuard" routes app bootstrap
grep -nE '^DB_CONNECTION=' .env

1行目は既定のガードと、各ガードのドライバーを出します。'driver' => 'token' があれば、その上の行がガード名です。2行目はルートとコードの中で api ガードを使っている箇所を探します。ガード名が api でなければ、2行目の api を自分のガード名に置き換えます。

結果の読み方と、このコマンドの限界

ダミーのアプリ2つ（12.67.0・2021年8月より前の雛形の config/auth.php・auth:api のルート・DB_CONNECTION=mysql の陽性対照と、12.70.0・いまの雛形・auth:sanctum・sqlite の陰性対照）で、掲載したままのコマンドを走らせました。

読むときの注意は3つです。

・陰性でも安全とは限らない：本番の DB 接続は .env でなく環境変数で渡していることがある。パッケージ（vendor/）の中のルートは2行目で探していない。composer.lock と本番に配備された vendor/ がずれていれば、版の結果も外れる
・陽性でも危ないとは限らない：token ガードを定義していても、どこからも呼んでいなければこの経路は通らない。11.56.1 以降の 11.x は、4行目では影響範囲と出るがコードには同じ変更が入っている
・composer audit では分からない：2026-10-20 時点で、12.67.0 の composer.lock に composer audit --locked をかけると別件（GHSA-jh5r-qr3c-85q8）だけが出て、本件と GHSA-5wcm は出なかった。Packagist の公開データベースに載るまでは版を自分で比べる

依存パッケージの警告をどれから直すかの考え方は、npm の例でnpm audit の結果はどれから直す？依存関係の脆弱性を到達性・EPSS・KEVで仕分ける実践手順にまとめています。

影響範囲：Laravel 脆弱性 GHSA-f9x3 の対象になるアプリ

参照ソース

・Token-based API guard Auth Bypass（GHSA-f9x3-7vq9-cph6） — 深刻度・CVSS・影響する版と修正版・条件（MySQL/MariaDB）・影響
・Unauthorized Data Destruction（GHSA-5wcm-3v2w-8362） — 同日公表の別件の版と影響
・TokenGuard Authenticates Unrelated User for Client Credentials Tokens（GHSA-349c-2h2f-mxf6） — Passport の別件（CVE-2026-39976）
・fix token retrieval（コミット 8dbb08b） — 12.x の修正の差分
・laravel/laravel の config/auth.php の変更（コミット 226d1bf） — 雛形の api ガードを token から外したコミット