Laravel TokenGuard auth bypass CVE-2026-114509: fixed in August, disclosed in October

What happened

Laravel published advisory GHSA-f9x3-7vq9-cph6 on 19 October 2026. It covers an authentication bypass in the framework's built-in TokenGuard. The CVE, CVE-2026-114509, reached NVD on 21 October 2026.

This is not a fresh patch. Laravel committed the fix on 25 August 2026 (UTC). Fixed releases went out the same day. The release notes did not flag it as a security fix.

So the fix is almost two months older than the advisory. If you updated Laravel since late August, you likely already have it.

GitHub, acting as CNA, scores it CVSS 4.0 9.2 (Critical). NVD has not published its own score yet.

The cause, in plain terms

TokenGuard checked only that the API token was not empty. It did not check that the token was a string.

A non-string value could therefore reach the database lookup. On MySQL and MariaDB, the comparison then converts the stored text token to a number. The advisory says this can make the query match an unintended existing user.

The guard then treats the request as logged in as that user. No valid token is needed.

The fix is one strict type check. Non-string credentials are now rejected before any lookup.

Who is affected

Per the advisory and NVD:

• laravel/framework 13.x before 13.29.0
• laravel/framework before 12.68.0

Hakai Security also lists 11.x before 11.56.1. The 11.x backport commit and the v11.56.1 tag exist in Laravel's repository, both dated 25 August 2026. The advisory itself does not mention 11.x.

You are only exposed if both conditions hold:

• A guard uses the built-in token driver (the classic auth:api setup).
• The users table lives on MySQL or MariaDB.

That is a smaller group than a 9.2 score suggests. The advisory names no other database. Laravel Sanctum and Laravel Passport ship their own guards and are not named in the advisory.

What is confirmed

• Advisory GHSA-f9x3-7vq9-cph6, published 19 October 2026, rated Critical.
• CVSS 4.0 9.2 from GitHub as CNA. The score marks "attack requirements present", which matches the database condition.
• Fixed versions 13.29.0 and 12.68.0, released 25 August 2026.
• Fix commits by Taylor Otwell, dated 25 August 2026 (UTC), on the 13.x, 12.x and 11.x branches.
• Git history shows the 13.x fix first shipped in 13.27.0. The advisory conservatively says 13.29.0.
• NVD lists the weaknesses as CWE-287 and CWE-1287.
• Hakai Security (Yokai Research) published an analysis on 20 October 2026 and a public PoC with a Docker lab. The PoC is not executed by ThreatWire. We only read it.
• Not in CISA KEV as of 25 October 2026.

What is not confirmed

• Exploitation in the wild. No source we checked reports attacks. A public PoC is not the same as active use.
• How many apps are exposed. Nobody has published a count of Laravel apps still using the token driver on MySQL or MariaDB.
• The 11.x line in the advisory. The 11.56.1 fix comes from Hakai's analysis and Laravel's git history, not the advisory text.

ThreatWire does not publish payloads or reproduction steps.

What to do

1. Update laravel/framework to 13.29.0 or later, or 12.68.0 or later. On 11.x, use 11.56.1 or later.
2. Check your guards. Look for any guard using the token driver in your auth config. If none, this bug does not reach you.
3. Plan a move to Sanctum or Passport if you still rely on the legacy token guard.
4. Review API access logs since late August 2026 on token-protected routes. Look for logins that do not match known clients.
5. Rotate API tokens if you find anything odd.

If you run Laravel, also check the PHP runtime itself. See our coverage of the PHP2Shell critical fixes and the probe logged before disclosure.

Related coverage

CVE record: CVE-2026-114509. Browse the CVE tracker.

Sources: Laravel's GitHub advisory, NVD, CVE.org, Laravel fix commits and releases, Hakai Security and the CISA KEV catalog. Links are in the references list.