Laravel TokenGuard Auth Bypass Explained: What Happened and How to Protect Your Laravel App

As the Founder and CEO of Acquaint Softtech, a Laravel development company and Official Laravel Partner, I read every Laravel security advisory the day it comes out. The one published on October 19, 2026, is among the most serious we have seen in years. It lets someone log in to a Laravel API as a real user, without a password and without a valid token.

The good news is that the fix is small, it is already released, and for most teams it takes minutes to apply. The bad news is that working attack code went public one day after the advisory. So if your app uses Laravel's older token guard, this is a "patch today" job, not a "next sprint" job.

---

The Laravel TokenGuard flaw explained: what happened and when

The flaw sits inside TokenGuard, the class behind Laravel's simple token driver for API login. This is the guard that older Laravel projects used before Sanctum became the default. It is part of the core framework, so a well-written app is still exposed if it uses this guard on an affected version.

Key fact	Details
Official names	CVE-2026-114509, advisory GHSA-f9x3-7vq9-cph6
Severity	CVSS 4.0 score of 9.2 out of 10 (critical)
Weakness type	Improper authentication (CWE-287)
What attackers can do	Log in as an existing user on any route protected by the token guard, with no valid token
Who is affected	Apps with a guard using 'driver' => 'token' and a users table on MySQL or MariaDB
Not affected	Laravel Sanctum and Laravel Passport, which use their own drivers
Affected versions	laravel/framework below 12.68.0 (12.x) and below 13.29.0 (13.x)
Fixed versions	laravel/framework 12.68.0 and 13.29.0, or any later release

You can read the full details in the official Laravel security advisory and the National Vulnerability Database (NVD) record for CVE-2026-114509.

The timeline so far

Date (2026)	What happened
August 25	Laravel quietly ships the fix in versions 12.68.0 and 13.29.0
October 19	The official security advisory goes public, rated critical
October 20	Public proof-of-concept attack code appears online
October 21	The CVE record is added to the National Vulnerability Database
October 22	Italy's national cyber security team issues a public alert about the attack code

The same releases also fix a second, medium-severity Laravel issue (CVE-2026-114508, CVSS 6.5) in JSON:API resources. One upgrade covers both, which is another reason not to wait.

How the TokenGuard attack works

Think of the token guard as a hotel door that checks your keycard. It should ask, "Is this a real keycard?" Instead, before the fix, it only asked, "Is the person holding something?"

1. The guard only checked that the token was not empty. It did not check that the token was text.

2. The attacker sends the token as a list instead of text, for example, api_token set to [0] in a JSON request.

3. Laravel turns that list into a database search that compares the token column with the number 0.

4. MySQL and MariaDB compare text and numbers loosely. A token that does not start with a digit is treated as 0, so it matches.

5. The database returns a real user, and Laravel treats the attacker as that user.

The attacker cannot pick which user they get, because the database returns the first match. But on many apps, that first user is an early account, and early accounts are often admin accounts. That is why the score is 9.2.

The fix in one line

Laravel's patch adds a simple is_string() check, so anything that is not text is rejected before the database is ever asked.

// Before the fix
if (! empty($token)) {
 
// After the fix (laravel/framework 12.68.0 and 13.29.0)
if (is_string(token)&&!empty(token)) {

Is your Laravel app at risk?

Your app is at risk if all three of these are true:

• A guard in config/auth.php uses 'driver' => 'token'. This is common in apps first built on Laravel 5.x to 7.x.

• Your users table is on MySQL or MariaDB. These are the databases named in the advisory.

• Your laravel/framework version is below the fixed version in the table below.

Your Laravel version	At risk if lower than	What to do
Laravel 13.x	13.29.0	Update to 13.29.0 or higher
Laravel 12.x	12.68.0	Update to 12.68.0 or higher
Laravel 11.x or older	No fixed release listed	Move to a supported version (12.x or 13.x) as soon as you can

What about apps on Laravel 10 or 11?

The advisory does not name a fixed release for Laravel 10 or 11, and these versions no longer get regular security fixes. If your app still runs on them, a planned move to a supported version is the safe path. This is exactly what our version upgrade services handle, step by step and without breaking your features. Our guide to Laravel application modernization explains how that move works.

How to fix CVE-2026-114509: a 6-step plan

Updating the framework is the only full fix. Follow these steps in order.

Step	What to do	Why it matters
Check your version	Run composer show laravel/framework on every app	You cannot fix what you have not listed
Find token guards	Search config/auth.php for the token driver	This tells you which apps are exposed
Update Laravel	Run composer update laravel/framework to 12.68.0, 13.29.0, or later	This closes the flaw
Confirm the fix	Run composer audit and check the version on the live server	Your local copy and production can differ
Look for an attack	Search app and proxy logs for api_token sent as a list, and review logins on API accounts	Working attack code has been public since October 20
Remove what you do not use	Delete the token guard if no route needs it, or move to Sanctum	Less old code means fewer future surprises

# 1. Check your Laravel version
composer show laravel/framework
 
# 2. Find token guards
grep -n "'driver' => 'token'" config/auth.php
 
# 3. Update and confirm
composer update laravel/framework
composer audit

Cannot update today? Do this for now

The advisory offers no official workaround, so treat these as short-term steps only:

• Add a small middleware that rejects any request where api_token is not plain text.

• Limit public access to API routes that use the token guard until the update is live.

• Plan the move to Laravel Sanctum, which is not affected and is Laravel's current standard for API tokens.

// Short-term guard: reject any api_token that is not text
public function handle($request, Closure $next)
{
    $token = $request->input('api_token');
    if (token!==null&&!isstring(token)) {
        abort(401);
    }
    return next(request);
}

For a wider check of your app's defences after this, our guide to securing your Laravel website is a good next read.

How Acquaint Softtech protects your Laravel app

Think of us as the locksmith who already has a copy of your building plan. When an advisory like this lands, we do not start from zero. With our support and maintenance services, Laravel stays updated month after month, so alerts like CVE-2026-114509 are handled before they become problems.

When a Laravel security alert lands, we:

1. Find everything: every app, every guard, and the exact framework version on each server.

2. Update without downtime: in a planned order, with tests run before anything goes live.

3. Prove the fix: by checking the live version and running a security audit on every app.

4. Check for intruders and change the locks: reviewing logs and replacing any API tokens that may be exposed.

Short on hands this week? You can hire Laravel developers who join your team within 48 hours.

Case study: securing API access on a live FinTech platform

FLIQA Payments, a Pay by Bank FinTech company in Slovenia, needed stronger security on a live Laravel platform that moves real money every day. A full rebuild was too risky. That is the same challenge this advisory creates: fix the login risk without stopping the business.

FLIQA's problem	How we solved it	Result
Weak API access control	Stronger API login checks and role-based access	Only the right people reach the right data
Banking data at risk	Encrypted storage for all banking data	Data protected even if an account is misused
No clear record of actions	A full activity record for every collection and payout	Every payment became traceable
A live system that could not stop	Changes delivered in phases over 8 months	No disruption to live operations

FLIQA's CEO, Nina Strajnar, said our team "added what was necessary, avoided what was not." You can read the full FLIQA case study.

For stronger walls around your servers, hire DevOps engineers to set up firewall rules, log monitoring, and automatic security updates. With verified reviews on Clutch, 70+ in-house engineers, ISO 27001 certification, and Official Laravel Partner status, we bring the same care to every Laravel security job.

Frequently Asked Questions