# Laravel 11 no longer gets security patches: October's authentication bypass and how to upgrade

> Laravel security: CVE-2026-114509 lets attackers log in as another user without a token, and Laravel 11 won't be patched. Check composer.lock and upgrade.

Author: Samuel Hinojosa (CEO & Founder, WITS) · Updated: 2026-10-25 · https://security.wits.mx/en/guides/laravel-11-security-patches/

## What Laravel security flaw shipped in October 2026?

On October 19, 2026 Laravel published CVE-2026-114509, a critical flaw (CVSS 9.2) in TokenGuard: someone with no account can log in as another user without knowing their token. It affects versions before 12.68.0 and 13.x before 13.29.0 on MySQL or MariaDB. Laravel 11 won't get a fix.

According to the [official advisory GHSA-f9x3-7vq9-cph6](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6), the attacker sends a credential that isn't a string. During the user lookup that value is mishandled, and the query matches someone else's record. The result is account takeover on any route protected by that guard. The advisory lists no workaround: the only fix is to upgrade.

> **Is it being exploited?** As of October 25, 2026 there are no reports of exploitation, and the flaw isn't in CISA's Known Exploited Vulnerabilities catalog. That doesn't make it less urgent: the advisory is public and describes the kind of value that triggers the bug.

It wasn't the only one. These are October's advisories that matter to a typical Laravel project:

| Advisory | Package | Severity | Affected | Fixed in |
|---|---|---|---|---|
| CVE-2026-114509, log in as another user (TokenGuard) | laravel/framework | critical, CVSS 9.2 | before 12.68.0 and 13.x before 13.29.0, with MySQL or MariaDB | 12.68.0 · 13.29.0 |
| CVE-2026-114508, a read endpoint can wipe a related table | laravel/framework | moderate, CVSS 6.5 | from 12.45.0 and before 13.27.0 | 12.68.0 · 13.27.0 |
| GHSA-mhf7-xp6r-6qrc, «#[Authorize]» bypass | livewire/livewire | moderate, CVSS 6.5 | from 4.3.0 and before 4.4.8 (3.x not affected) | 4.4.8 |
| CVE-2026-108082, a «Cache-Control» header burns CPU (ReDoS) | symfony/http-foundation | no official rating | 5.4, 6.4, 7.4 and 8.x before the fixed releases | 5.4.54 · 6.4.48 · 7.4.21 · 8.1.9 |

