On 19 October 2026 Laravel published a critical security advisory, GHSA-f9x3-7vq9-cph6, scored 9.2 out of 10. It lets an attacker sign in to an API as an existing user without knowing that user's token. The fix shipped in Laravel 12.68.0 and 13.29.0. There is no fixed release for Laravel 11 or anything older.
This is the plain-English version for owners and the people who look after the app: who is exposed, how to check in five minutes, and what to do if you are on a version that no longer gets fixes.
What the flaw is
Laravel ships a simple API guard called the token guard. It reads an api_token from the request and looks up the user whose stored token matches. According to the advisory, on MySQL and MariaDB a request can send a specially crafted value that is not a plain string, and the lookup then matches a real user instead of failing. The attacker is signed in as that user on every route the guard protects.
The flaw was reported by Hristijan Manasijev and fixed by the Laravel team within a day.
Who is affected
All three of these have to be true:
- The app uses the built-in token guard. In
config/auth.php, a guard has'driver' => 'token'. This is the olderapi_tokencolumn approach. Laravel Sanctum and Laravel Passport use their own guards, not this one. - The database is MySQL or MariaDB. The advisory names these two.
- The framework is older than the fixed release: below 12.68.0 on Laravel 12, below 13.29.0 on Laravel 13, or any version of Laravel 11 or earlier.
Older Laravel apps are the ones most likely to use the token guard, because it was the default way to build a simple API before Sanctum existed.
How to check in five minutes
Which Laravel version is your app on?
Paste your composer.json into the free audit. Within 24 hours you get the end-of-life dates, the abandoned packages, and a fixed price for bringing it current.
- Open
config/auth.phpand search for'token'. If no guard uses the token driver, this advisory does not apply to you. - Check the database:
DB_CONNECTIONin the production.env, or ask your host. - Check the framework version:
composer show laravel/framework, or findlaravel/frameworkincomposer.lock.
Or paste your composer.json into the free Laravel audit and we will tell you in writing within a day whether you are in range and what it takes to get out of it.
What to do
On Laravel 12 or 13
Update the framework to 12.68.0 or later on 12, or 13.29.0 or later on 13 (composer update laravel/framework), run the test suite, and deploy. Minor releases in the same major version are designed to be safe to take. The same releases also fix a second advisory published the same day, a medium-severity data-loss issue on recent Laravel 12 and 13 versions, so it is worth updating even if you do not use the token guard.
On Laravel 11 or older
There is no patched release. Laravel 11 stopped receiving security fixes on 12 March 2026 and Laravel 10 on 4 February 2025. This is what end of life means in practice: the first serious advisory after the date, and nothing to install. The options, in order:
- Upgrade to a patched version. Laravel 12 at 12.68.0 or later is supported for security until 24 February 2027; Laravel 13 is supported longer. From Laravel 11 this is usually one sprint.
- Move the API off the token guard. Replacing it with Sanctum removes the affected code path, but it changes how clients authenticate, so it needs testing with every consumer of the API.
- As a stop-gap only, some teams reject any request whose
api_tokenis not a plain string before the guard runs. Treat that as a bridge for days, not a fix: test it, and plan the upgrade anyway.
If the app is several majors behind, the move is bigger, and our Laravel 11 and 12 end-of-life guide explains the routes and what drives the effort.
What it costs with us
- Upgrade Sprint, £1,900 or €2,300, 7–10 working days. Laravel 11 or 12 to a patched, supported version, test suite green, staging sign-off before production.
- Full Upgrade, £3,400–£4,500 or €4,100–€5,500, 2–3 weeks. For apps on Laravel 10 or older: several majors, abandoned packages replaced, tests written where they are missing.
Start with the free audit. You get the versions, the advisories that apply, and a fixed price in writing.
Frequently asked questions
We use Sanctum. Are we affected?
Not by this advisory, which concerns the framework's built-in token guard. Check config/auth.php anyway: older apps sometimes keep a token guard for one legacy endpoint after moving the rest to Sanctum.
We run PostgreSQL. Do we need to do anything?
The advisory names MySQL and MariaDB. If you are on Laravel 12 or 13, take the update anyway; it is a minor release. If you are on Laravel 11 or older, the wider point stands: the next advisory may not be limited to one database.
Can we copy the fix into our old version ourselves?
It is possible to patch the framework locally, but from then on you maintain your own fork of Laravel and have to repeat it for every future advisory. It can bridge a few weeks while the upgrade is scheduled; it is not a place to stay.
How do we know if someone already used it?
Look in your API logs for requests to token-protected routes where the api_token parameter was not a normal string, and for activity on accounts that does not match their usual pattern. If you find anything, treat it as an incident: rotate tokens, review what those accounts could reach, and take advice on your reporting duties.
