Laravel 12 vs 13: What Actually Changed, and When You Need to Upgrade

Laravel 13 was released on March 17, 2026. If you are still on Laravel 12, the short version is: the upgrade is small, there is no urgency for features, but the support clock is now running and a few of the changes have real security and session implications worth understanding before you start.

Laravel 12 vs 13 at a glance

Dates are from the official support policy. The important line is the third one: Laravel 12 no longer receives bug fixes. It still gets security patches until February 24, 2027, and nothing after that.

What is new in Laravel 13

The release notes describe Laravel 13 as having minimal breaking changes. The headline additions:

• PHP 8.3 minimum. The biggest practical change for most teams. Check your servers, CI images and Docker base images first.
• Laravel AI SDK. A first-party package for text generation, agents, embeddings, images and audio across providers.
• JSON:API resources. First-party support for responses that follow the JSON:API specification.
• Queue routing by class. Queue::route(...) sends a job class to a connection and queue from one place instead of on every dispatch.
• More PHP attributes, such as #[Middleware('auth')] on controllers.
• Cache::touch() to extend an item's TTL without rewriting it.
• Semantic and vector search support.

None of these force you to change existing code. They are reasons to upgrade, not things that break when you do.

The changes that matter for security

These come from the Laravel 13 upgrade guide. They are the ones to read carefully. For a step-by-step version, see the Laravel 13 security upgrade checklist.

CSRF becomes request forgery protection

The VerifyCsrfToken middleware is now PreventRequestForgery, and it adds origin-aware checks using the browser's Sec-Fetch-Site header on top of the token check. The upgrade guide rates this as high impact.

VerifyCsrfToken and ValidateCsrfToken still exist as deprecated aliases, so existing references keep working. What to check:

• Any code that extends or references VerifyCsrfToken by name, including test helpers that disable it.
• Your exemption list. Laravel 13 adds a preventRequestForgery(...) method for configuring the middleware in bootstrap/app.php. Review your exemptions while you are there: CSRF exemptions added "temporarily" for a webhook have a way of covering far more routes than intended.
• Cross-origin form posts from other domains you own. Origin checks are exactly what should stop forged requests, so test any legitimate cross-site flows.

Cache unserialization is hardened

The cache configuration's serializable_classes option now defaults to false. The upgrade guide says this hardens cache unserialization to help prevent PHP deserialization gadget chain attacks if your application's APP_KEY is leaked.

If you cache Eloquent models or other objects, list the classes you actually need there rather than switching the protection off. Leaked keys are not a theoretical concern: researchers found more than 260,000 Laravel APP_KEY values in public GitHub repositories. We cover what an attacker can do with one, and how to rotate safely, in Your Laravel APP_KEY Leaked.

Session serialization moves to JSON

New Laravel 13 applications set session serialization to json. JSON cannot carry PHP objects, which removes a class of unserialization risk from session data.

Existing applications keep their current setting unless you change it, and switching from php to json logs out every active session. If you store objects in the session, you will need to store arrays or IDs instead.

Default cookie and cache prefixes change

The fallback values for the session cookie name and cache and Redis prefixes changed from an underscore separator to a hyphen (_session to -session). If you never set SESSION_COOKIE, CACHE_PREFIX or REDIS_PREFIX, the upgrade renames them. For the session cookie that means everyone is logged out on deploy, and for the cache it means a cold cache.

Set these explicitly in your environment before upgrading. The values below are placeholders:

SESSION_COOKIE=myapp_session
CACHE_PREFIX=myapp-cache-
REDIS_PREFIX=myapp-database-

Use whatever values your application is producing today (check the cookie name in your browser's developer tools), so nothing changes on deploy.

What did not change

A lot of searches ask whether Laravel 13 changed the default database tables. It did not. The default users migration is identical in the Laravel 12 and 13 skeletons and creates the same three tables:

• users: id, name, unique email, email_verified_at, password, remember token, timestamps
• password_reset_tokens: email (primary key), token, created_at
• sessions: id, user_id, ip_address, user_agent, payload, last_activity

The cache and jobs migrations ship in both versions too. If your Laravel 12 application uses the defaults, there is nothing to migrate.

Should you upgrade now?

There is no feature-driven urgency, but there is a deadline. Laravel 12 stopped receiving bug fixes in August 2026 and stops receiving security fixes on February 24, 2027. Running a framework with no security support is how a known, published vulnerability ends up being exploitable on your application with nobody to fix it.

A sensible order:

1. Move servers, CI and Docker images to PHP 8.3 or later. This is independent of Laravel and can ship first.
2. Set SESSION_COOKIE, CACHE_PREFIX and REDIS_PREFIX explicitly, and deploy that on Laravel 12.
3. Upgrade laravel/framework to ^13.0 with PHPUnit 12 or Pest 4, following the upgrade guide.
4. Review your request forgery exemptions and serializable_classes.
5. Decide separately, and deliberately, whether to switch session serialization to JSON.

After deploying, confirm what production actually runs. A free StackShield scan checks your live Laravel application from the outside, including exposed debug tools, framework end of life and session cookie flags. The open source stackshield/scanner runs the same kind of checks from inside the app with one artisan command.