Laravel 11は2024年3月12日にリリースされ、2026年3月12日でセキュリティ修正の提供も終了しました。それでも11.xブランチには2026年10月27日のv11.57.1までタグが打たれ続けており、「まだ保守されているのか、もう危ないのか」が外から判断しにくい状態になっています。2026年10月23日には認証を回避されるCriticalの脆弱性（CVE-2026-114509）も公表され、影響範囲に11系が含まれています。
この記事では、Laravel 11で実際に何が変わったのかを整理したうえで、EOL後の11.xで何が起きているかをGitHubの一次情報と11系の実コードから確認し、12と13のどちらへ移すかの判断材料を示します。最新メジャーである13系そのものの内容はLaravel 13のAI SDK入門｜1.x対応の導入手順・Agent実装・Skills・ベクトル検索、稼働中のアプリの版の調べ方と各版のサポート期限の一覧はLaravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限で扱っています。
まとめ：Laravel 11の現在地
- バグ修正は2025年9月3日、セキュリティ修正は2026年3月12日で提供終了。公式表の凡例でいう End of life に当たります。
- 2026年10月23日公表のTokenGuard認証回避（CVE-2026-114509・Critical）は、アドバイザリ上の影響範囲が「12.68.0未満」で11系全体を含みます。ただし実コードを確認すると、11.xにも2026年8月25日のv11.56.1でTokenGuardの修正が入っています。
- 一方、2026年6月17日に公開されたemailルールのCRLFインジェクションと一時URLのパス解釈の2件は、2026年10月時点の最新タグv11.57.1でも修正が入っていません。修正版として案内されているのは12系と13系だけです。
- EOL後の11.xのタグは大半がLaravel Cloud向けのバックポートで、v11.52.0以降はGitHubのリリースノートも作成されていません。タグの存在を保守継続の根拠にはできません。
- 11の中核は
bootstrap/app.phpへの設定集約、Laravel Reverbの追加、/upヘルスルート、秒単位レート制限、暗号鍵の無停止ローテーション。既存アプリの構造変更は求められません。 - 対応PHPは8.2〜8.4。13系はPHP 8.3以上が必須のため、PHPの版が移行先の上限を決めます。
- 移行はメジャーを1つずつ。公式の想定所要時間は11→12が5分、12→13が10分です。
Laravel 11のサポート期限とEOL後に起きていること
バグ修正2025年9月3日・セキュリティ修正2026年3月12日で終了
Laravelのサポートポリシーは全リリース一律で、バグ修正が18か月、セキュリティ修正が2年と定められています。バージョンごとに期間の長短を設ける仕組みではないため、11だけが延長されることはありません。公式ドキュメントのリリースノート（13.x）のサポート表に記載された各版の期限は次のとおりです（2026年10月時点）。
| バージョン | 対応PHP | リリース | バグ修正期限 | セキュリティ修正期限 |
|---|---|---|---|---|
| Laravel 11 | 8.2 – 8.4 | 2024年3月12日 | 2025年9月3日 | 2026年3月12日 |
| Laravel 12 | 8.2 – 8.5 | 2025年2月24日 | 2026年8月13日 | 2027年2月24日 |
| Laravel 13 | 8.3 – 8.5 | 2026年3月17日 | 2027年第3四半期 | 2028年3月17日 |
表で見落とされがちなのは12系の位置づけです。12のバグ修正提供は2026年8月13日で終わり、現在はセキュリティ修正のみ（2027年2月24日まで）の期間に入っています。11から12へ移してもバグ修正の窓はすでに閉じているため、移行先を12に決めるのは「セキュリティ修正が続く残り約4か月を買う」判断だと理解しておく必要があります。
EOL後も打たれ続ける11.xタグの内容と一般向け修正との違い
Packagistのlaravel/frameworkで11系のリリース履歴をたどると、セキュリティ修正期限の2026年3月12日を過ぎたあともv11.49.0とv11.50.0（2026年3月17日）、v11.51.0（3月26日）、v11.52.0（5月14日）、v11.55.0（7月14日）と続き、2026年10月28日時点の最新はv11.57.1（10月27日）です。タグだけを見れば保守が継続しているようにも読めます。
しかし中身は一般向けの保守ではありません。GitHubのリリース一覧に登録されている11.x向けのリリースはv11.51.0が最後で、v11.52.0以降はタグが存在するのにリリースノートが作成されていません。v11.51.0からv11.55.0までの16コミットを確認すると、「Backport cloud queues」「Dedicated Cloud Queue」「Pop managed queue jobs from the cloud-agent instead of SQS」といった、Laravel Cloudのマネージドキューを11系でも動かすためのバックポートが大半を占めます。
v11.55.0からv11.57.1までの18コミットも傾向は同じで、cloud-agentの通信設定、Cloudのログドライバ、名前付きS3認証情報とCloud IAMディスク、Cloud向け例外処理の移植が並びます。例外は2026年8月25日の「fix token parsing」の1件だけで、これが後述するTokenGuardの修正に当たります。
タグが増えていることを、脆弱性が塞がれ続けている根拠として読んではいけません。これらはホスティング側の都合による機能移植が中心で、一般利用者向けのバグ修正・セキュリティ修正の窓は2026年3月12日で閉じたままです。TokenGuardの修正が入ったのは例外的な扱いで、同じことが今後も続く保証はどこにも書かれていません。
11系に修正版が出ていない2026年6月の脆弱性と該当する構成
EOLの実害は、すでに具体的な形で現れています。2026年6月17日、laravel/frameworkに対して2件のアドバイザリが公開されました。
| アドバイザリ | 深刻度 | 内容 | 影響範囲 | 修正版 |
|---|---|---|---|---|
| GHSA-5vg9-5847-vvmq | High | emailルールのCRLFインジェクション | 12.60.0未満／13.0.0-13.9.0 | 12.60.0／13.10.0 |
| GHSA-crmm-hgp2-wgrp | Medium | ローカルディスクの署名付き一時URL | 12.61.1未満／13.0.0〜＜13.12.0 | 12.61.1／13.12.0 |
GHSA-5vg9-5847-vvmqとGHSA-crmm-hgp2-wgrpの影響範囲は「12.60.0未満」「12.61.1未満」と記載されており、11系の最新タグであるv11.57.1もこの範囲に含まれます。一方、修正版として案内されているのは12系と13系だけです。
記載レンジだけでなく、実コードでも裏が取れます。12系ではIlluminate/Validation/Concerns/ValidatesAttributes.phpのvalidateEmail()にpreg_match('/[\r\n]/', (string) $value)による改行文字のガードが追加されていますが、v11.55.0からv11.57.1までのどのタグにもこの記述はありません。一時URLのほうも、12系と13系のLocalFilesystemAdapter::temporaryUrl()はパスをrawurlencode()してから署名する形に直っていますが、v11.57.1では['path' => $path]のまま署名しています。
フォームでemailバリデーションを使っているアプリケーションを、11系のまま運用する判断はもう取れません。もう1件のほうは適用範囲が狭く、公式の説明ではローカルファイルシステムドライバの問題という位置づけです。config/filesystems.phpのlocalディスクで'serve' => trueを有効にし、Storage::disk('local')->temporaryUrl()で一時URLを発行している構成が該当します。期限切れのURLが有効なまま受け付けられたり、署名した対象と別のリソースに解決されたりする恐れがあります。
この2件はEOL後わずか3か月で出たもので、その後8月以降にも新たな公表が続いています。今後同種のものが出ても11系には修正が来ない、という前提で計画を立てる必要があります。
LTSという区分が無い現行ポリシーと全リリース共通の修正提供期間
「Laravel 10 LTS」「Laravel 11 LTS」といった検索が続いていますが、現行のサポートポリシーには長期サポート版の区分がありません。サポート表で(LTS)の表記が付いた最後のバージョンはLaravel 6（2019年9月3日リリース）で、当時のポリシーはLTSがバグ修正2年・セキュリティ修正3年、一般リリースがバグ修正6か月でした。Laravel 7以降は表からLTSの表記が消え、現在は全リリースが一律でバグ修正18か月・セキュリティ修正2年に統一されています。
つまり11も12も13もLTSではなく、Laravel 10も2025年2月4日でセキュリティ修正が終了済みです。「どれかがLTSだから当面は動かさなくてよい」という前提でバージョンを据え置いているなら、その前提自体が成り立ちません。フレームワークとしての先行きを含めた判断材料はLaravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応で整理しています。
2026年8月以降に公表された脆弱性と11系の実コードの対応状況
6月の2件のあと、2026年9月29日と10月23日にもlaravel/frameworkのアドバイザリが公開されました。11系に関係するのは次の2件です。どちらもアドバイザリの記載レンジでは11系全体が影響範囲に入りますが、11.xの実コードを確認すると扱いが分かれます。
| アドバイザリ | 公開日 | 深刻度 | 修正版 | v11.57.1の実コード |
|---|---|---|---|---|
| GHSA-f9x3-7vq9-cph6 | 2026年10月23日 | Critical | 12.68.0／13.29.0 | v11.56.1で修正済み |
| GHSA-jh5r-qr3c-85q8 | 2026年9月29日 | Low | 12.69.0／13.30.0 | 該当設定なし |
| GHSA-5vg9-5847-vvmq | 2026年6月17日 | High | 12.60.0／13.10.0 | 未修正 |
| GHSA-crmm-hgp2-wgrp | 2026年6月17日 | Medium | 12.61.1／13.12.0 | 未修正 |
同じ10月23日に公表されたリレーションの読み込みに関するCVE-2026-114508（Medium）は、影響範囲が12.45.0以上に限られており、11系は対象外です。
TokenGuard認証回避CVE-2026-114509の条件と影響
GHSA-f9x3-7vq9-cph6（CVE-2026-114509）は、Laravel標準のTokenGuardを使うAPIガードで、他人のAPIトークンを知らないまま既存ユーザーとして認証できてしまう脆弱性です。深刻度はCritical、分類はCWE-287（不適切な認証）とCWE-1287（入力の型検証の不備）です。
成立条件は、データベースがMySQLまたはMariaDBであることと、TokenGuardで保護したルートがあることの2つです。攻撃者が文字列ではない資格情報（配列など）を送ると、認証時の検索クエリで値が想定外に扱われ、認証失敗になるはずの要求が別のユーザー行に一致します。修正コミットで追加されたテストは、api_tokenに配列[0]を渡したときにretrieveByCredentials()が呼ばれないことを確かめる内容でした。修正の中身は、TokenGuard::user()とvalidate()の両方にis_string()による型の判定を足すものです。
影響範囲は12.68.0未満と、13.0.0以上13.29.0未満。修正版の12.68.0と13.29.0はどちらも2026年8月25日に公開されており、アドバイザリの公表はその約2か月後でした。公表日を起点に「まだ時間がある」と考えるのではなく、修正版が出てから公表までの間にすでに差分が読める状態だったと受け止めるのが妥当です。
対象になるのはconfig/auth.phpのガード定義で'driver' => 'token'を指定している構成です。Laravel Sanctumは独自のガードクラスを登録するため、TokenGuardとは別の実装になります。ただ、1つのアプリでSanctumと旧来のapi_token方式のガードが併存していることも珍しくないため、Sanctumを入れているから無関係だと決める前にguardsの定義を全部見てください。Sanctumのトークン認証とCookieセッションの使い分けはLaravel Sanctumとは：SPAとモバイルのトークン認証とCookieセッションの使い分けで解説しています。
アドバイザリと11系の実コードが食い違う箇所と修正有無の確認手順
GHSA-f9x3-7vq9-cph6の記載上、11系には修正版がありません。ところが11.xブランチには2026年8月25日に「fix token parsing」というコミットが入り、同日のv11.56.1以降のTokenGuard.phpには12系・13系と同じis_string($token)の判定が含まれています。v11.56.0以前は未修正なので、11系の中でもタグによって状況が変わります。
この食い違いはcomposer auditの結果にも表れます。auditはアドバイザリの記載レンジで判定するため、TokenGuardが直っているv11.57.1でもGHSA-f9x3-7vq9-cph6が報告対象です。逆に、TokenGuardの指摘を「実コードでは直っているから」と除外しても、emailルールと一時URLの2件はv11.57.1でも残ります。判定結果を鵜呑みにも全否定にもせず、次の手順で実ファイルを確かめてください。
# 1. TokenGuard（driver 'token'）を使うガードがあるか
grep -n "'driver' => 'token'" config/auth.php
# 2. 導入済みの laravel/framework の版
composer show laravel/framework | grep '^versions'
# 3. TokenGuard の型判定が入っているか（v11.56.1 以降なら 1 件ヒットする）
grep -n 'is_string($token)' vendor/laravel/framework/src/Illuminate/Auth/TokenGuard.php
# 4. email ルールの改行ガードが入っているか（11 系のタグでは 0 件）
grep -nF '[\r\n]' vendor/laravel/framework/src/Illuminate/Validation/Concerns/ValidatesAttributes.php
# 5. 依存パッケージ全体のアドバイザリ照合
composer auditv11.56.0以前でTokenGuardを使っているなら、最低限の止血として11.xの最新タグへ上げる方法はあります。ただしその場合でも、emailルールと一時URLの未修正は残り、今後の修正が11.xへ入るかどうかも分かりません。11.x内の更新はあくまで12・13へ移すまでのつなぎとして扱うべきです。
# 11.x 内での止血（恒久策ではない）
composer require laravel/framework:^11.56.1 --update-with-dependenciesデバッグページのXSS CVE-2026-102279と11系での実装の違い
GHSA-jh5r-qr3c-85q8（CVE-2026-102279）は、APP_DEBUG=trueのときに表示される例外ページで、攻撃者が操作できる値がTippy.jsのツールチップにallowHTML: trueの設定で渡り、マウスを重ねた時点でDOMベースのXSSが起きるものです。深刻度はLow、GitHubでの公開日は2026年9月29日で、修正版の12.69.0と13.30.0は9月1日に出ています。
影響範囲は「12.69.0未満」と書かれているので、記載上は11系も含まれます。しかしv11.57.1の例外ページ用scripts.jsはTippy.jsをクリックで開く設定で初期化しており、allowHTML: trueの指定は見当たりません。修正版のスクリプトはシンタックスハイライトにShikiを読み込んでおり、highlight.jsを使う11系とは別の実装です。修正の対象になった設定そのものが11系には無い、というのが実コードから読み取れる状況です。
どちらにしても、本番環境でAPP_DEBUGを有効にしていること自体が情報漏えいの原因になります。デバッグ情報を表示する仕組みと本番での無効化の手順はLaravel Debugbarの使い方｜導入・APP_DEBUG設定・SQL確認とv4改称対応にまとめています。
Laravel 11で実際に変わったアプリ構成と開発・運用機能
bootstrap/app.phpへの設定集約と新規アプリのファイル削減
11の目玉は、新規アプリケーションの構成を薄くしたことです。従来5つあったサービスプロバイダはAppServiceProviderの1つだけになり、イベントの自動検出が既定で有効になりました。新規アプリに同梱されていた9つのミドルウェアはフレームワーク側へ移り、HTTPカーネルのクラスそのものが不要になっています。ルーティング・ミドルウェア・例外処理・サービスプロバイダの設定は、bootstrap/app.phpに集約されました。
<?php
return Application::configure(basePath: dirname(__DIR__))
->withRouting(
web: __DIR__.'/../routes/web.php',
commands: __DIR__.'/../routes/console.php',
health: '/up',
)
->withMiddleware(function (Middleware $middleware) {
$middleware->validateCsrfTokens(except: ['stripe/*']);
})
->withExceptions(function (Exceptions $exceptions) {
$exceptions->dontReport(MissedFlightException::class);
})->create();スケジュール定義もコンソールカーネルを介さず、routes/console.phpでScheduleファサードを使う形になりました。
<?php
// routes/console.php（Laravel 11以降はコンソールカーネルを置かない）
use Illuminate\Support\Facades\Schedule;
Schedule::command('emails:send')->daily();またroutes/api.phpとroutes/channels.phpは既定で作られません。必要になった時点でphp artisan install:api、php artisan install:broadcastingを実行して追加します。
ここで誤解されやすいのは適用範囲です。この構成変更は新規作成するアプリケーションに対するもので、公式ドキュメントは既存アプリケーションに変更を求めていません。10から11へ上げただけでディレクトリ構成を作り直す必要はなく、旧構成のままでも動きます。
Laravel Reverbによる自前WebSocketサーバー
11では、ファーストパーティのWebSocketサーバーであるLaravel Reverbが追加されました。php artisan reverb:startで起動し、Laravel Echoをはじめとする既存のイベントブロードキャスト機構とそのまま組み合わせられます。Redisのパブリッシュ／サブスクライブ機能による水平スケールにも対応しており、リアルタイム通信のために外部のホスティングサービスへ依存しない選択肢が本体側に用意された点が、11の実務上の変化として大きい部分です。
新規アプリの既定データベースのSQLite化と本番設定の確認対象
11で新規作成したアプリケーションは、データベースの既定がSQLiteになりました。セッション・キャッシュ・キューの各ドライバも既定がdatabaseです。追加のミドルウェアやサーバーを用意しなくても、作成直後から開発を始められるようにするための変更でした。裏を返せば、11以降に作られたプロジェクトを引き継いだときは、.envのデータベース設定が明示されているかを最初に確認しないと、意図せずSQLiteのまま本番に出る事故が起こり得ます。
/upヘルスルートによる死活監視とHTTP・キューの秒単位レート制限
11の新規アプリには/upのヘルスチェック用エンドポイントが定義されています。上のコードのwithRouting()にある'/up'がその指定で、Kubernetesなどのオーケストレーターや外部の死活監視サービスから叩くことを想定したものです。このルートにHTTPリクエストが届くとDiagnosingHealthイベントが発行されるため、依存サービスへの疎通確認など独自のチェックも追加できます。
レート制限は、それまで分単位の粒度しか扱えませんでした。11ではHTTPリクエストとキュージョブの双方で秒単位の指定が可能になっています。
<?php
RateLimiter::for('invoices', function (Request $request) {
return Limit::perSecond(1);
});暗号鍵の無停止ローテーションと認証時のパスワード自動再ハッシュ
Laravelはセッションクッキーを含むすべてのクッキーを暗号化するため、暗号鍵を入れ替えると全ユーザーがログアウトし、旧鍵で暗号化したデータも復号できなくなっていました。11ではAPP_PREVIOUS_KEYS環境変数に過去の鍵をカンマ区切りで並べておけます。暗号化には常にAPP_KEYの現行鍵を使い、復号は現行鍵で失敗した場合に過去の鍵を順に試すため、鍵の入れ替えでユーザーを追い出さずに済みます。
パスワードのハッシュも同様です。bcryptのワークファクタをconfig/hashing.phpやBCRYPT_ROUNDSで引き上げると、以降はユーザーが認証するたびに古いハッシュが自動で再ハッシュされます。計算コストの見直しを、利用者への影響なしに反映できるようになりました。
casts()・キューテスト・Artisanコマンドの追加と実装例
Eloquentのキャストは、プロパティではなくcasts()メソッドで定義できるようになりました。引数付きのキャストを書くときに記述が素直になります。
<?php
class Product extends Model
{
protected function casts(): array
{
return [
'options' => AsCollection::using(OptionCollection::class),
'released_at' => 'datetime',
];
}
}キューのテストも書きやすくなりました。ジョブが解放・削除・失敗したことの検証には従来カスタムのフェイクやスタブが必要でしたが、11ではwithFakeQueueInteractions()を挟むだけで済みます。
<?php
$job = (new ProcessPodcast)->withFakeQueueInteractions();
$job->handle();
$job->assertReleased(delay: 30);クラス生成系のArtisanコマンドとしてmake:class、make:enum、make:interface、make:traitが追加されました。スキーマ検査ではSchema::getTables()やSchema::getColumns()など、テーブル・ビュー・カラム・インデックス・外部キーを取得するネイティブメソッドが揃っています。テスト面では、:memory:のSQLiteを使う際にPDOオブジェクトを接続間で使い回すようになり、公式ドキュメントはテスト実行時間が半減する場合があると説明しています。データベースでは、MySQLドライバの流用ではなくMariaDB専用ドライバが用意された点も変更のひとつです。
Laravel 11の動作要件と移行前の確認対象（PHPとデータベース）
対応PHPの範囲8.2から8.4と稼働中アプリのバージョン確認方法
Laravel 11.xが要求するPHPの最低バージョンは8.2で、サポート表に併記された対応範囲は8.2〜8.4です。実際、11系のタグとして確認できるv11.55.0のcomposer定義でも、PHPの要求は^8.2のままという定義です。稼働中のアプリがどの版で動いているかは、次のコマンドで確認できます。それぞれのコマンドが何の版を返しているのかの切り分けと、コマンドラインが使えない環境での調べ方はLaravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限にまとめています。
# 稼働中のアプリが実際にどの版で動いているかを確認する
composer show laravel/framework | grep '^versions'
php artisan --version
php -v対応データベース5種と必要バージョン（MySQL 5.7以上）
公式が一次サポートを明示しているデータベースと必要バージョンは次のとおりです。
| データベース | 必要バージョン |
|---|---|
| MySQL | 5.7以上 |
| MariaDB | 10.3以上 |
| PostgreSQL | 10.0以上 |
| SQLite | 3.26.0以上 |
| SQL Server | 2017以上 |
移行を検討するうえで押さえておきたいのは、この必要バージョンの一覧が11系と13系の公式ドキュメントで完全に一致している点です。PHPの下限は13で8.3へ引き上げられた一方、データベース側の下限は動いていません。11で動いていたデータベースは13でもそのまま条件を満たします。なお、MongoDBはフレームワーク本体ではなくMongoDB社が保守するmongodb/laravel-mongodbパッケージ経由での対応です。前述のTokenGuardの脆弱性はMySQLとMariaDBの構成で成立するため、データベースの種類は脆弱性の当否を見るときにも確認項目になります。
Laravel 11から12・13へ移行する順序と公式の想定所要時間
メジャー1つずつの段階移行と公式ガイドの想定時間・依存パッケージ
公式のアップグレードガイドはメジャー単位で用意されており、11から13へ直接移す手順は存在しません。11→12のアップグレードガイド、12→13のアップグレードガイドの順に段階を踏みます。ガイドに記載された想定所要時間は11→12が5分、12→13が10分です。13は破壊的変更を抑えることに重点を置いた版で、公式ドキュメントも「多くのアプリはコードをほとんど変えずに移行できる」と説明しています。
# 1段階目：Laravel 11 から 12 へ（composer.json の require を書き換える）
composer require laravel/framework:^12.0 --update-with-all-dependencies
composer require --dev phpunit/phpunit:^11.0 --update-with-all-dependencies
# 2段階目：Laravel 12 から 13 へ（PHP 8.3 以上が前提）
composer require laravel/framework:^13.0 laravel/tinker:^3.0 --update-with-all-dependencies
composer require --dev phpunit/phpunit:^12.0 --update-with-all-dependencies
# Laravel Boost を入れている場合は同時に上げる（/upgrade-laravel-v13 に必要）
composer require laravel/boost:^2.0 --update-with-all-dependenciesテスト関連の依存も同時に上がります。12ではphpunit/phpunitが^11.0、pestphp/pestが^3.0、13ではそれぞれ^12.0と^4.0が要求されます。13ではlaravel/tinkerの^3.0への更新も必要です。12系に着地させる場合は、2026年の脆弱性4件の修正がすべて入っている12.69.0以上（2026年10月27日時点の最新は12.70.2）になっていることをcomposer showで確かめてください。13系なら13.30.0以上が同じ基準になります（同日時点の最新は13.39.0）。
移行先の上限を決めるPHPの版と12・13の選択条件・修正提供期間
13.xが要求するPHPの最低バージョンは8.3です。PHP 8.2で運用しているなら、Laravelだけを13へ上げることはできません。12.xはPHP 8.2〜8.5に対応しているため、PHPを動かせない事情がある環境の現実的な着地点は12になります。逆にPHP 8.3以上へ上げられるなら、セキュリティ修正が2028年3月17日まで続く13まで進めたほうが、次の移行作業を先送りできます。順序としては、Laravelのメジャーを上げる前にPHPの版を確定させると手戻りが出ません。
エラーにならないまま挙動が変わるUUID・画像検証・保存先の確認
移行で厄介なのは、例外も警告も出ないまま動作だけが変わる変更です。11から12へ上げるときは、HasUuidsが返すUUIDのバージョン7化（従来の順序付きUUIDv4を続けるならHasVersion4Uuidsへ差し替え）、imageバリデーションが既定でSVGを弾く点、localディスクを明示していない場合にルートがstorage/appからstorage/app/privateへ変わる点の3つを先に確認してください。影響度を含む全体像は公式の12.xアップグレードガイドに影響度別で並んでいます。
<?php
// Laravel 12以降、HasUuids が返すのは UUIDv7。
// 従来の順序付き UUIDv4 を維持したい場合は差し替える。
use Illuminate\Database\Eloquent\Concerns\HasVersion4Uuids as HasUuids;12から13へ上げる際に高影響として挙げられているのは、CSRFミドルウェアの扱いです。VerifyCsrfTokenがPreventRequestForgeryへ改称され、Sec-Fetch-Siteヘッダーによるオリジン検証が加わりました。VerifyCsrfTokenとValidateCsrfTokenは非推奨のエイリアスとして残るものの、テストやルート定義でミドルウェアを除外している箇所は新しいクラス名へ直す必要があります。
13へのアップグレードはAIアシスタントに任せる経路も用意されており、laravel/boost ^2.0を導入すると/upgrade-laravel-v13コマンドで手順を進められます。Boost自体の位置づけはLaravel Boostの使い方｜boost:installの選択肢とSkills・エージェント別設定【v2.10対応】で解説しました。認証まわりのスターターキットを使っている場合は、Laravel Breezeはなぜ非推奨に？Laravel 13で使う手順と後継スターターキット4種・移行判断も併せて確認してください。
11系に留める期間と12・13へ移す時期を左右する機能とPHPの判断条件
ここまでの事実から、判断は条件で切り分けられます。次のいずれかに当てはまるなら、11系に留める選択肢はありません。フォームでemailルールを使っている、localディスクで一時URLを発行している、TokenGuardを使っていてv11.56.0以前に留まっている、のどれかです。前の2つは11.xのどのタグでも直っておらず、アプリ側で入力を自前検証するか機能を止めるしか回避の手段がありません。
反対に、上の3つのいずれにも当てはまらず、管理画面など外部から到達できない用途に限られているなら、PHPの版上げと移行作業の日程を決めたうえで、短期間だけ11系で運用を続ける余地はあります。その場合でも、次に公表される脆弱性に修正が来ない前提は変わらないため、期間を区切らない据え置きは見送るべきです。移行先は、PHP 8.3以上へ上げられるなら13、上げられないなら12の12.69.0以上とし、12を選ぶ場合は2027年2月24日までに次の移行が必要になることを計画に含めてください。
移行までの間にどの機能が攻撃の入口になり得るかを第三者の目で洗い出したい場合は、一創の脆弱性診断・セキュリティ診断で、Laravelアプリの認証まわりや入力検証を含めた診断をお受けしています。
よくある質問
Laravel 11のサポート期限はいつまでですか？
バグ修正は2025年9月3日、セキュリティ修正は2026年3月12日で提供が終了しています。公式のサポートポリシーは全リリース一律でバグ修正18か月・セキュリティ修正2年と定められており、11だけが延長される仕組みはありません。11.xブランチには2026年10月27日のv11.57.1までタグが打たれていますが、内容の大半はLaravel Cloud向け機能のバックポートで、一般向けのセキュリティ修正が続いているわけではありません。
Laravel 11のPHPバージョンは？
最低要件がPHP 8.2で、公式サポート表に記載された対応範囲は8.2〜8.4です。移行先を13にする場合はPHP 8.3以上が必須になるため、PHP 8.2のままなら12（対応範囲8.2〜8.5）が上限になります。
Laravel 11の次はどのバージョンを選べばよいですか？
PHP 8.3以上へ上げられるなら、2026年3月17日リリースの13系が第一候補です。バグ修正が2027年第3四半期まで、セキュリティ修正が2028年3月17日まで提供されるため、次の移行までの間隔を最も長く取れます。PHPを動かせない場合の上限は12系ですが、そのバグ修正の終了日はすでに過ぎた2026年8月13日です。13で加わったAI SDKなどの内容はLaravel 13のAI SDK入門｜1.x対応の導入手順・Agent実装・Skills・ベクトル検索、各版の期限の一覧はLaravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限にまとめています。
Laravel 11はCVE-2026-114509（TokenGuardの認証回避）の影響を受けますか？
アドバイザリの記載では影響範囲が12.68.0未満のため、11系全体が対象に含まれ、修正版は12.68.0と13.29.0だけが案内されています。ただし11.xの実コードでは、2026年8月25日公開のv11.56.1以降はTokenGuardの型判定が入った状態です。v11.56.0以前でTokenGuard（'driver' => 'token'）を使い、データベースがMySQLかMariaDBなら影響を受けます。v11.56.1以降でもcomposer auditはこの指摘を出し続けるうえ、emailルールと一時URLの2件は未修正のままです。
Laravel 11に留まる場合、何をすればよいですか？
まずTokenGuardの修正が入ったv11.56.1以降へ上げ、そのうえで2026年6月17日公開の2件への対処を決めます。既定のemailバリデーションを使っているか、localディスクを'serve' => trueで公開してtemporaryUrl()を発行しているかを洗い出し、該当する場合は自前で回避策を実装するか、外部から到達できないよう遮断する対応が要ります。本番でAPP_DEBUGが無効になっていることも確かめてください。いずれも恒久策にはならないため、移行時期を決めたうえでの暫定措置として扱ってください。
関連記事
- Laravelのバージョン確認方法｜最新バージョンは13・artisanとcomposerの違いとサポート期限
- Laravel 13のAI SDK入門｜1.x対応の導入手順・Agent実装・Skills・ベクトル検索
- Laravel Sanctumとは：SPAとモバイルのトークン認証とCookieセッションの使い分け
- Laravelの将来性を2026年のデータで判断する｜サポート期限・求人単価・AI対応
- Laravel Boostの使い方｜boost:installの選択肢とSkills・エージェント別設定【v2.10対応】
- Laravel Breezeはなぜ非推奨に？Laravel 13で使う手順と後継スターターキット4種・移行判断
