> ## Content Index
> Fetch the complete content index at: https://blog.previdian.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Laravel CVE-2026-114509 authentication bypass attempts observed by Previdian
- URL: https://blog.previdian.com/laravel-cve-2026-114509-authentication-bypass-attempts-observed-by-previdian/
- Published: 2026-10-27T15:54:42.000Z
- Updated: 2026-10-27T15:54:42.000Z
- Author: Ryan Dewhurst

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](https://previdian.com/CVE-2026-114509?ref=blog.previdian.com) 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:

```json
{"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](https://github.com/hakaioffsec/CVE-2026-114509-PoC?ref=blog.previdian.com).

| **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](https://github.com/laravel/framework/commit/8dbb08bccac1be095dba4a9d259a419620f1e8a5?ref=blog.previdian.com) adds string-type checks before the affected lookups, including a regression test for `api_token => [0]`.

Laravel’s [Eloquent user provider](https://github.com/laravel/framework/blob/12.x/src/Illuminate/Auth/EloquentUserProvider.php?ref=blog.previdian.com) treats an array-valued credential as a list of possible values. This produces a lookup equivalent to:

```sql
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](https://laravel.com/framework/docs/12.x/queries?ref=blog.previdian.com#basic-where-clauses) 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](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6?ref=blog.previdian.com) 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:

```text
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](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6?ref=blog.previdian.com) 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](https://dev.mysql.com/doc/refman/8.4/en/type-conversion.html?ref=blog.previdian.com) 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.](https://previdian.com/CVE-2026-114509?ref=blog.previdian.com)