Laravel TokenGuard auth bypass: does CVE-2026-114509 apply to you?

Laravel has fixed an authentication bypass in its built-in TokenGuard, tracked as CVE-2026-114509 (GitHub advisory GHSA-f9x3-7vq9-cph6). The advisory rates it critical, CVSS v4 9.2. The fixed releases are laravel/framework 12.68.0 and 13.29.0.

Before anything else: this is not "every Laravel app is vulnerable". The advisory is conditional, and both conditions have to hold. In NVD's wording, the bug is that "TokenGuard configured as a standard token-based API guard does not reject a crafted non-string credential", and "Under affected MySQL or MariaDB configurations, the authentication lookup can match an unintended existing user". When both apply, the result is serious: "an unauthenticated attacker to bypass authentication and take over an account on routes protected by TokenGuard."

The GitHub advisory was published on 19 October 2026 and the NVD record on 21 October. NVD lists the record as "Awaiting Analysis", so the 9.2 score is the advisory publisher's, not yet NVD's own.

Does it apply to you? Three questions

1. Which framework version is deployed? Read it from the lock file you actually ship, not from composer.json:

   composer show laravel/framework | grep versions
   # or, inside the running app
   php artisan --version

   The affected ranges are below 12.68.0 on the 12.x line and below 13.29.0 on 13.x. Note what that range includes: anything older than 12.68.0, including Laravel 11 and earlier. The advisory lists fixed releases only for 12.x and 13.x, so an older major has no patch on its own line; the fix there is an upgrade to 12.68.0 or later.
2. Do you use the token guard? Open config/auth.php and look at guards. The condition is a guard with 'driver' => 'token', typically the old api guard used with auth:api middleware. A default app with only the session web guard does not use TokenGuard. Sanctum and Passport have their own guards; check your configuration rather than assuming either way, and search your routes for auth:api.
3. Is the database MySQL or MariaDB? Check DB_CONNECTION in your environment. The advisory names those two as the affected configurations.

If the answer to all three is yes, upgrade now. If you are not sure about the guard, upgrade anyway: a patch-level framework bump within your major line is the cheapest of the three to settle.

The fix is in your app, not in your server

Unlike a PHP or Node.js runtime patch, this one is a Composer dependency inside the application you deploy. No server update or base image fixes it. The work is yours:

composer update laravel/framework --with-dependencies
composer show laravel/framework | grep versions   # expect 12.68.0+ or 13.29.0+
git add composer.lock && git commit -m "Bump laravel/framework for CVE-2026-114509"

Then deploy, and check the version from inside the running app afterwards. The lock file is what decides which framework code runs, so a commit that changes composer.json without the updated composer.lock changes nothing. Run your test suite before you ship the bump, as with any framework update.

If you deploy with a pinned lock file and a rebuild on push, the bump only reaches production when that deploy completes; see our note on why a pushed commit is not the same as a running one.

Sources: GitHub Security Advisory GHSA-f9x3-7vq9-cph6, published 19 October 2026; NVD, CVE-2026-114509, published 21 October 2026. Both read 24 October 2026.