CVE-2026-114509: 
PHP vulnerability analysis and mitigation

CVE-2026-114509 is a critical authentication bypass vulnerability in Laravel's built-in TokenGuard component, affecting the Laravel framework when configured as a standard token-based API guard. The flaw allows an unauthenticated attacker to bypass authentication and take over arbitrary user accounts on routes protected by TokenGuard by submitting a crafted non-string credential value. Affected versions include all Laravel framework releases prior to 12.68.0 on the 12.x branch, and versions 13.0.0 through 13.28.x on the 13.x branch. The vulnerability was disclosed on October 21, 2026, and carries a CVSS v4.0 base score of 9.2 (Critical) (GitHub Advisory, Feedly).

The root cause is improper input type validation (CWE-287: Improper Authentication; CWE-1287: Improper Validation of Specified Type of Input) in src/Illuminate/Auth/TokenGuard.php. The user() method previously checked if (! empty($token)) before performing a credential lookup, which does not reject non-string values such as arrays. When a crafted array value (e.g., api_token=[0]) is submitted, PHP's empty() evaluates it as non-empty, and the value is passed to the underlying database query. Under MySQL or MariaDB, loose type coercion during the SQL lookup can cause the query to match an unintended existing user record, effectively authenticating the attacker as that user. The fix, applied in commits 8dbb08b (12.x) and 9b21ce0 (13.x), adds an explicit is_string() check: if (is_string($token) && ! empty($token)) in user() and a corresponding guard in validate() (GitHub Commit 12.x, GitHub Commit 13.x).

Successful exploitation allows an unauthenticated remote attacker to authenticate as an arbitrary existing user on any API route protected by TokenGuard, resulting in full account takeover. The impact spans high confidentiality, integrity, and availability of the vulnerable system — an attacker gains the same access level as the impersonated user, potentially including access to sensitive data, the ability to modify or delete records, and the ability to perform privileged actions within the application. Depending on the application's design, this could facilitate lateral movement to other systems or services that trust the compromised account's credentials (GitHub Advisory, Feedly).

As of the disclosure date (October 21, 2026), there is no public proof-of-concept exploit code and no evidence of active in-the-wild exploitation (Feedly). The EPSS score is reported as 0.0, and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no user interaction, and is network-accessible, making it highly automatable once exploitation techniques become public. The attack requirement of a specific MySQL/MariaDB database configuration (AT:P) slightly limits the attack surface compared to a fully universal exploit.

1. Reconnaissance: Identify Laravel applications using token-based API authentication (TokenGuard) backed by MySQL or MariaDB, running framework versions prior to 12.68.0 or between 13.0.0 and 13.28.x. Tools like Shodan, Censys, or manual HTTP fingerprinting can help identify Laravel-based APIs.
2. Identify a protected API endpoint: Locate an API route that requires TokenGuard authentication, typically by reviewing API documentation, error responses, or common Laravel route patterns (e.g., /api/user, /api/profile).
3. Craft a non-string token payload: Instead of providing a valid string API token, craft a request that submits the api_token parameter as an array (e.g., api_token[]=0 in a query string or POST body), exploiting PHP's handling of array-typed query parameters.
4. Submit the crafted request: Send the HTTP request to the protected endpoint: GET /api/user?api_token[]=0. The TokenGuard user() method passes the array to the database query without type validation.
5. Trigger database type coercion: Under MySQL/MariaDB, the array value is coerced during the SQL lookup in a way that matches an unintended user record (e.g., a user with a numeric or empty token value), causing the guard to authenticate the attacker as that user.
6. Achieve account takeover: The attacker is now authenticated as the matched user and can perform any actions that user is authorized to perform on the application (GitHub Advisory, GitHub Commit 12.x).

• Network: HTTP requests to API endpoints where the api_token parameter is submitted as an array (e.g., ?api_token[]=0 or api_token[0]=0 in query strings or POST bodies) rather than a standard string value; unexpected successful 200 OK responses to API routes from unauthenticated or unknown clients.
• Logs: Laravel application logs (laravel.log) showing authenticated sessions for users who did not initiate a login; web server access logs (e.g., nginx/Apache) containing requests with array-formatted api_token parameters to protected API routes.
• Application Behavior: Unexpected API activity under legitimate user accounts (e.g., data access, modifications) at unusual times or from unfamiliar IP addresses, which may indicate an attacker operating under an impersonated account.

The primary remediation is to upgrade the Laravel framework to version 12.68.0 or later (for 12.x users) or 13.29.0 or later (for 13.x users), which include the fix enforcing is_string() validation on token credentials (GitHub Release 12.x, GitHub Release 13.x). As a temporary workaround for teams unable to upgrade immediately, add explicit input validation middleware or request validation rules to ensure the api_token parameter is a string before it reaches TokenGuard processing. Additionally, consider implementing supplementary authentication verification (e.g., additional middleware checks) on sensitive routes protected by TokenGuard until the patch can be applied (GitHub Advisory).

The vulnerability was reported by researcher KIKOmanasijev and the advisory was published by andrei-laravel on the Laravel GitHub Security Advisories page (GitHub Advisory). Early community discussion appeared on Mastodon/Infosec.exchange shortly after disclosure, and the vulnerability was picked up by automated CVE tracking services including radar.offseq.com and cvefeed.io within hours of publication (Feedly). No major vendor statements beyond the GitHub advisory or significant media coverage have been identified at this time.