The second flaw, per [advisory GHSA-5wcm-3v2w-8362](https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362), lets a request to a read-only endpoint empty a related table with no write permissions. The [Livewire](https://github.com/advisories/GHSA-mhf7-xp6r-6qrc) one lets «#[Authorize]»-protected actions run against records the user doesn't own, such as deleting another user's comment. The [Symfony](https://symfony.com/blog/cve-2026-108082-redos-in-headerutils-split-reachable-through-the-cache-control-request-header) one reaches Laravel because that component parses every request: a crafted header costs close to a second of CPU. Note that Symfony says its first fixed releases had a regression, so on 6.4, 7.4 and 8.1 you need 6.4.48, 7.4.21 or 8.1.9.

## Why won't Laravel 11 get the patch?

Because its support is over. Laravel gives each major version 18 months of bug fixes and 2 years of security fixes. Laravel 11 shipped on March 12, 2024 and its security support ended on March 12, 2026, per [Laravel's support policy](https://laravel.com/docs/12.x/releases). The TokenGuard advisory covers every version before 12.68.0 and only publishes fixes for 12 and 13.

| Version | Supported PHP | Bug fixes until | Security fixes until |
|---|---|---|---|
| Laravel 10 | 8.1 to 8.3 | Aug 6, 2024 | Feb 4, 2025 |
| Laravel 11 | 8.2 to 8.4 | Sep 3, 2025 | Mar 12, 2026 |
| Laravel 12 | 8.2 to 8.5 | Aug 13, 2026 | Feb 24, 2027 |
| Laravel 13 | 8.3 to 8.5 | Q3 2027 | Q1 2028 |

A second deadline hits the same projects: PHP 8.2 stops receiving security fixes on December 31, 2026, per [PHP's supported versions table](https://www.php.net/supported-versions.php). Plenty of Laravel 11 systems run on PHP 8.2. If that's you, plan the framework and PHP upgrades together. We cover it in [how to upgrade PHP to 8.4 without breaking production](https://security.wits.mx/en/guides/upgrade-php-8-4/).

## How do I check whether my Laravel project is affected?

Everything is in «composer.lock», which records the exact installed version of every package. Check the one on the production server, not only your laptop, because they don't always match.

```
composer show laravel/framework livewire/livewire symfony/http-foundation
composer audit                 # checks composer.lock against the security advisory database
php artisan about              # Laravel version, PHP version and drivers in use
grep -n "'driver'" config/auth.php   # does any guard use the 'token' driver?
```

1. Laravel: if «laravel/framework» is on 11.x or older, 12.x before 12.68.0, or 13.x before 13.29.0, you're in the TokenGuard range.
2. Configuration: the flaw applies when a guard uses the «token» driver (the built-in TokenGuard) and your database is MySQL or MariaDB. If your API uses a different mechanism, the risk from this specific flaw drops, but the other advisories still apply.
3. Livewire: if you're on version 4 between 4.3.0 and 4.4.7 and your components use «#[Authorize]», upgrade to 4.4.8. In the meantime, calling «$this->authorize()» inside the method isn't affected.
4. Symfony: compare your «symfony/http-foundation» version with the table above.
5. The rest of the server: the PHP version counts too. If it runs a version affected by [PHP2Shell](https://security.wits.mx/en/guides/php2shell-cve-2026-109618/), deal with that first.

> **If you don't have server access** Ask whoever maintains the system for the production «composer.lock». That file tells you which versions run without logging into the server or reading the code. From the outside, the [free check](https://security.wits.mx/en/php-check/) tells you whether your domain advertises a vulnerable PHP version.

## How do you upgrade from Laravel 11 to 12 and 13 without breaking the API?

The good news: recent Laravel upgrades are small. The [official 11 to 12 guide](https://laravel.com/docs/12.x/upgrade) estimates 5 minutes and the [12 to 13 guide](https://laravel.com/docs/13.x/upgrade) 10 minutes for a clean application. A real system with third-party packages and years of code takes longer, but it's still days, not months. This is how we stage it:

1. Move to Laravel 12.68.0 or later first. It's the shortest step that closes TokenGuard and the data-wipe flaw, and Laravel 12 gets security fixes until February 24, 2027. In «composer.json»: «laravel/framework» to «^12.0», «phpunit/phpunit» to «^11.0» and «pestphp/pest» to «^3.0». Laravel 12 requires Carbon 3.
2. Review the 11 to 12 changes that tend to bite: «HasUuids» now generates version 7 UUIDs, the «image» rule no longer accepts SVG by default and the «local» disk points to «storage/app/private» unless you define it.
3. Run the tests plus a manual pass through the API on staging: login, token issuance, role permissions and the routes that expose data.
4. Roll out in stages with a ready rollback: the previous version deployed side by side, or a deploy you can revert in minutes.
5. Then plan Laravel 13. It requires PHP 8.3 or later, so it pairs with leaving PHP 8.2 behind. The high-impact changes are CSRF protection renamed to «PreventRequestForgery» (it now checks the request origin via the «Sec-Fetch-Site» header) and dependencies: «laravel/tinker» to «^3.0», «phpunit/phpunit» to «^12.0» and «pestphp/pest» to «^4.0».
6. On Laravel 13, choose the new security defaults deliberately: «serializable_classes» for cache and «json» session serialization. Switching sessions from «php» to «json» logs out every user, so do it in a planned window.

Once the framework is current, Laravel security takes little upkeep: «composer audit» on every deploy, alerts for your packages and minor updates each month. We publish the week's relevant flaws in [alerts](https://security.wits.mx/en/alerts/).

> **Want us to review it with you?** Security OS reviews your «composer.lock», your authentication config and the server's PHP version with read-only access. You get which flaws apply and which don't, a staged upgrade to Laravel 12 or 13 with its rollback plan, and before-and-after evidence. No change reaches production without your approval.

Tell us which Laravel and PHP versions you run and where it's hosted. If you can, have the production composer.lock handy. [Review my Laravel project](https://security.wits.mx/en/guides/laravel-11-security-patches/#contacto)

## Frequently asked questions

**What is CVE-2026-114509?**

It's a critical flaw (CVSS 9.2) in Laravel's TokenGuard, published on October 19, 2026. On MySQL or MariaDB, an attacker with no account can log in as another user without knowing their token.

**Will Laravel 11 get a TokenGuard patch?**

No. Laravel 11 stopped receiving security fixes on March 12, 2026, and the advisory only ships fixes in 12.68.0 and 13.29.0. The way out is upgrading to Laravel 12 or 13.

**How do I check my Laravel version?**

Run «php artisan about» or «composer show laravel/framework» on the server. It's also in composer.lock under the laravel/framework package.

**Am I affected if I use PostgreSQL or Sanctum?**

The advisory names MySQL and MariaDB with the built-in TokenGuard as the affected setups. If you use another database or token mechanism, this specific flaw doesn't apply per the advisory, but upgrade anyway for October's other flaws.

**Is the Laravel flaw being exploited?**

As of October 25, 2026 there are no reports of exploitation and it isn't in CISA's KEV catalog. The advisory is public, so the prudent move is to upgrade now.

**How long does a Laravel 11 to 12 upgrade take?**

Laravel estimates 5 minutes for an application without unusual customizations. A real system with third-party packages usually takes days, mostly for testing.

**Does Laravel 13 run on PHP 8.2?**

No. Laravel 13 requires PHP 8.3 or later. Since PHP 8.2 loses support on December 31, 2026, it makes sense to plan both upgrades together.

## Sources

- [GHSA-f9x3-7vq9-cph6 (CVE-2026-114509): Token-based API guard Auth Bypass](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6)
- [GHSA-5wcm-3v2w-8362 (CVE-2026-114508): Unauthorized Data Destruction](https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362)
- [GHSA-mhf7-xp6r-6qrc: Livewire #[Authorize] bypass](https://github.com/advisories/GHSA-mhf7-xp6r-6qrc)
- [Symfony: CVE-2026-108082, ReDoS en HeaderUtils::split()](https://symfony.com/blog/cve-2026-108082-redos-in-headerutils-split-reachable-through-the-cache-control-request-header)
- [Symfony: security advisories](https://symfony.com/blog/category/security-advisories)
- [Laravel: release notes and support policy](https://laravel.com/docs/12.x/releases)
- [Laravel: upgrade guide from 11.x to 12.0](https://laravel.com/docs/12.x/upgrade)
- [Laravel: upgrade guide from 12.x to 13.0](https://laravel.com/docs/13.x/upgrade)
- [PHP: Supported Versions](https://www.php.net/supported-versions.php)