CVE-2026-114509: Laravel TokenGuard authentication bypass through non-string API credentials
Laravel's built-in TokenGuard can be bypassed on MySQL and MariaDB. An unauthenticated attacker sends a non-string API token, such as an array, and the lookup matches an unintended user, so the attacker is logged in as that user. Any app using the standard token API guard is affected. Upgrade laravel/framework to 12.68.0 or 13.29.0.
Published Oct 23, 2026 · Analysis Oct 24, 2026
What an attacker can do
TokenGuard reads the API token from the request (the api_token input by default) and passes it to the user provider's retrieveByCredentials lookup. Before the fix, the guard only checked that the value was not empty. It never checked that it was a string. A request such as ?api_token[]=0 delivers an array instead of a token.
The advisory says that under certain database configurations (MySQL and MariaDB) the query built from that value matches an unintended user record instead of failing. The attacker does not need to know a valid token.
In practice, anyone who can reach a route protected by the token guard can authenticate as another existing user. That gives account takeover on every route behind the guard, including API endpoints that expose or change data. The attack needs network access only. It needs no account, no user interaction and no malicious repository. The CVSS vector rates complexity low, with an attack-requirements flag for the database configuration.
Apps that use Sanctum, Passport or session guards instead of the plain token driver are not described as affected.
Who is affected
Affected: laravel/framework 13.0.0 up to but not including 13.29.0, and every release below 12.68.0. The risk applies to apps that configure a guard with the token driver (TokenGuard) and run on MySQL or MariaDB.
Check the installed version:
composer show laravel/frameworkThen look in config/auth.php for a guard whose driver is token.
laravel/framework
- Ecosystem
- Composer (PHP)
- Affected
- >= 13.0.0, < 13.29.0
- Fixed in
- 13.29.0
- Check
composer show laravel/framework
laravel/framework
- Ecosystem
- Composer (PHP)
- Affected
- < 12.68.0
- Fixed in
- 12.68.0
- Check
composer show laravel/framework
How to fix it
Upgrade to 12.68.0 on the 12.x line or 13.29.0 on the 13.x line:
composer update laravel/frameworkThe fix, in src/Illuminate/Auth/TokenGuard.php, accepts only string tokens. user() now returns null and validate() returns false for any non-string input. The advisory lists no workarounds, so upgrading is the only remediation it gives.
How to tell if you were hit
Search web server and application logs for requests that pass the token as an array or other non-scalar form, for example api_token[]= or api_token[ in the query string, or a JSON body where the token field is an array or object. Look for successful authenticated requests on token-guarded routes that come from clients you do not know. Compare them with the users those requests acted as. The advisory gives no indicators of compromise beyond this, so treat these as heuristics.
Original advisory
From the GitHub Advisory Database (CC BY 4.0).
Laravel's built-in TokenGuard, when configured with a standard token-based API guard, may be bypassed to authenticate as an arbitrary existing user without knowledge of their valid API token.
Under certain database configurations (MySQL/MariaDB) an attacker can submit a specially crafted, non-string credential value that is mishandled during the authentication lookup, causing the underlying query to match an unintended user record rather than failing authentication as expected.
Impact
An unauthenticated attacker may authenticate as another user without possessing that user's API token, leading to authentication bypass and account takeover on any route protected by the affected guard.
Credited to KIKOmanasijev.
Questions
- Does CVE-2026-114509 affect Laravel on PostgreSQL or SQLite?
The advisory names MySQL and MariaDB as the database configurations where the crafted value matches an unintended user. It does not describe other databases. Upgrading is still the safe course, because the fix rejects non-string tokens before the query runs.
- Which Laravel versions fix this?
12.68.0 for the 12.x line and 13.29.0 for the 13.x line. All 12.x releases below 12.68.0 and 13.x releases below 13.29.0 are vulnerable.
- Do I need to be logged in to exploit it?
No. The advisory describes an unauthenticated attacker who authenticates as another user without that user's API token, on any route protected by the affected guard.
- Is this exploited in the wild?
None of the sources read say so. The advisory gives no exploitation details and the entry is not in CISA's Known Exploited Vulnerabilities catalog.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. The analysis is written by an AI model from the sources listed above and checked by automated rules before it is published. Check versions against the vendor's advisory before you act. Methodology
