--- title: "Laravel TokenGuard auth bypass (GHSA-f9x3): are you hit?" description: "Laravel's token API guard let attackers log in as any user on MySQL and MariaDB. Fixed in 12.68.0 and 13.29.0. How to check exposure and patch." source: "https://wardio.net/guides/laravel-tokenguard-auth-bypass/" --- **Patching** # Laravel TokenGuard auth bypass: GHSA-f9x3-7vq9-cph6 A critical Laravel advisory with a public proof of concept, but only some apps are exposed. Three checks tell you whether yours is one of them. By David Kabel · Updated 2026-10-21 · 4 min read **The short answer** Your app is exposed if it runs laravel/framework below 12.68.0 or 13.29.0, has a guard using the plain `token` driver, and keeps users in MySQL or MariaDB. An attacker can then log in as an existing user without their API token. Run `composer update laravel/framework`. The fixes have been on Packagist since 25 August 2026, so if you updated after that you are already patched. ## What went wrong Laravel's `TokenGuard` protects routes behind the `token` driver, usually `auth:api`. Before the fix it only checked that the submitted token was not empty before handing it to the user lookup. The advisory says a crafted, non-string value is then mishandled on MySQL and MariaDB, so the query matches an unintended user record instead of failing. The fix rejects arrays and other non-string values before any query runs. Laravel published the advisory on 19 October 2026 with a CVSS score of 9.2 and no CVE ID. Hakai Security published an analysis and a working proof of concept a day later. ## Three checks ``` # 1. Which framework version is installed? composer show laravel/framework | grep versions # 2. Does any guard use the plain token driver? grep -n "'driver' => 'token'" config/auth.php # 3. Is the users table on MySQL or MariaDB? grep -E '^DB_CONNECTION=' .env ``` You need all three to be exposed: an affected version, a guard on the `token` driver, and MySQL or MariaDB. The advisory covers that driver only. Sanctum and Passport register their own drivers and are not listed. Many apps have the old `api` guard in `config/auth.php` without using it on any route, but if the guard exists, patch rather than spend time proving it is unused. ## Fixed versions | Branch | Affected | Fixed in | Notes | | --- | --- | --- | --- | | 13.x | Below 13.29.0 | 13.29.0 | Hakai found the fix first shipped in 13.27.0 | | 12.x | Below 12.68.0 | 12.68.0 | Listed in the advisory | | 11.x | All | 11.56.1 | Backport found by Hakai; not listed in the advisory | | 10.x and older | All | None | Upgrade, or move off the token driver | ## Update ``` composer update laravel/framework --with-dependencies composer show laravel/framework | grep versions php artisan config:clear && php artisan route:clear # Restart queue workers and Octane, which keep the old code loaded php artisan queue:restart php artisan octane:reload # only if you run Octane ``` A long-running process keeps the old framework code until it restarts, so restart queue workers, Horizon, Octane and anything under Supervisor after deploying. ## If the token guard was exposed Treat the API as possibly accessed. Look in your web server logs for requests to token-guarded routes where the token arrived in an unusual shape, such as an array in a JSON body or repeated `api_token[]` query parameters, followed by successful responses. Then rotate the stored API tokens, because anything an attacker did as a user was done with that user's rights. The same researcher reported a second, medium-severity advisory published the same day, GHSA-5wcm-3v2w-8362, where a read-only JSON:API resource request could empty a related table. The same update covers it. ## Gotchas - **The advisory's version list is incomplete.** It names only 12.x and 13.x, but Packagist shows 11.56.1 released alongside them, which Hakai identified as the backport. On 11.x, update to 11.56.1 or later. - **Laravel 10 and older have no fix.** Upgrade the framework, or replace the token guard with Sanctum, which this advisory does not cover. - **Pinned composer.lock.** A deploy that runs `composer install` installs exactly what the lock file says. Commit the updated `composer.lock`, or the server stays on the old version. **How this was checked.** On 21 October 2026 we read the Laravel advisory on GitHub and confirmed the release dates of 11.56.1, 12.68.0, 13.27.0 and 13.29.0 through the Packagist API. The 11.x and 13.27.0 details come from Hakai Security's analysis, not from Laravel. Not tested: the bypass itself. ## Sources 1. [GHSA-f9x3-7vq9-cph6: Token-based API guard auth bypass](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6), laravel/framework, 19 October 2026 2. [GHSA-5wcm-3v2w-8362](https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362), laravel/framework 3. [GHSA-f9x3-7vq9-cph6: Authentication Bypass in Laravel TokenGuard](https://yokai.hakaisecurity.io/en-ghsa-f9x3-7vq9-cph6-authentication-bypass-in-laravel-tokenguard/), Hakai Security, Yokai Research 4. [Critical Token Guard Auth Bypass Fixed in Laravel 13.29 and 12.68](https://laravel-news.com/laravel-token-guard-auth-bypass), Laravel News 5. [laravel/framework](https://packagist.org/packages/laravel/framework), Packagist ## Questions ### What is the Laravel TokenGuard authentication bypass? GHSA-f9x3-7vq9-cph6 is a critical flaw in Laravel's built-in TokenGuard, the class behind the token guard driver. On MySQL or MariaDB, a crafted non-string credential is mishandled during the lookup, so the query matches an existing user instead of failing. An unauthenticated attacker can then act as that user on every route behind the guard. It is rated CVSS 9.2 and had no CVE ID when published on 19 October 2026. ### Which Laravel versions fix GHSA-f9x3-7vq9-cph6? The advisory lists laravel/framework 12.68.0 and 13.29.0 as patched. Hakai Security found the fix in 13.27.0 and a backport in 11.56.1, which the advisory does not mention. All of these were released on 25 August 2026, so an app updated since then is already fixed. Laravel 10 and older have no patch. ### Does the Laravel token guard bypass affect Sanctum or Passport? The advisory covers the token driver only. Sanctum and Passport register their own guard drivers and are not listed in it. Check config/auth.php for any guard with driver set to token. ### Is my Laravel app affected if it uses PostgreSQL? The advisory names MySQL and MariaDB as the database configurations where the bypass works. Update anyway, because the fix rejects non-string tokens before any query runs, and you may move databases later. **Running Laravel on servers nobody watches?** The free review checks framework versions, queue workers and how updates reach production. [Pricing](/pricing/). [Free server review](/contact/)