Laravel TokenGuard (CVE-2026-114509): When the Wrong API Token Opens the Right Account

Imagine sending an API a credential that doesn't belong to anyone and getting access to a real user's account.

That's essentially what happens with CVE-2026-114509, a critical authentication bypass in Laravel's TokenGuard.

The attacker doesn't need to steal a password, guess an API token or trick anyone into clicking a link. Under certain conditions, submitting an array containing a number can fool the authentication process into accepting an unrelated user's stored token.

It's a small input-validation mistake with potentially serious consequences for applications relying on the affected authentication method.

What Is CVE-2026-114509?

Disclosed by Laravel on 19 October 2026, CVE-2026-114509 affects the framework's built-in TokenGuard, which some applications use to authenticate API requests.

The flaw was reported by security researcher KIKOmanasijev and received a CVSS 4.0 score of 9.2 (Critical).

The vulnerability is tracked under GitHub Security Advisory GHSA-f9x3-7vq9-cph6.

Its impact depends on how an application handles authentication. Laravel applications using other guards, including properly configured Sanctum authentication, aren't automatically vulnerable to this particular TokenGuard issue.

The vulnerable setup typically involves an explicitly configured token-based API guard, unhashed stored tokens and an affected MySQL or MariaDB database configuration.

The API Token That Wasn't a Token

API tokens work a little like passwords.

An application issues a credential to a user or client. When that client makes a request, it supplies the token so the application can verify its identity.

For example, a fitness booking platform might use tokens to identify members accessing their class schedules through a mobile app.

Each request should contain a valid token associated with the member.

Laravel's TokenGuard handles this lookup in applications configured to use its built-in token authentication.

The problem was that the vulnerable guard didn't properly check the type of value being submitted.

A valid API token should be a string. But Laravel also accepts structured request data, including arrays. And that's where the trouble starts.

How a Number Slips Through Authentication

In vulnerable versions, TokenGuard checks whether the supplied token value is empty before attempting to look up the user.

An array containing an integer, such as:

isn't considered empty by PHP. So it can pass the initial check, even though it isn't a valid token string. Laravel then passes that array to its user provider.

The provider interprets an array differently from an ordinary token. Rather than looking for one exact credential, it constructs a database query using an IN condition.

In a simplified example, the query becomes:

That might look harmless. After all, a long random API token shouldn't match the number zero. But MySQL and MariaDB have another behaviour that makes this dangerous.

Why MySQL Can Mistake a Random Token for Zero

When MySQL compares a string with a number, it may convert the string into a numeric value.

A token beginning with nonnumeric characters can become zero during that comparison.

Imagine a stored API token resembling:

It's clearly different from the integer 0. However, in the affected comparison, MySQL can interpret that nonnumeric string as zero.

The database may therefore return the user record even though the attacker never supplied the correct token.

Laravel receives that record and treats the request as authenticated.

The complete failure involves three components:

1. TokenGuard accepts the wrong input type. An array passes the initial nonempty check.
2. Laravel changes the database lookup. The array becomes an IN comparison rather than an ordinary string match.
3. MySQL performs numeric conversion. A stored text token can match the number supplied in the request.

The result is authentication as an existing user without possessing their valid credential. Exact account returned depends on the database records and query behaviour. The exploit doesn't guarantee that an attacker can select any particular account.

What Could an Attacker Do With Access?

The vulnerability affects routes protected by the vulnerable TokenGuard configuration. As such, the impact therefore depends on what those routes allow.

For a booking platform, an attacker might gain access to a member's private information or perform account-level actions available through the API.

In another application, the compromised identity might have access to sensitive business records or administrative functionality.

Once authentication succeeds, the request may proceed through ordinary application logic with that user's permissions.

That makes CVE-2026-114509 an account takeover risk, even though the attacker never obtains the original API token.

It doesn't automatically provide a shell or remote code execution. The consequences depend on the permissions and functionality available to the authenticated account.

Is Every Laravel Application Vulnerable?

No, not every Lavarel application is vulnerable. The issue affects a particular authentication path rather than Laravel applications generally.

An application needs the vulnerable TokenGuard configuration and database behaviour for this bypass to work.

According to Laravel's advisory, affected framework versions include releases before 12.68.0 and Laravel 13 releases before 13.29.0.

Applications using MySQL or MariaDB with an explicitly configured token-based guard deserve particular attention.

The vulnerable scenario also involves unhashed token handling. Applications that hash tokens before database comparison have a different authentication path, although updating the framework remains the recommended response.

Modern Laravel applications frequently use Laravel Sanctum, which provides a different token authentication mechanism.

How to Spot a Possible Authentication Bypass

One challenge with CVE-2026-114509 is that a successful exploit may look like an ordinary authenticated API request.

The application can return a successful response associated with a legitimate user because its authentication lookup has already been fooled.

A simple count of failed logins may therefore miss the relevant activity.

(1) Start with the routes protected by the affected guard.

(2) Look for unusual requests where the API token is supplied as an array or another unexpected data type instead of a string. In particular, investigate JSON request bodies containing an array-valued api_token field.

(3) Review successful authentication events that don't correspond to an expected token-authentication flow.

Your Logs Might Not Show the Important Part

Standard web server access logs often record the request method, URL, response code and source address. They may not preserve the JSON request body.

That means a suspicious request could appear as an ordinary successful API call without revealing the malformed token responsible.

Security teams should review their existing API telemetry and determine whether appropriate request-validation failures can be recorded safely.

Avoid indiscriminately logging valid API credentials or sensitive request bodies.

Where a WAF or API gateway can detect malformed credential types, its events may provide useful supporting evidence.

CrowdSec's exploit tracking has documented attempts involving array-valued tokens, although it had not observed significant exploitation activity across its network at the time of reporting.

That supports monitoring for the technique without presenting it as evidence of widespread compromise.

How to Fix CVE-2026-114509

Laravel addressed the vulnerability by introducing stricter validation of token inputs.

The corrected TokenGuard checks that a credential is a string before using it in the authentication lookup. An array that previously passed the initial check is now rejected.

For affected applications, update the laravel/framework dependency to a fixed, supported version and deploy the updated application. Then verify that authentication behaves correctly and that malformed credentials are rejected.

Security teams should also review any exposed routes that rely on the affected guard.

Can You Get In Without a Token?

In TryHackMe's Laravel TokenGuard: CVE-2026-114509 room, you'll investigate a vulnerable Laravel API in a controlled environment.

The room follows a fictional class-booking platform whose security team needs to determine whether its API is exposed.

You'll examine how TokenGuard processes credentials, explore the database comparison behind the bypass and investigate what the attack leaves behind.

Then you'll switch to the defender's perspective to understand how to identify the issue and verify the fix. You only need basic HTTP, command-line and SQL knowledge to get started.