Laravel TokenGuard authentication bypass through non-string API credentials

Stackwatch@stackwatch_de

Laravel CVE-2026-114509: Auth-Bypass im TokenGuard (CVSS 9,2). Betroffen nur mit TokenGuard + MySQL/MariaDB. Fix: 12.68.0 / 13.29.0. Kein Workaround im Advisory, nur Update. Nicht in KEV, kein PoC bekannt.

一般社団法人ソフトウェア協会 AIビジネス研究会 公式アカウント@saj_aibusiness

【今日のAI今北産業｜0321:認証すり抜け】 正しいAPIトークンがなくても、別の利用者として認証される恐れ Laravel標準TokenGuardとデータベースの型解釈が生んだ重大な欠陥 10月19日の公式警告を受け、実装と更新状況の棚卸しが必要に ← イマココ ■1．ログイン画面を破らなくても、ログインしたことになる 2026年10月19日、PHPの代表的なWebアプリケーションフレームワークLaravelは、標準のAPI認証に関する重大な問題を公表した。公式管理番号はGHSA-f9x3-7vq9-cph6。後にCVE-2026-114509として登録された。CVSS v4.0の基本評価は9.2で、区分はCritical。影響条件が成立すると、正規のAPIトークンを知らない外部の利用者が、すでに存在する別のアカウントとして認証される可能性がある。 ここで注意したいのは、すべてのLaravel製サイトに対して、誰でも無条件で侵入できると発表されたわけではないことだ。問題があるのは、Laravelに組み込まれたTokenGuardという認証部品を特定の設定で使用し、さらに一部のMySQL／MariaDB構成が関係する場合である。影響を決めるのは製品名だけではない。使っている認証方式、アプリケーションが受け付ける値、データベースの型変換、配布済みの修正が適用されているかという複数の条件だ。 それでも警告の重みは大きい。APIは企業サイトの裏側で商品、顧客、社員、注文、業務システムをつないでいる。侵入者が認証処理を通過できるなら、パスワードを盗まずに保護されたデータや機能に近づく可能性が生まれる。今回の事件が教えるのは、入口に鍵を置いていても、鍵を判定する仕組み自体が誤っていれば防御にならないということだ。 ■2．認証と認可は、似ているが違う まず混同されやすい二つの言葉を整理する。認証（Authentication）は「あなたは誰か」を確認する処理。認可（Authorization）は「確認できたあなたが、何をしてよいか」を決める処理である。社員証を見て人物を確認するのが認証で、社員証の持ち主が機密室に入れるかどうか決めるのが認可に近い。 APIでも原理は同じだ。通常はアプリが提示したトークンなどを調べ、その値が利用者に紐づく正しい秘密情報なのか確かめる。認証に成功すると、次の処理は「この利用者からの要求だ」という前提で進む。利用者番号、契約、権限、注文履歴、所属組織を読み出し、その人が許可された操作かどうかを判定する。 もし認証の段階で別人を本人として扱えば、後続の認可が正確でも悪い結果になり得る。認可機能は、すでに誤認された利用者について正当な権限を判定してしまうからだ。権限の弱いアカウントなら影響は限定されるかもしれないが、管理者、取引責任者、特権ユーザーとして認識されれば、許可される操作の幅が広がる。だから認証バイパスは、単なるログイン手続きの不備にとどまらない。 「認証すり抜け」と呼ぶことで分かりやすくなる反面、ログイン画面への総当たりやパスワードの使い回しと混同しやすい。今回問題なのは、正しい秘密の値を知らなくても、プログラムの値の扱いによって本人確認の結果がねじ曲がる可能性である。 ■3．そもそもAPIトークンとは何か APIはApplication Programming Interfaceの略で、システムの機能を別のソフトウェアへ提供する接点のことだ。人間が画面のボタンを押す代わりに、スマートフォンのアプリ、取引先のサービス、会計ソフト、自動処理などがAPIを通じてサーバーへ要求を送る。会員データの取得や注文登録を行うAPIには、誰が呼び出しているか確認する仕組みが必要になる。 そこで使われる方法の一つがAPIトークンだ。通常、サーバーが発行した秘密の文字列をリクエストに添えて送り、サーバー側で対応する利用者や権限を照合する。実際にはトークンの保存方式、暗号化・ハッシュ化、期限、権限範囲など、さまざまな設計がある。トークンという言葉だけで、すべてが同じ実装というわけではない。 API経路は必ずしも通常のログイン画面を通らない。だから「ログインページに多要素認証を追加したからAPIも安全」という考え方は成立しない。APIがどのGuardで本人確認を行い、どの条件で拒否するのかを別途点検する必要がある。画面とAPIが同じ利用者情報を参照していても、認証の入口は異なる場合がある。 また、APIは人間の操作より頻繁に利用される。外部連携や自動ジョブに組み込まれた認証の欠陥は、発見の遅れや影響範囲の把握を難しくする。画面上に異常が出ないまま、裏側の呼び出しだけが不正に成立する可能性を運用設計に織り込む必要がある。 ■4．LaravelのGuardは一種類ではない LaravelはPHPでWebサービスを構築するためのオープンソースのフレームワークで、ルーティング、データベース、認証、ジョブ、通知などの土台を提供する。その認証を担う部品の呼び方がGuardである。Guardは「要求をどの方法で本人確認するか」を定める仕組みで、ブラウザのセッションを使う方式、API向けのトークン方式、追加パッケージが提供する方式などがある。 今回の公式警告が名指ししたのは、フレームワーク標準のTokenGuardだ。これは、API要求からトークンを取得し、対応する利用者を検索する認証部品である。設定によっては、Guardの名前がapiとなり、API経路で使われることがある。ただし、設定名がapiというだけでは実際の実装は確定しない。何という名前のGuardなのかより、ドライバーに何が指定され、どのクラスが実行されているかが重要だ。 LaravelにはSanctumやPassportという認証向けの仕組みもある。SanctumはシンプルなAPIトークンやSPAの認証で、PassportはOAuth 2.0を必要とする構成で利用される。PassportにもTokenGuardという名前のクラスがあるが、フレームワーク本体のIlluminate\Auth\TokenGuardとは別物だ。この名称の類似が誤解を生みやすい。 Laravelを採用しているという事実だけで一括判定するのも、Sanctumを利用しているからすべて無関係と決めつけるのも避けたい。追加パッケージから他のGuardを参照する構成や、独自認証を組み合わせた構成もあり得る。判断するのはコードと実際の設定である。 ■5．本質は「正しい型しか受け取らない」という約束 今回の問題は、認証のために受け取った値の型が、想定と違っていても、そのまま処理へ進み得たことにある。トークンとして期待されているのは文字列なのに、別の種類の値を渡された場合、最初の段階で適切に拒否できない経路が存在した。 プログラミングでは、数字、文字列、配列、真偽値などを区別する。人間には「鍵っぽい文字」かどうか判断しやすくても、プログラムでは値が存在するかどうかだけの緩い確認と、文字列であることを確かめる厳密な確認は違う。認証ではこの差が致命的になり得る。 本来の安全な設計は、認証に用いる値が期待された形式でなければ検索を始めず拒否することだ。型が違う場合に自動変換して都合よく解釈したり、検索条件として解釈し直したりすることは避ける。処理の次の段階に到達する前に、入力が満たすべき条件を固定するのである。 この教訓はPHPに限らない。JavaScript、Python、Java、Goなどでも、外部入力が境界をまたぐときに、受け付ける型と値の範囲を厳密に決めておくことが重要だ。データがJSONで来たのか、フォーム値なのか、ヘッダーなのかという受け取り方も影響する。単に「入力をサニタイズする」だけでは足りず、そもそもどんな種類のデータを受け取る仕様なのかを明文化しなければならない。 ■6．データベースの「親切な解釈」が安全性を崩す Laravelの公式情報では、一部のMySQL／MariaDB構成で問題が顕在化すると説明されている。背景には、アプリケーションから渡された値が、データベースの検索処理において想定しない比較へ結び付くことがある。プログラム側は特定の利用者に対応するトークンを探しているつもりでも、入力の型が変わると検索条件の解釈が変化し、本来一致してはいけない行を見つける可能性がある。 データベースには利便性のために型を変換して比較する挙動が存在する。たとえば文字列と数値を比較するとき、製品や設定によって変換の方針が違う場合がある。通常の業務データ処理では便利でも、認証の判断へ入り込むと危険になる。プログラムの入口が厳密でも、途中で型の意味が失われるなら、最終的な検索結果だけを信用できない。 今回の報告は「SQLインジェクションが自由に実行できる」と一般化するものではない。文字列を好きなSQL文として実行させる問題と、想定外の型が認証検索の条件を変えてしまう問題は区別するべきだ。攻撃の詳細な手順を知らなくても、入力値の検証、認証用検索、データベースの比較処理が一つの安全性の境界になっていると理解すれば、実務判断に役立つ。 設計レビューではアプリケーションコードの書き方だけでなく、DBの種類、テーブル定義、利用するORM、フレームワークの変換処理まで、認証経路に沿って見る必要がある。 ■7．何ができてしまうのかは、API側の権限で変わる 公式アドバイザリが問題として挙げたのは、正しいトークンなしに既存の別アカウントとして認証され、認証済み利用者向けの経路に入れる可能性だ。いわゆるAccount Takeover、アカウント乗っ取りへつながり得る。しかし、認証を通過した後にどこまで操作できるかは、そのアカウントが持つ権限と、APIが提供する機能に左右される。 閲覧専用のAPIなら顧客情報、社内文書、契約条件などの機密が問題になる。登録・変更を受け付けるAPIなら注文、配送先、振込先、在庫、社員情報などの整合性に影響が出る。管理者向けAPIでは、複数利用者に対する操作や設定変更へ波及する可能性も考える必要がある。実際の被害が確認されたという話ではなく、リスク評価上の想定である。 加えて、操作履歴が「認証された別の利用者」のものとして残ると、監査が難しくなる。後から不正な変更を見つけても、ログの利用者名だけで本人の操作だと断定できないためだ。IPアドレス、端末、User-Agent、アクセス元、時間帯、トークンの取り扱い、通常の利用傾向を複合的に確認する必要がある。 認証は本人確認という一段階だが、その結果が決済、会員管理、管理者権限、業務の証跡まで連鎖するため、深刻度が高い。重要なのは攻撃可能な理論上の操作と、現実に発生した被害を分けて説明することだ。 ■8．CVSS 9.2という数字は何を意味するか 今回の公式アドバイザリにはCVSS v4.0で9.2という重大度が示されている。CVSSは脆弱性の技術的な危険性を共通の尺度で評価する仕組みで、9点台はCriticalという最上位区分に該当する。ネットワークから悪用され得ること、事前の正規権限が不要なこと、条件が成立した場合に機密性、完全性、可用性へ大きな影響が及び得ることなどが評価に関わる。 一方、CVSSは「今すでに世界中で大規模な侵入が発生している確率」ではない。ある企業のシステムに実際の影響があるか、攻撃者が到達できる状態か、修正版が適用済みか、守るべき情報は何かを数値だけで判断してはいけない。運用現場では技術的深刻度に加え、公開範囲、事業への重要性、利用者の数、障害時の影響を重ねて優先度を付ける。 同じLaravelを使うサイトでも、標準TokenGuardを使わない構成なら今回の影響条件とは異なる。逆に、一般公開していないと思っていたAPIが外部から到達可能なら、危険度の見積もりは変わる。脆弱性の数字は対応開始の合図だが、修正対象を決める最終根拠は自社の構成情報にある。 ■9．修正が公表より前に存在した、重要な時間差 今回の経緯にはもう一つ、運用管理上の示唆がある。Laravelの修正版として案内された12.68.0と13.29.0は、2026年8月25日にリリースされた。一方、重大な認証バイパスに関するセキュリティアドバイザリが公開されたのは10月19日。CVEの登録情報もその後更新された。つまり、公開警告を読んで初めて危険性を知った組織がある一方で、すでに安全な版へ更新されていた組織も存在し得る。 この時間差から「公開日以降に更新しなければ絶対に未対策」という考え方も、「問題を知らなかったのだから安全」という考え方も成り立たない。重要なのは、本番で動作しているフレームワークの正確なバージョンと、修正が含まれたパッケージをデプロイした実績だ。開発端末で更新されていても、本番のコンテナイメージや配布済みコードが古ければ意味がない。 また、修正の詳しい理由が後から公になることもある。リリースノートに脆弱性の全貌が明記されない時期があっても、開発者は安定版の更新履歴を継続的に見ておく必要がある。セキュリティアドバイザリの監視だけでなく、依存関係の更新、テスト、段階的な配布を普段から行える組織ほど、公開時点ですでに危険を減らせている可能性が高い。 今回の事例では、修正公開日、警告公開日、CVE登録日を同じ出来事としてまとめず、それぞれの役割を区別することが正確な報道にも欠かせない。 ■10．「Laravelを使っているなら全部危険」は誤り Laravelという名称だけで、利用企業の危険性を判定するのは無理がある。Laravelはフレームワークであって、完成済みの一種類のアプリケーションではない。開発会社ごとに採用した認証パッケージも、設定も、DBも、アクセス制御も違う。標準TokenGuardが使われていないのに、Laravel製だという理由だけで今回の欠陥を再現できるとは言えない。 現在のLaravel公式ドキュメントは、一般的なAPI開発でSanctumを案内している。SanctumはCookieベースのセッション認証やAPIトークン認証を提供し、PassportはOAuth 2.0の機能が必要な用途向けだ。これらと標準TokenGuardは、実装上の部品が異なる。Laravelの公式アドバイザリは標準TokenGuardについて述べたもので、SanctumとPassportが一律に同じ脆弱性を持つと公表したわけではない。 ただし「Sanctumを導入している」という一行の情報だけで無条件に安全と宣言するのも早い。認証設定で別のGuardを呼び出すことがあるし、複数のAPI経路の一部だけ過去の方式が残されていることもある。Passportにも独自のTokenGuardというクラス名があり、同名であることを根拠に対象を混同する事故も考えられる。 点検の基本は、実際の認証ドライバー、認証を要求するルート、ユーザープロバイダー、接続DB、導入済みパッケージの対応関係を追うこと。名称による推測ではなく、設定値と実行コードを見て判定する。 ■11．古いシステムほど設定が残りやすい 情報システムは完成した時点で固定されるものではない。新しい機能や認証方式を追加しながら、古いAPIも取引先との互換性のために残る。画面を作り直した後も、昔のスマホアプリ用APIが稼働し続けていることがある。担当者の交代や制作会社の変更が重なると、その経路が標準TokenGuardを使っているかどうかさえ把握されなくなる。 Laravel 11の公式セキュリティサポートは2026年3月12日に終了した。12系は2027年2月24日まで、13系は2028年3月17日までが公式のセキュリティサポート期間と案内されている。利用するメジャー系統によって、今後の修正を受け取れる見通しが異なる。 古いLaravelアプリケーションを抱えた組織では、単純にComposerのバージョン指定だけを変えれば安全になるとは限らない。PHPの稼働版、依存するパッケージ、ログイン処理、DBの互換性、ジョブや通知などの周辺機能も合わせて検証する必要がある。特に認証系の変更は、正規利用者がログインできなくなる障害と、意図しない利用者が通ってしまう欠陥の両方を防がなくてはならない。 技術負債は単に古いコードの量ではない。どの認証設定がどこで使われているか追跡できないこと、更新時に影響を調べるテストがないこと、運用主体が曖昧なことも重大な負債になる。今回の出来事は、その負債が安全性へ直結する例として理解できる。 ■12．まず確認すべきは本番の事実 実務対応は、危険度の高いニュースに慌てて本番を更新することから始めるのではない。最初に何が動いているかを確定する。Laravelを使うサービスの一覧、公開APIの有無、現在配布されているlaravel/frameworkの版、認証に使うGuard、接続するデータベース、運用担当者を同じ台帳にまとめる。開発環境、テスト環境、本番環境を混同しないことも重要だ。 Laravelの構成では、Composerで管理する依存関係が実際のフレームワークの版を決める。したがってcomposer.jsonに書いた希望バージョンだけで判断せず、composer.lockや本番に展開されたvendorの実態を見る。開発サーバーが12.68.0でも、本番のイメージが12.60.0なら本番側の判断が必要になる。逆に13.29.0以降の更新が済んでいれば、公式指定の修正は取り込まれている。 次に認証の経路を確認する。config/auth.phpなどでGuardのdriverがtokenに設定されていないか、該当GuardがどのAPI経路に指定されているかを洗う。auth:apiと書かれている場合も、apiという名前のGuardがどのドライバーへ結び付くか確認する。データベースにはMySQL／MariaDBが含まれるか、認証で照合する利用者データがどのように保持されているかも対象となる。 ここで求められるのは、無理に攻撃を再現することではない。構成を把握し、影響条件を見極め、公式修正版を適用し、正規と不正の両方をテストすることだ。PoCを本番へ投入すると、利用者情報や業務データへ想定外の影響を与える可能性がある。検証は隔離された承認済みの環境で行う。 ■13．更新は「入れた」ではなく「効いた」で判定する 更新する際には、まずデータとシステムのバックアップ、切り戻し手段、正常系の確認項目を揃える。Laravel 12系なら公式指定の12.68.0以降、13系なら13.29.0以降を基準とし、可能ならその系統で利用可能な最新の安全なリリースを選ぶ。サポート終了系統は別途移行計画を立てる。影響する依存パッケージの衝突やPHPの要求条件を確認してから適用する。 適用後は、開発環境でコマンドが成功したことだけをもって完了としない。実際の公開APIで認証が正常に機能するか、誤った型の値は拒否されるか、権限のない利用者が情報を閲覧できないか、期限切れトークンが通らないか、一般利用者の業務に障害が出ていないかを確かめる。 同じアプリケーションが複数台で動いている場合には、一部のサーバーだけ古いまま残る可能性もある。負荷分散環境、コンテナ、サーバーレス、ジョブ用環境まで含め、実行中の全インスタンスの版を確認することが必要だ。キャッシュや古いイメージが残っていると、ソース管理上の修正が本番へ反映されていないケースもある。 完了判定は「更新作業をした」ではなく「本番で修正版が稼働し、認証テストを通過した」である。更新日時、対象サービス、確認したバージョン、テスト結果、担当者、戻す手順を記録できれば、次の脆弱性が出た際の対応時間も短縮できる。 ■14．すでに不正なアクセスがあったか、どう考えるか 公式アドバイザリは脆弱性と影響条件を説明しているが、そこに被害件数や特定企業の侵入事実が列挙されているわけではない。技術的な危険性が高いことと、現実の攻撃による被害が確定したことは別の話だ。公開されている実験的な検証やPoCも、直ちに全世界で悪用されていることを意味しない。 一方で、「被害情報が見当たらないから調査不要」と判断するのも危険である。対象条件に該当するシステムなら、異常なログイン成功、普段と異なるIPからのAPI操作、利用者の行動パターンと一致しない更新、認証失敗と成功の不自然な連続、権限の高いAPI呼び出しを点検する価値がある。個々のログが正常な業務で発生する場合もあるため、単独の兆候だけで侵入と断定してはいけない。 ログ調査では、記録が十分かどうかも分かる。利用者IDしか残していなければ、認証すり抜けが起きた際に本人の行動と区別しにくい。リクエストID、認証方式、操作された資源、時刻、アクセス元などを適切な期間保持していれば、調査の手掛かりになる。もちろん個人情報や秘密のトークンそのものをむやみにログへ残さない配慮も必要だ。 もし不正操作の兆候があれば、影響範囲を保全し、証拠を確保し、対応体制を整えたうえで、トークンの失効やアカウント保護、利用者への連絡を判断する。原因と範囲の確認より先に全ログを消したり、証拠を失わせる操作をしたりしないことが大切だ。 ■15．PHP2Shellとは別の問題、守る層も違う 2026年10月にはPHP本体の深刻な欠陥PHP2Shellも公表された。PHP2ShellはPHPの要求処理に関わる脆弱性であり、アプリケーションのログイン処理が始まる前の段階に危険が存在する。一方、今回のCVE-2026-114509は、Laravelフレームワークに組み込まれた特定の認証ロジックに関するものだ。両者を「PHPサイトが危険」という一つの言葉へまとめると、必要な対応を見誤る。 PHP本体を更新しても、Laravel側の未修正TokenGuardが自動的に直るとは限らない。逆にLaravelを更新しても、PHP本体の別の脆弱性が消えるわけではない。OS、Webサーバー、PHP実行環境、フレームワーク、依存パッケージ、アプリケーション固有のコード、認証設定、DB権限をそれぞれ独立した管理対象として把握することが必要だ。 WAFは不審な要求の検知や遮断に役立つ場合があるが、認証処理の型検証そのものを直すものではない。既知の攻撃パターンを止められても、認証経路の正しさは別途確認する必要がある。また、ログイン画面にCAPTCHAや二要素認証を追加しても、画面を経由しないAPIのTokenGuardに直接影響しない構成は存在する。 セキュリティ製品の導入、アプリの更新、認証設計の見直しは代替関係ではなく、異なる層を守る対策である。企業に必要なのは「何か一つ入れてあるから安心」ではなく、各層の修正状況と残存リスクを説明できる状態だ。 ■16．AIエージェントの普及はAPI認証の価値を高める AIエージェントが外部システムを操作する際、多くの処理はブラウザの画面ではなくAPIを通じて行われる。顧客情報を検索する、チケットを発行する、見積もりを作る、倉庫の在庫を確認する、社内ナレッジを参照するといった一連の作業を複数サービスへまたがって実行できる。こうした自動化は生産性を高める一方、認証の結果を誤ると操作の規模と速度が拡大しやすい。 ここでの論点は、今回のLaravel脆弱性がAIエージェント固有のものという意味ではない。AIを使わない通常のAPIでも同じ問題は起き得る。しかし企業がAIへ業務実行を任せるほど、背後にあるAPIの本人確認、権限、監査ログ、承認、実行範囲の重要性は増す。AIが賢いかどうかと、APIが正しく本人確認するかどうかは完全に別の品質である。 たとえばAIが注文処理を担当するなら、AIに渡した認証情報の権限を狭くし、一件当たりの限度、取引先ごとの制限、人間の承認、異常検知、途中停止を設計しておく。認証バイパスに対する根本修正の代わりにはならないが、他の失敗も含めた影響範囲を小さくするために役立つ。 今後は人間の社員だけでなく、アプリケーション、外部パートナー、ソフトウェアボット、AIエージェントが操作主体になる。誰にどの権限を渡し、いつ失効させ、行動をどう追跡するか。認証と認可を分けて設計する発想が、DXやAXの基礎体力になっていく。 ■17．企業の経済損失は、パッチ費用より広い 今回の脆弱性を経営課題として見ると、単に保守担当者が更新作業をするだけの問題ではない。仮に重要な顧客情報や取引機能が露出した場合、原因調査、サービス停止、データ復元、顧客対応、取引先への説明、法的な検討などが発生し得る。実際にこれらの被害が確認されたと主張しているわけではなく、リスクが顕在化した場合の費用構造の話だ。 経済的な合理性を考えるなら、更新に必要な工数を単独で見るのではなく、脆弱な状態が続く期間、守る資産の重要性、障害が起きたときの停止損失、修正の失敗による業務影響まで比較する必要がある。修正を急ぎすぎて顧客の注文を止めても損失になるため、安全な事前検証と素早い配布を両立させる仕組みが価値を持つ。 受託開発会社、SaaS事業者、社内情報システム部門では責任の範囲が異なる。保守契約に脆弱性情報の監視、緊急更新の判断、テスト、証跡、顧客連絡、サポート終了対応が含まれているかを見直す余地がある。セキュリティは「機能を追加したときだけ費用が生じる仕事」ではなく、サービス提供を続けるための継続的な能力になっている。 その能力を測るなら、脆弱性の公表から影響判定までの時間、修正版配布までの時間、全本番環境の確認率、重要APIの認証テスト網羅率など、具体的な指標が使える。ツールを買った数より、危険を把握して修正できる速さが競争力になる。 ■18．これから1～3年で問われる設計と運用 今後、クラウド、外部API、AIエージェント、モバイルアプリが一層連携するほど、認証の仕組みは目に見えない社会インフラとして重要になるだろう。利用者の端末、認証基盤、業務システム、DBが複雑に結び付くなかで、各サービスが「何を正しい認証情報として受け付けるか」を厳密に決める必要がある。 開発側では、型が異なる入力の拒否、期限切れの拒否、権限の不足、別利用者へのなりすまし、再利用できないトークンの失効などを、正常系と同じくらい重視してテストすることが求められる。さらに認証方式の変更がAPI全体へ波及していないか、パッケージ更新のたびに自動検証できる状態が望ましい。 運用側では、ソフトウェア部品表、サービス台帳、公開経路の一覧、依存関係の自動検出、緊急時の連絡網を整える。経営側では、更新を誰が判断し、顧客への説明責任を誰が担い、停止判断を誰が下すかを明確にしておく。技術の欠陥そのものをゼロにするのは難しくても、見つかった欠陥を短期間で封じ込める仕組みは改善できる。 また、今後の評価では「認証機能があるか」から「想定しない値でも必ず拒否するか」へ視点を深めるべきだ。正常なログインができるだけでは安全性は証明されない。失敗すべき操作が確実に失敗することこそ、認証基盤の重要な品質である。 ■19．結論：問われているのは鍵より、鍵を判定する仕組み 今回の「認証すり抜け」は、Laravelを使った企業への一律の危険宣言ではない。標準TokenGuardを利用する一部構成で、型の検証とデータベースの解釈が組み合わさり、認証結果を誤らせ得る重大な欠陥が存在したという問題である。公式は12.68.0以降と13.29.0以降を修正版として示している。まず自社の実装と本番バージョンを確認し、該当すれば修正し、認証が拒否すべき要求を正しく拒否することを検証する必要がある。 この事例の核心は、厳しい認証方式を用意しても、境界で受け付ける値が曖昧なら守りが崩れる点にある。セキュリティは強いパスワードや多要素認証だけの問題ではなく、データ型、検索条件、依存ライブラリ、API権限、ログ、運用判断の積み重ねで成立する。 人間の利用者に加え、業務システムとAIエージェントがAPIを常時利用する時代。誰が操作したのかを正しく識別し、必要な権限だけを認め、不正な入力は入口で止める。この基本を構造として維持できるかどうかが、企業の信頼を分けていく。 #AI #Laravel #サイバーセキュリティ

