Laravel: TokenGuard authentication bypass (CVE-2026-114509) fixed in 12.68.0 and 13.29.0, exploited in the wild
Published 28/10/2026 10:58
Timeline
2 events over 8 d
- 20/10/2026ConfirmedCERT-FR advisories+8 d
- 28/10/2026 10:58Published on WatchtowerPro CISO
In short
Laravel's built-in TokenGuard can be tricked by a crafted request so that an attacker with no login is signed in as an existing user. VulnCheck KEV lists the flaw as exploited, and fixes are available in Laravel 12.68.0 and 13.29.0. Apps that use the token guard on MySQL or MariaDB should be updated first. GreyNoise reports a public exploit for CVE-2026-114509 (28/10/2026).
How bad is it
Critical. An attacker with no login can send a crafted request to a vulnerable Laravel API and be signed in as an existing user, possibly an administrator. Exploitation is reported by VulnCheck KEV.
Confirmed by the vendor or a CERT - no exploitation reported yet.
Severity score
CVSS 4.0 from NVD, from github.com, read 28/10/2026.
What an attacker needs
- Internet access to itEnough
- A loginNot needed
- A user to clickNo
- Special settingsUsually yes
Red helps the attacker, blue holds them back, grey is not published yet.
If it works, an attacker can
- Read the data it holds
- Change or delete that data
- Take it offline
Type: authentication bypass.
A score is the worst case for the flaw, not a verdict on any one system. How we score · ReconX customers see which of their own systems are affected.
Affected versions
- Laravel 12.x before 12.68.0 and 13.x before 13.29.0 (GitHub Advisory Database gives the 13.x range as >= 13.0.0, < 13.29.0).
- Requires the built-in token guard (driver => token) with the Eloquent users provider, on MySQL or MariaDB, and a JSON request body.
- Worse when tokens are stored in plaintext (hash => false), or when the first user in the users table is an administrator.
- Old apps are at risk: Laravel 5.x to 7.x shipped the token guard by default, and apps upgraded to 8+ keep the old guard configuration.
- Sanctum, Passport and apps using only a session guard are reported as not affected by third-party sources, not by the vendor text.
Fixed in
- 12.68 branch: 12.68.0
- 13.29 branch: 13.29.0
What to do now
- Check config/auth.php for any guard with driver => token and check which database is in use (MySQL/MariaDB is exposed).
- Upgrade laravel/framework to 12.68.0 or 13.29.0 or later as a priority, because exploitation is reported. Start with apps that use the token guard on MySQL/MariaDB.
- Updating beyond the minimum is sensible: other advisories from the same release batch need 12.69.0 or 13.30.0 for the XSS fix.
- If you cannot update yet, apply interim measures: reject non-string api_token values in middleware, set 'hash' => true, or add a WAF rule. These reduce exposure and do not make the application safe.
- For Laravel 11 and older, plan a move to a supported branch; until then use the middleware or WAF workaround and check these apps by hand, as Composer audit and Dependabot may stay silent.
- Search logs for JSON bodies where api_token is an array, such as "api_token":[0], and for database queries with where api_token in (0); also look for successful API authentication with no preceding login. If you find any, treat the affected accounts as compromised.
ReconX customers see the full notice - and their own systems
Our customers are alerted at every phase. Until a patch exists, the ReconX agent watches their servers from the inside for anomalies, and our outside view - the attacker's view - shows which systems to fix first.
In ReconX: the full analysis, 4 open questions, followed up as sources answer and all 4 sources with their dates. And technology matching: which of your systems run Laravel, at which version, fixed or not - and what each one needs.
Main sources
Multiples vulnérabilités dans Laravel (20 octobre 2026) CERT · [UPDATE] [hoch] Laravel: Mehrere Schwachstellen CERT · Known exploited (VulnCheck KEV): Laravel Laravel Framework - Laravel Laravel Framework Improper Authentication Research