Laravel TokenGuard bypass: are you exposed, and what to run today

Laravel News reported on 2026-10-20 a critical advisory, GHSA-f9x3-7vq9-cph6 with a CVSS score of 9.2, in Illuminate\Auth\TokenGuard, the class behind the token guard driver. On MySQL and MariaDB, an attacker with no account could be authenticated as an existing user without knowing that user's API token. If you run Laravel, the useful question is not how bad it sounds but whether your app uses that guard at all, and you can answer it by opening one file.

What went wrong

According to the advisory as Laravel News describes it, the guard only checked that the token taken from the request was not empty before passing it to the user provider. A specially crafted value that was not a string got through that check, and the lookup that followed matched a user record it should never have matched instead of failing. The report is credited to Hristijan Manasijev. The fix adds a type check in both user() and validate(), so anything that is not a string is rejected before a query runs.

// before (simplified): only emptiness was checked
if (! empty($token)) { ... }

// after (as quoted in the report): the type is checked first
if (is_string($token) && ! empty($token)) { ... }

Why a non-string value is dangerous at a lookup

This part is general explanation of the bug class, not the confirmed mechanism of this advisory. Request input in PHP is not always a string. A query string or a JSON body can carry an array where your code expects a single value, and query builders often treat an array as "several values" or "several conditions" rather than as one token to compare. Code that only asks "is it empty?" lets that array through, and the lookup is then answering a different question from the one you meant to ask. The defence is boring and reliable: check the type of every credential-like input at the boundary, before it touches a query.

Are you exposed? Open config/auth.php

Per the advisory, you are affected only if a guard in config/auth.php uses the token driver, for example 'api' => ['driver' => 'token', 'provider' => 'users']. Sanctum and Passport register their own guard drivers and are not listed in the advisory. The patched releases are Laravel 12.68.0 and 13.29.0, both dated 2026-08-25 in the Laravel News article; every version below those is listed as affected, and patches exist only for the 12.x and 13.x branches. If you are on an older major version and use the token driver, upgrading the major version is the fix.

The same day brought a second, medium advisory, GHSA-5wcm-3v2w-8362 with CVSS 6.5, in the JSON:API resources added in 12.45: a read-only request could be crafted to trigger a destructive database operation on a related table. Laravel News lists 12.68.0 and 13.27.0 as the patched versions for that one, so the same upgrade covers both.

What to run

composer update laravel/framework
composer audit

Put composer audit in CI as well, so the next advisory shows up as a failed build rather than a news article you happen to read. For this site I checked both things: composer.lock pins laravel/framework v13.35.0, which is past 13.29.0, and config/auth.php defines only a session guard, so there is no token guard here to begin with. If you are building a new API, Sanctum is the safer default than the bare token guard, and whatever you use, check that every credential is a string before it reaches a query.

Source: Laravel News, "Laravel token guard auth bypass".