Laravel CVE-2026-114509: TokenGuard Auth Bypass Fix

A critical vulnerability in the Laravel PHP framework, tracked as CVE-2026-114509, affects the built-in TokenGuard used for simple token-based API authentication. According to the GitHub advisory, an unauthenticated attacker may be able to authenticate as another existing user without knowing that user's API token. The advisory rates it Critical, with a CVSS v4 score of 9.2.

If you run a Laravel application that protects API routes with a token guard, and your database is MySQL or MariaDB, you should check your framework version now. Fixes are available in laravel/framework 12.68.0 and 13.29.0.

What happened

The advisory was published against laravel/framework on Oct 19, 2026, according to the GitHub page. The same page lists publication by the National Vulnerability Database on Oct 21 and in the GitHub Advisory Database on Oct 23, 2026, with the last update on Oct 23. The CVE record is CVE-2026-114509.

The flaw is an authentication bypass. On routes protected by the affected guard, the advisory says the impact is account takeover, meaning the attacker acts as another user of your application.

Technical details in plain terms

The advisory says that when Laravel's TokenGuard is configured as a standard token-based API guard, then under certain database configurations (MySQL/MariaDB) an attacker can submit a specially crafted, non-string credential value. That value is mishandled during the authentication lookup, so the underlying query matches an unintended user record rather than failing authentication as expected.

In plain terms, the check that should answer 'no valid token, access denied' can instead end up returning a real user. The advisory does not describe the exact payload, assign a weakness class (no CWE is listed in the research), or explain the lookup in more depth, and this article does not either.

Who is affected

Based on the advisory, you are in scope if all of the following are true:

• You use laravel/framework in an affected version range (listed below).
• Your application uses Laravel's built-in TokenGuard, configured as a standard token-based API guard.
• Your database is MySQL or MariaDB, in the configurations the advisory refers to as 'certain database configurations'. The advisory does not spell out which configurations, so do not assume yours is safe.

The advisory describes only the built-in TokenGuard configured as a standard token-based API guard. It does not discuss other guards or authentication packages, so it gives no basis for calling them safe or affected. If you are unsure which guard protects your API routes, check your configuration rather than guessing, and upgrade the framework regardless.

How to check your exposure

1. Open composer.lock in your project, or run composer show laravel/framework, and note the installed version.
2. Compare it with the ranges above. Anything below 12.68.0, or from 13.0.0 up to but not including 13.29.0, is in the vulnerable ranges.
3. Open config/auth.php and look at the guards section. A guard using the token driver is typically the built-in TokenGuard. Note which routes use it, often through auth:api middleware.
4. Confirm your database driver in config/database.php and your environment file. MySQL and MariaDB are the ones the advisory names.
5. Check every environment: production, staging, queue workers and any old copies of the app that still serve traffic.

Also consider hosted or client projects. Agencies and hosting administrators often manage many Laravel installs, and a quick search of lockfiles across servers is the fastest way to build an inventory.

What to do now

1. Upgrade laravel/framework to 12.68.0 or 13.29.0, depending on your branch. The fixes are in the v12.68.0 and v13.29.0 releases.
2. Run composer update laravel/framework in a test environment first, run your test suite, then deploy. Confirm the new version in composer.lock after deployment.
3. If you cannot upgrade immediately, consider reducing exposure, for example by restricting access to token-protected routes by network or at a web application firewall where that is practical. This is a stopgap, not a fix, and the advisory does not list an official workaround.
4. Review access logs and application logs for unusual activity on token-protected routes since the advisory was published, such as requests from unfamiliar addresses acting on accounts they should not reach.
5. If you suspect misuse, consider rotating API tokens for affected users and reviewing recent account changes. Rotating tokens is not described as closing the bypass itself, so the upgrade still comes first.
6. Consider whether the API needs the simple TokenGuard at all. For higher-risk applications, a more fully featured token system with hashed, scoped and expiring tokens can limit the damage of any single flaw.

Detection and monitoring afterwards

The advisory does not describe how exploitation would look in traffic, so there is no known signature to search for. General practice still helps: log the authenticated user ID alongside the client address and user agent on API routes, and review for accounts acting from unexpected locations or devices, or sudden bursts of requests to token-protected endpoints. These are broad hygiene signals, not indicators confirmed for this flaw.

A web application firewall can add an extra layer of filtering in front of an app, as explained in What is a WAF?, but it does not replace patching. You can also use Webforta Scan to run read-only checks on sites you have verified, and Webforta Monitor to watch uptime, certificates and header changes after a deployment. Neither can tell you whether this specific flaw is present in your code, so confirm the framework version yourself.

For a broader routine, see the small business website security guide.

Timeline

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

• CVE-2026-114509 - GitHub Advisory Database (github.com)

Tags: Laravel, CVE-2026-114509, authentication bypass, PHP, API security