If your Laravel app authenticates API requests with a token, this one is worth a look today. Laravel just backported a TokenGuard fix to the 10.x line for CVE-2026-114509, and it closes an authentication bypass that needs nothing more than a cleverly shaped query string. Scout Monitoring instruments Laravel out of the box, so if you run an older app that’s still on 10.x, this is exactly the kind of change worth confirming lands cleanly in production. Watch it with Scout for free while you upgrade.
What a Single Bracket Could Do
TokenGuard is the piece of Laravel’s auth system that pulls an API token off the request and hands it to your user provider to look up a matching account. The weakness was in an assumption most of us never think to question: that the token coming in is a string.
It usually is. But request input in PHP isn’t guaranteed to be a scalar. A request like ?api_token[]=0 arrives as an array, not a string, and TokenGuard passed that array straight through to the provider’s lookup. On MySQL and MariaDB, loose type coercion in the comparison could then match that value against an existing row, returning a real user to an attacker who never presented a real credential.
That’s the whole trick. No stolen token, no brute force, just a query parameter wearing square brackets.
The Fix Is Small and Strict
The patch does the obvious, careful thing: it refuses to treat anything that isn’t a non-empty string as a token.
TokenGuard::user()now only performs the user lookup when the token is a non-empty string, so an array or other non-string value never reachesretrieveByCredentials.TokenGuard::validate()returnsfalsewhen the supplied credential isn’t a non-empty string, rather than attempting a comparison.
New tests cover a non-string token for both methods, and both fail against the unpatched guard, which is a good sign the fix is pinned to the actual behavior rather than a surface symptom.
This was already fixed on the 12.x and 13.x branches under the same advisory. The news here is the backport: the fix now reaches teams who are still on Laravel 10, which is a large group, since 10.x is a long-lived line that plenty of production apps never left.
Who Needs to Act
The honest answer is: anyone using TokenGuard on an affected version, most commonly through the api guard with a token driver, or any custom guard built on top of it. Apps that moved entirely to Sanctum or Passport for API auth use different machinery and aren’t the target of this specific advisory, though it’s still worth confirming what your auth.php actually wires up rather than assuming.
The database detail is what makes this more than theoretical. The coercion path is real on MySQL and MariaDB, which together cover a very large share of Laravel deployments. If that’s your stack, treat this as a prompt to upgrade rather than a note for the backlog.
Upgrading Without Drama
Because the change is a strict input check rather than a behavioral rework, upgrading should be quiet. Legitimate tokens are strings, so they keep working exactly as before. The only requests that change behavior are the malformed ones that should never have authenticated in the first place.
Bump to the patched release on your line, run your auth test suite, and you’re done. There’s no migration, no config change, and no new dependency to weigh.
Confirming the Upgrade in Production
A security patch like this shouldn’t change what your app does for real users, and the best outcome is that nothing visibly moves. The question is how you prove that, rather than hope it.
This is where application monitoring earns its place. With Scout, your authenticated endpoints, their response times, error rates, and throughput sit in one view across the app. After you deploy the TokenGuard fix, watch your login and token-authenticated routes for a cycle or two. If the stricter input handling interacts with something unusual in how your app builds requests, it surfaces as a changed error rate or a shifted trace rather than as a surprise from a user. And because Scout ties errors back to the exact endpoint and request that produced them, a new 401 pattern after the bump is immediately traceable instead of a mystery.
Clean dashboards after the upgrade are the signal that you closed an auth bypass without taking anything down with it. Add Scout to your Laravel app for free, deploy the patch, and let the traces tell you the upgrade was boring, which is exactly what you want from a security release.