- PHP で Web アプリを作るための土台のソフト（フレームワーク）Laravel（ララベル）に、API の合言葉（トークン）を知らない人が、ほかの利用者になりすましてログインできてしまうおそれがある脆弱性 CVE-2026-114509 が公表されました。深刻度は Critical（CVSS 4.0 で 9.2）です［Laravel の GitHub アドバイザリ］。
- 対象は、Laravel 標準の「token」方式の認証（TokenGuard）を使っていて、データベースが MySQL か MariaDB の、一部の設定のアプリです。すべての Laravel アプリが対象ではありません。
- 修正版は Laravel 12.68.0 と 13.29.0（どちらも2026年8月25日〜26日に公開済み）。それより古い版が対象です。
- 同じ日に、読み取りだけのはずの API からデータを消されるおそれがある中程度の脆弱性 CVE-2026-114508 も公表されました。修正版は 12.68.0 と 13.27.0 です。
- どちらも Laravel の問題で、PHP 本体の脆弱性（php2shell）とは別物です。Laravel と PHP の両方を更新する必要があります。悪用が確認されたという公式の発表は、10月25日時点ではありません。
何が起きたか
Laravel は、会員サイトや予約システム、スマホアプリの裏側の API などを PHP で作るときによく使われるフレームワークです。自社で開発していなくても、制作会社に作ってもらったシステムが Laravel でできていることがあります。
Laravel の開発チームは、日本時間の10月19日 22時32分に、GitHub で次の脆弱性の情報（セキュリティアドバイザリ）を公開しました［Laravel の GitHub アドバイザリ］。
| 項目 | 内容（GitHub アドバイザリ・CVEレコード） |
|---|---|
| 名前 | Token-based API guard Auth Bypass（トークン方式の API 認証の回避） |
| 番号 | GHSA-f9x3-7vq9-cph6 / CVE-2026-114509 |
| 深刻度 | Critical。CVSS 4.0 の基本値 9.2（AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H） |
| 中身 | Laravel 標準の TokenGuard を、トークン方式の API 認証として設定している場合、特定のデータベース設定（MySQL/MariaDB）のもとで、細工した「文字列ではない」値を送られると、ログインの照合がうまく失敗せず、別の既存の利用者として認証されてしまうおそれがある |
| 起こりうること | ログインしていない攻撃者が、ほかの利用者のトークンを知らないまま、その利用者になりすます（アカウントの乗っ取り）。対象の認証で守られたすべての API が影響を受ける |
| 弱点の種類 | CWE-287（不適切な認証）、CWE-1287（入力の型の確認不足） |
| 報告者 | KIKOmanasijev 氏 |
TokenGuard（トークンガード）は、API を呼び出すときに送られてくる「トークン」という合言葉の文字列を、データベースの利用者の情報と照らし合わせて「だれのリクエストか」を決める Laravel の部品です。今回は、本来は文字列であるはずのトークンに別の形の値が来たときの扱いに抜けがありました。修正は、Laravel のリポジトリの TokenGuard のファイルに対して行われています［GitHub のコミット］。攻撃の手順に当たる部分は、この記事では扱いません。
CVSS は脆弱性の深刻さを0〜10で表す共通の物差しです。9.2 は、もっとも深刻な区分「Critical」（9.0〜10.0）に入ります。評価の中の「AT:P」は、攻撃が成り立つには特定の条件（ここではデータベースの種類や設定）がそろう必要がある、という意味です（読み方はCVSSの解説にまとめています）。
対象になるアプリ・ならないアプリ
アドバイザリによると、条件は次の3つが重なることです。
- Laravel のバージョンが修正版（12.68.0 / 13.29.0）より前
- Laravel 標準の token ドライバー（TokenGuard）を使った認証（guard）を設定し、API などを守っている
- データベースが MySQL か MariaDB で、影響を受ける設定になっている
| 使い方 | 対応 |
|---|---|
config/auth.php の guards に 'driver' => 'token' の行があり、その guard を API のルートで使っている（MySQL/MariaDB） | 対象。急いで更新 |
| token ドライバーを使っていない（画面からのログインだけ、など） | この脆弱性の条件には当たらない。ただし同じ日のもう1件や PHP 本体の件があるので、更新はしておく |
| Laravel Sanctum・Laravel Passport で API の認証をしている | 報道（Laravel News）によると、Sanctum と Passport は独自の仕組みを使うため、今回のアドバイザリの対象には挙がっていない。アドバイザリ自体には Sanctum・Passport についての記載はない |
| データベースが PostgreSQL・SQLite など | アドバイザリは MySQL/MariaDB の一部の設定を条件にしている。ただ、ほかのデータベースなら安全とは書かれていないので、更新はしておく |
| 制作会社にシステムを作ってもらった | Laravel かどうか、token ドライバーを使っているか、今のバージョンはいくつかを聞く |
token ドライバーは、Laravel の以前の版の初期設定に api という名前の guard として入っていたことがあり、古くから続くアプリには設定が残っている場合があります。設定ファイルに行があるだけでなく、実際にルートの保護（auth:api など）に使われているかも確かめてください。分からなければ、開発した会社や担当者に確認するのが確実です。
修正版の一覧
アドバイザリと CVE レコードに書かれた対象と修正版です［GitHub アドバイザリ・CVE.org］。
| 使っている系列 | CVE-2026-114509（認証の回避） | CVE-2026-114508（データ削除） | 上げる先 |
|---|---|---|---|
| 13.x | 13.29.0 より前が対象 | 13.27.0 より前が対象 | 13.29.0 以降 |
| 12.x | 12.68.0 より前が対象 | 12.45.0 〜 12.68.0 より前が対象 | 12.68.0 以降 |
| 11.x 以前 | 対象（CVE レコードでは「12.68.0 より前」） | 対象外（12.45.0 より前のため） | 修正版は出ていない。12.68.0 以降か 13.29.0 以降への移行が必要 |
修正版そのものは、アドバイザリの公開より前の8月に出ています。12.68.0 は日本時間8月25日 23時19分、13.29.0 は8月26日 5時58分に GitHub で公開されました［Laravel のリリース］。9月以降に Laravel を普通に更新していれば、すでに直っていることになります。いまの最新は 13.38.0（10月20日）と 12.70.1（10月21日）です。
同じ日に出たもう1件（データ削除のおそれ）
同じ報告者から、もう1件の脆弱性も同じ日に公表されています［Laravel の GitHub アドバイザリ］。
| 項目 | 内容 |
|---|---|
| 名前 | Unauthorized Data Destruction（権限のないデータの破壊） |
| 番号 | GHSA-5wcm-3v2w-8362 / CVE-2026-114508 |
| 深刻度 | Medium（中）。CVSS 3.1 の基本値 6.5 |
| 中身 | 一部の「読み取り用」の API で、関連するデータを一緒に返す指定（リレーションの読み込み）の処理に問題があり、条件によっては、データを読むだけのはずのリクエストで、関連するテーブルを消す操作が動いてしまう |
| 起こりうること | 読み取りの権限しかない利用者が、書き込み権限なしに、関連テーブルを空にするなど元に戻せないデータの消失を起こせる |
| 対象 | 12.45.0 以上 12.68.0 より前、13.27.0 より前 |
報道（Laravel News）によると、これは Laravel 12.45 で加わった JSON:API リソース（API の返し方を決まった形式にそろえる機能）にかかわる問題です。修正は Laravel のプルリクエスト #61322・#61323 で行われ、12.68.0 のリリースノートには「Fix resource loading（リソース読み込みの修正）」と書かれています［Laravel のリリース］。
12.68.0 以降、13.29.0 以降に上げれば、2件ともまとめて直ります。
Laravel のバージョンの確かめ方
Laravel のバージョンは、Web サイトを外から見ても基本的には分かりません。サーバーや開発用のパソコンで、アプリのフォルダに入って確かめます。
- Composer で見る：アプリのフォルダで
composer show laravel/frameworkを実行すると、入っている laravel/framework のバージョン（versions の行）が表示されます。Composer は PHP の部品（パッケージ）を管理する道具です。 - artisan で見る：
php artisan --versionでも「Laravel Framework 12.xx.x」のように表示されます。 - まとめて調べる：
composer auditを実行すると、入っている部品に公表済みの脆弱性があるかを一覧で確かめられます。 - ファイルで見る：
composer.lockの中のlaravel/frameworkの項目にもバージョンが書かれています。
本番のサーバーと開発環境でバージョンがずれていることがあります。確かめるのは、実際に動いている本番のほうです。
今すぐやること
- 使っているか確かめる。Laravel のバージョン、
config/auth.phpの token ドライバーの有無、データベースの種類を確認します。 - 検証用の環境で更新する。同じ系列の中の更新（12.x の中、13.x の中）なら、通常は
composer update laravel/frameworkで修正版以降に上がります。composer.jsonの指定（^12.0など）で上げられる範囲が決まります。ほかの部品も一緒に更新されることがあるので、まず検証用の環境で試します。 - 動作を確かめる。ログイン、API、管理画面など、主な機能が動くかテストします。
- 本番に反映する。更新後の
composer.lockを本番に反映し、composer show laravel/frameworkで修正版になったことを確認します。
すぐに更新できない場合：アドバイザリには、この脆弱性の回避策は載っていません。更新が対策です。token ドライバーの guard を使っているなら、更新を最優先にしてください。
対象の構成でしばらく古いまま動いていた場合は、利用者のデータや API の利用記録に、身に覚えのない操作がないかも確かめてください。侵害されたかもしれないときの一般的な進め方は侵害チェックの記事にまとめています。
悪用の状況（公式・報道・未確認）
| 区分 | 内容 |
|---|---|
| 公式（Laravel） | アドバイザリに、悪用を確認したという記載はない |
| 公式（CISA） | 悪用が確認された脆弱性の一覧（KEV）には、10月24日 4時30分（日本時間）更新の版で、2件とも載っていない。CVE-2026-114508 の CVE レコードに CISA が付けた評価（10月23日付）は、悪用「none（確認なし）」、自動化「yes（可能）」、技術的な影響「partial（部分的）」 |
| 報道 | Laravel News は10月20日付の記事で2件を紹介し、早めの更新と config/auth.php の確認、composer audit の実行を勧めている。悪用の有無には触れていない |
| 未確認 | 国内の JPCERT/CC・IPA の注意喚起は、この記事の時点で当サイトでは確認できていない |
Laravel では過去にも、別の脆弱性（CVE-2021-3129 など）が KEV に載ったことがあります［CISA KEV］。修正の中身が公開されると攻撃が始まりやすくなるので、悪用の報告を待たずに更新してください。
PHP2Shell との関係
同じ時期に、PHP 本体の脆弱性（通称 php2shell）の修正版も出ています。Laravel は PHP の上で動くため混同しやすいのですが、直す場所が違う、別々の問題です。
| Laravel（今回） | php2shell | |
|---|---|---|
| どこの問題か | Laravel（アプリ側の部品） | PHP 本体（サーバー側のソフト） |
| CVE | CVE-2026-114509 / 114508 | CVE-2026-109618 / 109619 |
| 直し方 | Composer で laravel/framework を 12.68.0 / 13.29.0 以降に | PHP を 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 以降に |
| だれが直すか | アプリの開発・保守の担当 | サーバーの管理者、レンタルサーバー会社 |
Laravel を更新しても PHP の問題は直りませんし、PHP を更新しても Laravel の問題は直りません。両方の更新が必要です。なお Laravel 13 は PHP 8.3 以上で動くため、PHP を上げるときは Laravel の対応範囲も確かめてください［Laravel 公式ドキュメント］。PHP の件はphp2shellの解説に、外から見える PHP のバージョンはPHPかんたん診断で確かめられます（Laravel のバージョンはこの診断では分かりません）。
経緯（日本時間）
| 日時 | 出来事 |
|---|---|
| 8月25日 23:17 | Laravel 13.27.0 を公開（CVE-2026-114508 の修正を含む）［Laravel のリリース］ |
| 8月25日 23:19 | Laravel 12.68.0 を公開（2件の修正を含む）［Laravel のリリース］ |
| 8月26日 5:58 | Laravel 13.29.0 を公開（CVE-2026-114509 の修正を含む）［Laravel のリリース］ |
| 10月19日 22:32・22:33 | Laravel が GitHub で2件のアドバイザリを公開［Laravel の GitHub アドバイザリ］ |
| 10月20日（付・時刻の記載なし） | Laravel News が2件を報じる |
| 10月22日 6:45・6:49 | CVE-2026-114508・CVE-2026-114509 の CVE レコードが公開［CVE.org］ |
日本時間は、各ページの協定世界時の記載に9時間を足しています。
よくある質問
WordPress のサイトは関係ありますか？
WordPress は Laravel を使っていないので、今回の件とは関係ありません。ただし WordPress は PHP で動くので、PHP 本体の脆弱性（php2shell）の更新は必要です。
うちのシステムが Laravel かどうか分かりません。
外からは分からないことが多いので、開発した会社や保守の担当者に「Laravel で作っているか」「laravel/framework のバージョンはいくつか」「token ドライバーの認証を使っているか」を聞くのが確実です。
Laravel Sanctum を使っています。更新しなくていいですか？
報道では Sanctum はこの認証回避の対象に挙がっていませんが、同じ日のデータ削除の脆弱性や、今後の修正もあります。12.68.0 以降または 13.29.0 以降に上げておくことをおすすめします。
9月に Laravel を更新しました。もう大丈夫ですか？
修正版は8月25日〜26日に出ているので、12.68.0 以降または 13.29.0 以降になっていれば、2件とも直っています。composer show laravel/framework で本番のバージョンを確かめてください。
Laravel 11 や 10 を使っています。
Laravel 10・11 はセキュリティ修正の期限が過ぎていて、今回の修正版も出ていません。Laravel 12 以降への移行を計画してください。移行に時間がかかる場合は、その間 token ドライバーの API を外から呼べないようにするなどの一時しのぎも考えられますが、公式の対策ではありません。
Laravel や PHP の更新、サーバーの状態の確認でお困りでしたらご相談ください。
参考にした情報
- Laravel GitHub アドバイザリ GHSA-f9x3-7vq9-cph6「Token-based API guard Auth Bypass」
- Laravel GitHub アドバイザリ GHSA-5wcm-3v2w-8362「Unauthorized Data Destruction」
- CVE.org CVE-2026-114509 / CVE-2026-114508
- Laravel v12.68.0 / v13.27.0 / v13.29.0（GitHub のリリース）
- 修正コミット 8dbb08b / 9b21ce0 / プルリクエスト #61323
- Laravel 公式ドキュメント「Release Notes（Support Policy）」
- CISA Known Exploited Vulnerabilities Catalog
- 報道：Laravel News「Critical Token Guard Auth Bypass Fixed in Laravel 13.29 and 12.68」（英語）