Previdian✓@PrevidianCyber

⚠️ We’ve observed exploitation attempts targeting Laravel’s TokenGuard authentication bypass, CVE-2026-114509, against one of our real Laravel application honeypots. First observed by Previdian on 27 October at around 15:00 UTC, from source IP 82.102.25[.]62. After checking for Laravel, the source sent API requests containing: {"api_token": [0]} The payload supplies an array containing zero where a token string is expected. In affected TokenGuard configurations using MySQL or MariaDB, this can cause the authentication lookup to match an existing user without a valid API token. On our honeypot, GET /api/user reached TokenGuard and generated a database lookup containing: "api_token" in (0) This application ran Laravel 8 with SQLite. The query failed. No authentication bypass or account takeover occurred. We expect to see successful exploitation against our other Laravel honeypots running affected MySQL or MariaDB configurations soon. We'll update you when we do. Defenders: check whether your API routes use TokenGuard. Update to Laravel 12.68.0 or later on 12.x, or 13.29.0 or later on 13.x, following Laravel’s advisory. Evidence and details 👇

Previdian✓@PrevidianCyber

Over the past 24 hours, Previdian’s honeypot network has captured exploitation attempts targeting four recently disclosed vulnerabilities: 1. MLflow (CVE-2026-116690): Arbitrary file read through prompt model versions, which can expose sensitive files accessible to the MLflow server process. 2. Google Brotli (CVE-2026-111497): A decoder buffer overflow triggered by crafted compressed data, potentially allowing memory disclosure, denial of service or remote code execution. 3. Oracle E-Business Suite (CVE-2026-101767): Unauthenticated SQL injection in Application Object Library that can be chained to remote code execution. 4. Laravel (CVE-2026-114509): A TokenGuard authentication bypass that can enable account takeover under affected MySQL/MariaDB configurations. The attempts targeted our real application honeypots for MLflow, Brotli and Laravel, and our Oracle E-Business Suite decoy. All four have been added to Previdian’s Known Exploited Vulnerabilities (KEV) catalog, with supporting evidence and technical details. If these products are in your environment, review the affected versions and prioritize the relevant vendor fixes. Explore the evidence: previdian.com

Erhan ÜRGÜN@erhanurgun

Laravel'deki CVE-2026-114509 nolu açık ile kimliği doğrulanmamış bir saldırgan, bi başka kullanıcının API token'ına sahip olmadan o kullanıcıymış gibi kimlik doğrulaması yapabilir !! Detaylar için bakınız: - nvd.nist.gov/vuln/detail/cv… - github.com/laravel/framew… #Laravel #Security

Harden Lab@hardenlab

🚨 Critical Laravel flaw (CVE-2026-114509, CVSS 9.2) may allow unauthenticated attackers to bypass API token authentication and impersonate users under specific MySQL/MariaDB configurations. Upgrade to 12.68.0+ or 13.29.0+. #Laravel #AppSec

Roman@mrBr4un

I just completed Laravel TokenGuard: CVE-2026-114509 room on TryHackMe! tryhackme.com/room/laravelto… #tryhackme через @tryhackme