On August 13, 2026, Laravel 12’s bug-fix support ended. Laravel will keep shipping security patches for it until February 24, 2027, but after that date, Laravel 12 gets nothing. A Laravel 12 app in production looks the same today as it did last week, because nothing in the framework itself changed on the 13th. What changed is what happens to a non-security bug you find tomorrow: it stays open, because Laravel core no longer commits to fixing it.
If your organization runs either version in production, now is the time to start planning a move to Laravel 13. Curotec’s Laravel 13 Upgrade Guide covers the technical considerations teams should evaluate before beginning the migration. Laravel 11 is a different situation. Its security coverage ended on March 12, 2026. Any vulnerability disclosed against Laravel 11 in the past five months has no patch coming, and if you’re running Laravel 11, that vulnerability is live in your production app right now.
Check the table below for your version, then jump to the section that applies.
If you’re on Laravel 11 or older, refer to “Laravel 11: exposure If you’re on Laravel 12, the next section covers what changed and what to do.
👋 Need help upgrading your Laravel version?
Curotec helps organizations evaluate architecture, scalability, and technical debt before growth turns small issues into major obstacles. Book a call, and we’ll walk through your app together.
Trusted by tech leaders at:
Laravel 11: exposure
Teams tend to file “no more security patches” under technical debt, something to schedule alongside the rest of the backlog. That’s the wrong category. Debt slows a team down over time. An unpatched vulnerability in a live system is a liability today, in production, handling real user traffic.
Laravel 11 has gone five months without a security patch. Several vulnerabilities have been disclosed against the framework since March 12. None of them will get fixed for Laravel 11. The only fix is moving off Laravel 11.
Laravel’s own guidance says most teams can jump straight from an older major to the current one, skipping intermediate versions entirely. Your third-party packages usually decide the real path, not the framework. Some dependencies dropped Laravel 11 support months ago. Others haven’t caught up to Laravel 13 yet. The fastest route depends on what your app actually runs on.
This is worth an immediate and direct answer for your team. Curotec can run a fast, security-focused review of your app: what’s exposed and the shortest safe path off Laravel 11.
Laravel 12: what “security fixes only” means
Security patches close vulnerabilities somebody finds and reports. Bug fixes cover everything else: a queue retry edge case, a validation rule that mishandles a specific input, a performance regression under one load pattern. As of August 13, Laravel stopped shipping bug fixes for version 12.
Nothing breaks on a specific date because of this. The list of known, unpatched quirks just grows slowly as long as you stay on 12. The sharper risk is ecosystem drift: package maintainers shift their testing to Laravel 13 as the community moves there, so a dependency that works fine on 12 today can quietly stop being tested against it within a few months. Nobody breaks it, but nobody’s checking anymore.
None of that calls for an emergency. It’s a reason to put the Laravel 13 upgrade on a calendar instead of a someday list.
The upgrade path to Laravel 13
Laravel 13 requires PHP 8.3 or newer. For teams already on 8.3 or later, it’s a small upgrade. For teams still on PHP 8.2, the PHP version is usually the bigger blocker, bigger than anything in the framework changes.
Laravel’s upgrade guide names two high-impact changes and two medium-impact ones. Everything past those four is closer to a find-and-replace pass. The two to check before you start:
- Concurrency result indexing changed. Apps using Laravel’s concurrency API and relying on result order will behave differently.
- Container dependency resolution changed for default property values. An edge case in how the service container resolves defaults. Check this if your app leans on advanced dependency injection.
If neither applies to your app, the upgrade matches the “10 minutes, run composer update, test” experience Laravel advertises. If one does apply, it’s a scoped fix with a known cause, not a rewrite.
Security coverage for Laravel 12 runs to February 2027. There’s no reason to rush this. There’s also no reason to wait until January to start. Support windows close faster than the calendar suggests.
The questions we keep getting
Can I upgrade straight from Laravel 11 to 13, or do I need to go through 12 first?
For most apps, yes, straight to 13. Laravel doesn’t require sequential major upgrades, and Laravel’s own guidance treats a single-version jump the same as a multi-version one. The real constraint is your dependencies. Run composer why-not laravel/framework 13.0 against your lock file, or just try the upgrade on a branch: if every package resolves, skip 12 entirely. If a package pins a Laravel 11 constraint, you’ll find out fast and can decide whether to wait, fork, or replace it.
Is Laravel 12 an LTS release?
No. Laravel stopped designating long-term-support majors after version 6. Every release since gets the same window: 18 months of bug fixes, 24 months of security patches. Laravel 12 isn’t an exception to a rule; it’s the rule.
What happens if my dependencies haven’t updated for Laravel 13 yet?
Check each package’s composer.json for its Laravel version constraint before you start the upgrade, not after. A package still pinned to ^11.0 or ^12.0 will block the update entirely. Your options are to wait for the maintainer, submit a compatibility PR yourself, or replace the package. None of these are quick fixes, which is the strongest argument for starting the compatibility check now instead of in February.
How long does a typical Laravel 13 upgrade take?
Laravel’s own docs estimate around 10 minutes for a straightforward app: run composer update, fix anything that breaks, done. That number holds if neither of the two high-impact changes applies to your codebase. If your app uses the concurrency API or leans on container default-property resolution, budget a half day to test and adjust those specific areas. Either way, the upgrade itself is small. The time sink is almost always your test suite, or the lack of one.
One policy, two clocks
Laravel’s support policy is now the same for every major release: 18 months of bug fixes, 24 months of security patches, no long-term-support branch to lean on afterward. Whatever version you run today will eventually hit this same fork. The variable is whether you know the dates before an unpatched vulnerability finds them for you.
Not sure which side of that line your app sits on—Laravel 11’s security gap or Laravel 12’s upgrade runway? Contact Curotec for a short conversation to find out.
