Previdian has observed attempts to exploit CVE-2026-114509, an authentication bypass in Laravel’s built-in TokenGuard, against one of our real Laravel application honeypots.

The activity was first observed on 27 October 2026 at around 15:11 UTC. The payload reached the application’s authentication lookup, but the query failed. No authentication bypass or account takeover occurred in this activity.

Previdian Watch had been tracking this vulnerability since 22 October. The Previdian CVE record now includes first-party request evidence from our sensors.

What we observed

Our HTTP logs recorded 19 requests from one source IP, 82.102.25[.]62, in a brief burst. This included reconnaissance followed by GET and POST requests carrying the authentication-bypass payload. Five GET attempts appear in the CVE-linked observations; the wider request sequence also includes the reconnaissance and POST requests described below.

The source first requested the application homepage, which returned HTTP 200, then checked common Laravel paths including /.env, /sanctum/csrf-cookie, /telescope, /_debugbar/open and /horizon. An initial unauthenticated request to /api/user returned HTTP 401.

It then sent the following JSON body to five API paths, using both GET and POST:

{"api_token": [0]}

The captured GET requests used Content-Type: application/json and Accept: application/json. Their body matches the payload in the public proof of concept.

API path	GET with the payload	POST with the payload
/api/user	HTTP 500; reached TokenGuard and failed during the user lookup	HTTP 405; the route accepted GET
/api/me	HTTP 404; route missing	HTTP 404; route missing
/api/profile	HTTP 404; route missing	HTTP 404; route missing
/api/v1/user	HTTP 404; route missing	HTTP 404; route missing
/api/v1/me	HTTP 404; route missing	HTTP 404; route missing

Of the requests carrying the payload, only GET /api/user reached TokenGuard. None of the requests returned a user.

How the authentication bypass works

The payload supplies an array containing the number zero where the application expects an API token string.

Before the fix, TokenGuard could pass a nonempty, non-string credential to the user provider. Laravel’s security patch adds string-type checks before the affected lookups, including a regression test for api_token => [0].

Laravel’s Eloquent user provider treats an array-valued credential as a list of possible values. This produces a lookup equivalent to:

WHERE api_token IN (0)

In an affected MySQL or MariaDB configuration, the database can compare a stored string token numerically against zero. A nonnumeric token can consequently match even though the requester never supplied the valid token. Laravel’s own query-builder documentation describes this string-number comparison behavior.

If the lookup returns an existing user, the affected guard can treat the request as authenticated. The Laravel advisory describes unauthorized authentication to routes protected by the affected guard.

Exposure depends on the authentication guard, lookup configuration, database behavior and existing user data. A Laravel application or an /api/user endpoint alone does not establish that the bypass will work.

Why the attempt failed on this honeypot

This particular honeypot ran Laravel 8 with SQLite. Its /api/user route used auth:api and reached TokenGuard, which passed the array into the user lookup.

The application returned HTTP 500 with the following database error:

SQLSTATE[HY000]: General error: 1 no such table: users
(SQL: select * from "users" where "api_token" in (0) limit 1)

The "api_token" in (0) expression shows that the crafted array reached the database lookup. The immediate reason the query failed was the absence of the users table.

The sensor also used SQLite, outside the MySQL/MariaDB configuration described in the vendor’s advisory. However, this response does not test how SQLite would compare an existing token: the missing table stopped the query first.

The payload and application response support the CVE mapping and the classification as attempted exploitation. The database error and route responses establish that this attempt failed.

What defenders should do

Identify exposed TokenGuard routes and apply the fix

Check which authentication guard and user provider protect your exposed API routes. Prioritize applications using the affected built-in TokenGuard lookup with MySQL or MariaDB.

Laravel’s advisory lists the following patched versions:

Laravel branch	Patched version
12.x	12.68.0 or later within 12.x
13.x	13.29.0 or later within 13.x

For older applications, establish an upgrade path to a release containing the fix. The failure on this Laravel 8 honeypot does not establish that other Laravel 8 deployments are safe.

Do not rely on MySQL strict SQL mode as a substitute for the framework fix. The MySQL documentation demonstrates that numeric comparisons against nonnumeric strings can still match rows in a SELECT query when strict mode is enabled.

Hunt for the payload and investigate the outcome

Where request-body telemetry is available, look for api_token supplied as an array, particularly the observed {"api_token": [0]} payload. Include GET requests in the search: in this case, a GET request reached the authentication lookup.

Use 82.102.25[.]62 as an observed source indicator and the API paths above as hunting leads. The source IP and paths are not, by themselves, proof of a successful bypass.

Correlate matching requests with application authentication results, protected data returned in responses, and subsequent account activity. A payload match establishes something to investigate; the outcome needs separate evidence.

What we expect next

With this payload already reaching the vulnerable lookup, we expect to see successful exploitation against our other Laravel honeypots running affected MySQL or MariaDB configurations soon. This is an expectation based on the activity and exploit mechanics; the observation documented here remains a failed attempt.

Teams running affected TokenGuard deployments should review their exposure and apply the vendor’s fix.

View Previdian’s CVE-2026-114509 record for the vulnerability details and observed activity.