devto 2026-10-25 원문 보기 ↗
Act today if this applies to you
CVE-2026-114509 is a critical (CVSS 9.2) flaw in Laravel’s built-in token API guard. If your app authenticates API requests with the "token" driver and stores users in MySQL or MariaDB, an attacker with no account can sign in as an existing user, without that user’s token. Update laravel/framework to 12.68.0 or 13.29.0 or later. Apps that use only Sanctum, Passport or session logins are not affected by this flaw.
Laravel published the advisory on 19 October 2026. It affects a feature many teams forget they still have: the simple token guard that older Laravel apps used for their API before Sanctum existed. If your site or product was started a few years ago and has a mobile app, an integration or a partner API, it is worth five minutes to check. This guide explains, for site owners, whether you are exposed and what to ask your developer to do.
Laravel’s TokenGuard checks an API token by looking up the user whose stored token matches the one sent with the request. Before the fix, it only checked that the value was not empty. It did not check that it was text.
An attacker can send a specially crafted value that is not text in a JSON request. On MySQL and MariaDB, the database then compares the stored tokens in a way that can match an existing user, so the request is treated as that user. The attacker does not need an account, a password or a real token, and no one has to click anything.
The result is account takeover on every route protected by that guard: reading the user’s data, changing it, or acting as them through your API. If the matched user is an administrator, the impact is the whole application.
You are exposed only if all four answers are yes:
QuestionHow to checkIf the answer is noIs laravel/framework older than 12.68.0 (or 13.x older than 13.29.0)?composer show --locked laravel/framework, or php artisan --versionYou already have the fixDoes config/auth.php define a guard with 'driver' => 'token'?Search config/auth.php for 'token'This flaw does not apply (Sanctum and Passport use their own guards)Do any routes use that guard?Look for auth:api or auth: in routes/, or run php artisan route:listThe guard is unused; still update and remove itAre users stored in MySQL or MariaDB?DB_CONNECTION in .envThe advisory names only MySQL and MariaDB; update anyway
Your developer can run these checks in a couple of minutes:
# 1. Which Laravel version is installed?
composer show --locked laravel/framework | grep versions
# 2. Is the built-in token guard configured?
grep -n "'driver' *=> *'token'" config/auth.php
# 3. Which routes use it? (usually the "api" guard)
grep -rn "auth:api" routes/ app/
php artisan route:list --middleware=auth:api
# 4. Which database holds your users?
grep -n "^DB_CONNECTION" .env
Common in older apps
Laravel 7 and earlier shipped an "api" guard with the token driver in config/auth.php by default. Many apps upgraded since then kept that guard even after moving to Sanctum, sometimes on a forgotten mobile or partner endpoint. Check it rather than assume.
Laravel versionStatusWhat to do13.xFixed in 13.29.0Update to 13.29.0 or later12.xFixed in 12.68.0Update to 12.68.0 or later11.xNo fixed release named in the advisoryPlan the move to 12 or 13; apply the stopgap below meanwhile10.x and olderNo fix; out of security supportUpgrade; apply the stopgap below meanwhile
Some write-ups say Laravel 11.56.1 contains the same type check, citing the proof-of-concept authors. The official advisory does not list an 11.x fix, so do not rely on it: treat 11.x as unpatched until Laravel says otherwise, and check Laravel’s support policy for which versions still receive security fixes.
composer update laravel/framework --with-all-dependencies
composer show --locked laravel/framework | grep versions # expect 12.68.0+ or 13.29.0+
php artisan optimize:clear
# Restart PHP-FPM, queue workers and Octane (commands depend on your server)
The fix itself is small: TokenGuard now rejects any token that is not a non-empty string (see the current source). Until you can update, a middleware that does the same check before the guard runs closes the hole. Add it in front of your token-guarded routes and remove it after updating.
<?php
// app/Http/Middleware/RejectNonStringApiToken.php
// Temporary: blocks CVE-2026-114509 until laravel/framework is updated.
namespace App\Http\Middleware;
use Closure;
use Illuminate\Http\Request;
class RejectNonStringApiToken
{
public function handle(Request $request, Closure $next)
{
// Use your guard's input_key if you changed it from the default.
$token = $request->input('api_token');
if ($token !== null && ! is_string($token)) {
abort(401);
}
return $next($request);
}
}
Register it so it runs before auth:api on the affected routes. It is a stopgap only: the framework update is the real fix, and Laravel 10 and 11 apps still need an upgrade plan.
As of 24 October 2026 there are no confirmed reports of attacks, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog. Security Online reports that a proof of concept has been published on GitHub, although the advisory itself links none. With a working example circulating, assume automated scanning will follow and patch exposed APIs first.
If you also run PHP 8.2 to 8.5, check that the server has this month’s PHP security release as well: our PHP2Shell guide covers the separate runtime fixes released on 21 October.
Laravel security
We can audit every Laravel app you run for this flaw, apply the update or the stopgap without downtime, and plan the upgrade off unsupported versions.
Originally published at phpscientist.com.