Laravel Framework CVE-2026-114509

Exploitable only when the application uses Laravel's TokenGuard as a standard token-based API guard to protect one or more routes AND runs on a MySQL or MariaDB backend whose loose/implicit type comparison allows a non-string (array) credential to match an existing user row. Limiting factors: the vulnerable TokenGuard must be the active auth guard (apps using Sanctum/Passport or non-affected comparison behavior are not affected), the backing database must exhibit the MySQL/MariaDB coercion behavior (the vendor's AT:P reflects this non-default/environment-specific requirement), and the installed framework version must be below 12.68.0 or 13.29.0. No valid token, credentials, or user interaction are required once these conditions hold.

This is a genuine high-priority issue, not an inflated CVSS score. CWE-287 authentication bypass with the vendor's CVSS 4.0 vector AV:N/AC:L/AT:P/PR:N/UI:N and full C:H/I:H/A:H (score 9.2) indicates a network-reachable, unauthenticated flaw yielding complete account takeover. The AT:P (attack requirements present) flag is the critical nuance and is corroborated by the description: exploitation depends on a non-attacker-controlled deployment state - TokenGuard used as the standard token-based API guard AND a MySQL/MariaDB backend whose loose type comparison lets a non-string (array) credential coerce-match an existing user. No EPSS score, no CISA KEV entry, and no public exploit were provided, so there is no evidence of active exploitation; however, the public fix commits disclose the exact root cause (missing is_string() checks), which lowers the barrier to building a working exploit. Net: real risk for any Laravel app meeting the TokenGuard+MySQL/MariaDB preconditions, tempered by those preconditions rather than being universally exploitable. The one signal to verify is the breadth of real-world TokenGuard usage, since many Laravel API apps use Sanctum/Passport instead of the legacy TokenGuard.

An attacker targets a Laravel application exposing API routes protected by TokenGuard on a MySQL/MariaDB backend. They send an unauthenticated request supplying the token credential as an array (e.g. api_token[]=0) instead of a string; the database's loose comparison matches an existing user row, and the attacker is authenticated as that account with no valid token. No public exploit was provided, but the fix commits publicly reveal the exact mechanism, making a PoC straightforward to construct.