Laravelの認証回避、直した版は8月に出ていた。「いつも通り更新していた」サイトは守られていた

• Laravel標準のAPI認証「TokenGuard」で、トークンを知らなくても他人として認証される穴（CVE-2026-114509、CVSS 9.2）
• 条件は、TokenGuardを使っていて、データベースがMySQLかMariaDB（特定の構成）であること
• 直した版（12.68.0 / 13.29.0）は8月25日にもう出ていた。勧告が出たのは10月19日

PHPでWebアプリを作るためのフレームワーク「Laravel」の開発チームが、2件のセキュリティ勧告を公表した。1件は深刻度「Critical（9.2）」の認証回避だ。

今週はPHP本体の脆弱性で大騒ぎになった。だが今回はPHPの上で動くフレームワークの穴で、話が別だ。PHPを最新にしても、こちらは直らない。

そして今回、いちばん伝えたいのは日付の話だ。

何が起きるのか

Laravel公式の勧告によると、こうだ。

• Laravelに最初から入っているTokenGuard（トークン方式のAPI認証）を使っている
• データベースがMySQLかMariaDBで、特定の構成になっている
• そこに攻撃者が文字列ではない形の値を、細工して送る
• 認証の照合がうまく失敗せず、関係のない既存ユーザーと一致してしまう

結果として、ログインしていない攻撃者が、そのユーザーのAPIトークンを知らないまま本人として扱われる。公式は「アカウントの乗っ取り」につながるとしている。

なぜ「文字列ではない値」で通るのか

勧告は細かい手口を書いていない。ここでは一般的な仕組みとして説明する。

トークンは本来、文字の並びだ。だが、送られてくるデータが数値や真偽値だった場合、MySQLなどは比べる前に型をそろえようとして変換することがある。この変換のせいで、本来は一致しないはずの値どうしが一致してしまうことが、昔から知られている。

Laravelの修正は、受け取った値が文字列かどうかを、照合の前に確かめるものだと報じられている。「想定外の型を、入口で止める」という基本の確認が抜けていたことになる。

直った版は、8月25日に出ていた

リリースの日付は、GitHubの公開記録で確かめた。修正版は勧告の約2か月前に出ていた。

開発元が修正を先に配り、使う側が上げ終わるのを待ってから中身を公表するのは、よくあるやり方だ。だから、8月以降もいつも通りLaravelを上げていたサイトは、勧告が出たときにはもう直っていた。

逆に、「何か起きたら上げる」運用だと、勧告が出てから慌てることになる。しかも今回は、翌日に検証用のコードが出回った。更新を「事件」から「習慣」に、と前に書いたのは、まさにこういう場面のためだ。

自分のアプリが対象か

1. Laravelの版を確かめる。本番に出ている composer.lock の laravel/framework の版を見るのが確実だ
2. TokenGuardを使っているかを確かめる。config/auth.php の guards で、'driver' => 'token' になっているガードがあるか
3. そのガードで守っているAPIが、外から使える状態か
4. データベースがMySQLかMariaDBか

Laravel SanctumやPassportは、別の仕組みの認証だ。公式の勧告が対象にしているのは標準のTokenGuardになる。ただ、複数の認証を併用しているアプリは、設定を一つずつ見ておきたい。

修正版と、古い系列

Laravelは、1つの系列に不具合の修正を18か月、セキュリティの修正を2年出す方針だ。毎年新しい系列が出るので、2年に1回は系列を上げる前提で計画しておく必要がある。

同じ日に出た、もう1件

Laravelは同じ日に、もう1件の勧告（CVE-2026-114508、深刻度Moderate 6.5）も出している。

• 一部の読み取り用のAPIで、関連データをまとめて取り出す処理に問題があった
• 条件がそろうと、読む権限しかないリクエストで、関連するテーブルが空になるような破壊的な操作が起きうる
• 対象は12.45.0以降13.27.0未満。修正は12.68.0 / 13.27.0

13系は、認証回避の修正（13.29.0）まで上げれば両方が直る。こちらはデータが消える種類なので、バックアップから戻せるかも確かめておきたい。

攻撃は確認されているか

米国のCISAが公開している「悪用が確認された脆弱性」の一覧（2026年10月23日版）を確かめたが、どちらのCVEも載っていない。

ただし、検証用のコードが出回った以上、試す人は出てくる。上げたあとは、TokenGuardで守っているAPIの認証の成功・失敗のログに、見慣れない形の値で通ったものがないかを見ておくとよい。怪しいものがあれば、そのユーザーのトークンを作り直す。

まとめ

• Laravel標準のTokenGuardで、トークンなしで他人として認証される穴。CVSS 9.2
• 条件はTokenGuard ＋ MySQL/MariaDB（特定の構成）。PHPの更新では直らない
• 修正版 12.68.0 / 13.29.0 は8月25日に公開済み。定期的に上げていれば守られていた
• 11系以前はサポート終了。12系か13系へ
• 同日に読み取りでデータが消える穴（CVE-2026-114508）も公表。13系は13.29.0で両方直る

出典

• Laravel「Token-based API guard Auth Bypass」（GHSA-f9x3-7vq9-cph6 / CVE-2026-114509）（影響、条件、修正版、CVSS v4 9.2）
• Laravel「Unauthorized Data Destruction」（GHSA-5wcm-3v2w-8362 / CVE-2026-114508）（対象版、修正版、CVSS v3.1 6.5）
• Laravel v12.68.0 / v13.29.0（いずれも2026年8月25日公開）
• Laravel「Release Notes」（サポート方針、各系列のセキュリティ修正の期限）
• CISA「Known Exploited Vulnerabilities Catalog」（2026年10月23日版で両CVEが未掲載であることを筆者が確認）
• セキュリティ対策Lab「PHP フレームワーク Laravelに認証回避脆弱性『CVE-2026-114509』、PoC公開」（2026年10月24日更新。検証コードの公開、修正の内容についての報道）

本記事は2026年10月25日時点の公式発表に基づく。「なぜ文字列ではない値で通るのか」の節は一般的な仕組みの説明であり、今回の攻撃手順を示すものではない。自分のアプリが対象かは、設定とデータベースの構成を確かめたうえで判断すること。