Laravel Patches Critical Token Guard Auth Bypass

Laravel has disclosed a critical authentication bypass in its built-in token API guard that lets unauthenticated attackers log in as existing users, and a working proof-of-concept exploit is now public.

The flaw is tracked as GHSA-f9x3-7vq9-cph6 and has a CVSS v4 score of 9.2. It affects laravel/framework versions before 13.29.0 and 12.68.0. No CVE identifier had been assigned at the time of writing. Laravel published the advisory on Monday, October 19, and credited researcher Hristijan Manasijev with the report.

The bug is in Illuminate\Auth\TokenGuard, the class behind the token guard driver that protects auth:api routes. Only applications that store their users’ table in MySQL or MariaDB can be exploited. According to Laravel News, Sanctum and Passport register their own guard drivers and are not covered by the advisory.

Before the fix, the guard only checked that the submitted token was not empty before passing it to the user provider. An attacker can send a JSON body of {"api_token":[0]}. The token then arrives as a PHP array holding the integer 0, which counts as non-empty, so it passes the check. Eloquent’s user provider turns array values into a whereIn() clause, and the resulting query compares the text api_token column against an integer.

MySQL and MariaDB compare values numerically, so any stored token that does not start with a digit is converted to 0. The first such row matches, and the guard accepts the request as that user. The advisory says the query matches “an unintended user record rather than failing authentication as expected.”

Rafael Felix and Gabriel Rodrigues of Hakai Offensive Security’s Yokai Research team published a technical analysis on Tuesday. They also released a Python exploit and Docker lab. Their testing shows the integer must come from a JSON body. A query-string array such as ?api_token[]=0 binds a string, and the database does not cast it to a number.

The exploit authenticates as the first user whose token starts with a letter, which is typical for randomly generated tokens. The PoC can also reach users whose tokens start with a specific digit by sending values from 0 to 9. Either way, the attacker gets full access to that account on every route behind the guard without knowing a valid token.

The fix adds an is_string() check to the guard’s user() and validate() methods. Arrays and other non-string values are now rejected before any database query runs. Hakai dated Taylor Otwell’s commits to August 24–25, 2026. Laravel News said versions 12.68.0 and 13.29.0 were released on August 25, almost two months before the advisory went public.

The sources disagree on which versions are patched. The advisory lists every release below 12.68.0 as affected, and Laravel News reported patches only for the 12.x and 13.x branches. Hakai’s review of the Git history found the fix first shipped in v13.27.0 and was backported to 11.x as v11.56.1, a release the advisory does not mention.

Manasijev also reported a second, medium-severity flaw that was published the same day. That flaw, GHSA-5wcm-3v2w-8362 (CVSS 6.5), lets a crafted request to a read-only JSON:API resource endpoint trigger a destructive database operation on a related table. It affects versions 12.45.0 through 12.67.x and 13.x releases before 13.27.0.

Cyber Kendra found no reports of in-the-wild exploitation as of Wednesday. Developers should update laravel/framework to 13.29.0 or 12.68.0, or to 11.56.1 on the 11.x branch. Apps with a guard set to the token driver in config/auth.php that run on MySQL or MariaDB should be patched first. Running composer audit checks installed packages against published advisories.