2026年10月22日（日本時間）、Webシステムを作るためのフレームワーク「Laravel」に、ログイン（認証）をすり抜けられる脆弱性（＝システムの安全上の欠陥）「CVE-2026-114509」が公表されました。深刻度は CVSS v4.0 で 9.2（緊急）とされています。
「PHPの件でLaravelのことを確認したばかりなのに、今度はLaravel自体の脆弱性？うちのシステムは関係あるの？」
先に結論をお伝えします。影響を受けるのは、Laravelの標準機能のうち「token」という方式でAPIのログインを作り、データベースにMySQLまたはMariaDBを使っているシステムです。修正版（Laravel 12.68.0・13.29.0）はすでに出ています。まずは、自社のシステムがこの方式を使っているか、Laravelのバージョンはいくつかを、開発会社に確認しましょう。サポートが終わったLaravel 11以前には、公式の修正版が案内されていません。
この記事では、公式の発表をもとに何が問題なのかを整理し、発注者が開発会社に確認したいことを、チェックリストと質問例つきで解説します（内容は2026年10月25日時点の情報に基づきます）。
CVE-2026-114509 の公式発表の要点
この脆弱性は、Laravelの開発元がGitHub上で公開したセキュリティ情報（アドバイザリ）と、CVEの公式記録で公表されています。
| 項目 | 公式発表の内容 |
|---|---|
| 対象 | Laravel（laravel/framework）の標準機能「TokenGuard」（＝APIのログインを、APIトークンという合言葉のような文字列で確かめる仕組み） |
| 起きること | 細工したデータを送ると、正しいAPIトークンを知らなくても、別の利用者としてログインできてしまう（認証の回避・アカウントの乗っ取り） |
| 条件 | 「token」方式の標準的な設定で使っていて、データベースが特定の設定のMySQLまたはMariaDBであること |
| 攻撃する側の条件 | ログインしていない第三者でも可能 |
| 影響を受けるバージョン | 12.68.0より前のすべてのバージョン、13.0.0以上13.29.0未満 |
| 修正版 | 12.68.0／13.29.0 |
| 深刻度 | CVSS v4.0 で 9.2（緊急） |
修正版の12.68.0と13.29.0は、2026年8月25日に公開されていました。CVEとしての公表は10月22日（日本時間）です。つまり、8月下旬以降にLaravelを更新しているシステムは、すでに修正が入っている可能性があります。
なお、執筆時点では、米国CISAの「悪用が確認された脆弱性」の一覧（KEV）には載っておらず、実際に悪用されたという公式の報告はありません。米国の脆弱性データベース（NVD）は、まだ独自の評価をしていません（「Awaiting Analysis」）。
📰 出典：NVD「CVE-2026-114509」
CVE番号やCVSSの点数の読み方は、次の記事で解説しています。
どんなシステムが影響を受けるのか
「token」方式でAPIのログインを作っているか
Laravelには、APIのログインを作る方法がいくつかあります。今回の公式発表が対象にしているのは、Laravel本体に入っている「token」方式（TokenGuard）です。
| 方法 | 概要 | 今回の公式発表での扱い |
|---|---|---|
| token方式（TokenGuard） | Laravel本体に入っている、昔からある簡単なAPIトークンの仕組み | 対象 |
| Laravel Sanctum | Laravel公式の追加パッケージ。画面（SPA）やスマホアプリ向けのAPIのログインで、現在よく使われる | 公式発表では触れられていない |
| Laravel Passport | Laravel公式の追加パッケージ。OAuth2という本格的な認可の仕組み | 公式発表では触れられていない |
| 画面からのログイン（Cookie・セッション） | 一般的な、ブラウザでIDとパスワードを入れてログインする仕組み | 公式発表では触れられていない |
📰 出典：Laravel「Authentication」（13.x）
Laravelの公式ドキュメントでは、APIのログインにはSanctumかPassportを使うよう案内されています。そのため、比較的新しいシステムではtoken方式が使われていないことも多いと考えられます。一方で、数年前に作られたシステムや、外部のシステムとデータをやり取りする「連携用のAPI」だけを簡単に作ったシステムでは、token方式が使われていることがあります（筆者の見解）。どの方法を使っているかは、外から見ても分からないので、開発会社に確認してください。
データベースがMySQL・MariaDBか
公式発表では、問題が起きるのは特定の設定のMySQLまたはMariaDBを使っている場合とされています。MySQL・MariaDBは、Laravelで作るシステムで広く使われているデータベースです。PostgreSQLなど別のデータベースを使っている場合が対象になるかは、公式発表では書かれていません。
Laravelのバージョンはいくつか
| Laravelのバージョン | 今回の状況 | Laravel自体のセキュリティサポート |
|---|---|---|
| 13.x | 13.29.0以上なら修正済み | 継続中 |
| 12.x | 12.68.0以上なら修正済み | 2027年2月24日まで |
| 11.x | 影響を受ける範囲に入るが、公式発表に修正版の記載はない | 2026年3月12日で終了 |
| 10.x以前 | 同上 | 終了 |
📰 出典：Laravel「Release Notes」（サポートポリシー）
📰 出典：Packagist「laravel/framework」（各バージョンの公開日）
Laravel 11以前で、token方式を使っているシステムは、Laravel自体のバージョンアップを検討する必要があります。Laravelのバージョンアップは、1つずつ段階を踏んで行うのが一般的で、作業と動作確認に時間がかかります。
発注者にとって何が変わるか／変わらないか
ここからは、公式発表をもとにした筆者の見解です。
変わらないこと：全部のLaravelのシステムが危ないわけではない
今回の脆弱性は、token方式でAPIのログインを作り、MySQL・MariaDBを使っている、という条件がそろった場合の問題です。Laravelで作ったシステムだからといって、すべてが対象になるわけではありません。また、修正版はすでに出ており、実際に悪用されたという公式の報告もありません。まずは対象かどうかの確認から始めましょう。
変わること1：対象なら、修正版への更新を急ぐ
対象になる場合、ログインしていない第三者が、ほかの利用者になりすましてAPIを使えるおそれがあります。顧客情報や取引データを扱うAPIであれば、情報漏えいや不正な操作につながりかねません。対象と分かったら、通常の定期メンテナンスを待たず、修正版（12.68.0・13.29.0以上）への更新を開発会社と相談しましょう。
あわせて、更新するまでの間に不審なログインやAPIの使われ方がなかったか、記録（ログ）を確認してもらうと安心です。
変わること2：Laravel 11以前は、バージョンアップの計画が必要になる
Laravel 11以前を使っていて対象になる場合は、修正版を「当てるだけ」では済まない可能性があります。PHPの脆弱性への対応で、すでにPHPのバージョンアップを検討している場合は、Laravelのバージョンアップもあわせて計画すると、作業をまとめられることがあります。PHPの脆弱性については、次の記事で解説しています。
フレームワークのバージョンアップにかかる費用の考え方は、次の記事も参考にしてください。
「『token方式を使っているか』『MySQLかMariaDBか』『Laravelのバージョンはいくつか』の3つが分かれば、対象かどうかはすぐに判断できます。」
今やるべきこと・まだ様子見でいいこと
| 区分 | 内容 |
|---|---|
| 今やること | 自社のLaravelのシステムで、APIのログインにtoken方式を使っているか、開発会社に確認する |
| 今やること | データベースがMySQL・MariaDBか、Laravelのバージョンがいくつかを確認する |
| 対象なら急ぎ | 修正版（12.68.0・13.29.0以上）に更新し、不審なログインやAPIの利用がなかったか記録を確認してもらう |
| 対象なら早めに | Laravel 11以前の場合は、Laravel自体のバージョンアップの計画と見積もりを相談する |
| 様子見でよい | token方式を使っておらず、修正済みのバージョンなら、追加の対応は基本的に不要 |
発注者がやること チェックリスト
- ☐ 自社のシステムがLaravelで作られているか、Laravelのバージョンはいくつかを把握した
- ☐ APIのログインに、Laravel本体のtoken方式を使っているか確認した
- ☐ データベースがMySQL・MariaDBか確認した
- ☐ 対象の場合、修正版（12.68.0・13.29.0以上）への更新をいつ行うか決めた
- ☐ 対象の場合、不審なログインやAPIの利用がなかったか、記録を確認してもらうよう依頼した
- ☐ Laravel 11以前の場合、バージョンアップの計画を相談した
開発会社への質問例
- 「当社のシステムは、Laravelのどのバージョンで動いていますか？データベースはMySQL・MariaDBですか？」
- 「APIのログインには、Laravel本体のtoken方式を使っていますか？それともSanctumやPassportですか？」
- 「CVE-2026-114509の対象になりますか？対象なら、修正版への更新はいつできますか？」
- 「更新するまでの間に、不審なログインやAPIの使われ方がなかったか、記録で確認できますか？」
- 「Laravel 11以前の場合、バージョンアップにどのくらいの作業と期間がかかりますか？」
まとめ
Laravelに、APIのログインをすり抜けられる脆弱性（CVE-2026-114509、CVSS v4.0で9.2）が公表されました。対象は、Laravel本体のtoken方式でAPIのログインを作り、特定の設定のMySQL・MariaDBを使っているシステムで、修正版の12.68.0と13.29.0はすでに出ています。
Laravelで作ったシステムがすべて危ないわけではありません。発注者がやるべきことは、token方式を使っているか、データベースとLaravelのバージョンは何かを開発会社に確認し、対象なら修正版への更新を急ぐことです。サポートが終わったLaravel 11以前の場合は、バージョンアップも含めて早めに相談しましょう。
Laravelのアップグレードや、古いフレームワークで動くシステムのリプレイスはご相談ください
株式会社THIRD HERO（当サイトの運営会社）では、Laravelのバージョンアップや、サポートが終わったフレームワークで動くシステムの更新・作り直し（リプレイス）のご相談を受け付けています。「今のシステムがどのバージョンで動いているか分からない」「バージョンアップと作り直しのどちらがよいか判断したい」といった段階からでも構いません。現状の確認から開発、公開後の運用保守まで一貫して対応します。
あわせて読みたい関連記事
