Laravelに認証すり抜けなど2件 12.68.0・13.29.0で修正、MySQLで要注意

PHPで業務のシステムや会員サイトを作るときによく使われるWebフレームワーク「Laravel」に、2件の脆弱性が見つかりました。1件は、APIの認証をすり抜けて他人として振る舞えるもので、深刻度はCVSS 4.0で9.2です。自社で開発したり、委託して作ってもらったりしたシステムにLaravelが使われていないか、確かめる必要があります。Laravelの公式の勧告から整理します。

何が見つかったか

Laravelの開発チームは2026年10月19日、フレームワーク本体(laravel/framework)の脆弱性2件を、GitHubのセキュリティ勧告で公表しました。ドイツのCERT-Bundも同じ日に、深刻度「高」の注意情報を出しています。

2件とも、10月20日時点でCVE番号は付いておらず、悪用の記載もありません。

重いのは、APIの認証のすり抜け

1件目は、Laravelに組み込みの「TokenGuard」を、標準のトークン方式のAPIの認証として設定している場合の不具合です。MySQLかMariaDBを使う構成では、攻撃者が文字列ではない特別な形の値を送ると、認証の照合がうまく働かず、意図しない利用者のデータと一致してしまうとしています。

その結果、ログインしていない攻撃者が、相手のAPIのトークンを知らなくても、ほかの利用者として認証され、この認証で守っている窓口(ルート)で、アカウントを乗っ取られるおそれがあります。勧告の評価では、ネットワーク越しに、権限も利用者の操作も要らずに狙えます(ただし、MySQL・MariaDBなどの条件が要る)。

2件目は、データの関係をまとめて読み込む処理の不具合です。特定の条件では、読むだけの窓口への細工した要求で、関連する表の中身を消すような操作が起きてしまうとしています。読む権限しかない利用者が、元に戻せない形でデータを失わせるおそれがあります。

影響する会社・しない会社

• 影響する: Laravelで作った業務のシステムや会員サイト、APIを動かしている会社です。とくに、TokenGuardでAPIを守り、データベースにMySQLかMariaDBを使っている場合は、急いで更新します。
• 影響する: システムの開発や保守を外部に任せている会社です。Laravelを使っているかどうかを、自社で把握していないことがあります。
• 影響しない: Laravelを使っていない会社です。Laravelを使っていても、12.68.0以降・13.29.0以降に上げ済みなら、2件とも直っています。

情シスが今日やること

• Laravelを使っているシステムを洗い出す。社内で作ったシステム、委託して作ったシステム、パッケージの製品の中に、Laravelが入っていないかを確かめます。開発の担当者には、composer.lockでlaravel/frameworkの版を見てもらうと早く分かります。
• 認証の方式とデータベースを確かめる。APIをTokenGuard(標準のトークン方式)で守っているか、データベースがMySQL・MariaDBかを、開発した会社や担当者に聞きます。両方に当てはまるなら、最優先で更新します。
• 12.68.0・13.29.0以降に上げる。更新は、試験の環境で動きを確かめてから本番に当てます。保守の契約がある場合は、更新の予定日と、当てた版を書面で受け取ります。
• ログを見ておく。更新の前に、APIの認証の記録で、見覚えのない利用者としての成功や、普段と違う接続元からの成功が無いかを確かめます。データの消去の件に備えて、関係する表のバックアップが取れているかも確かめます。