Laravel Patches a Critical TokenGuard Authentication Bypass

The framework’s maintainers published advisory GHSA-f9x3-7vq9-cph6 on October 19, describing a critical flaw (CVSS 9.2) in TokenGuard, Laravel’s built-in token-based authentication guard. On MySQL or MariaDB, an unauthenticated attacker could impersonate any existing user without knowing that user’s API token. The fix itself had shipped quietly two months earlier, in versions 12.68.0 and 13.29.0.

#A Fix Published Before Its Own Disclosure

Versions 12.68.0 and 13.29.0 shipped on August 25, 2026. At the time, the release notes gave no indication of the severity of what had just been patched. It wasn’t until October 19, nearly two months later, that advisory GHSA-f9x3-7vq9-cph6 laid out the real risk — a disclosure cadence that has become common among framework maintainers: patch quietly, give teams time to upgrade, then document the risk publicly. The framework’s latest major release, version 13.36, had already hardened queue worker reliability; 13.29, which fixes TokenGuard, sits a few releases earlier on the same branch.

#How the Flaw Works

TokenGuard is the simplest authentication guard Laravel ships for protecting an API: it compares the token sent by the client against the one stored for the user. Before the fix, the class only checked that the token wasn’t empty before handing it to the user provider. An attacker could submit a specially crafted, non-string credential value that the database lookup interpreted unexpectedly on MySQL and MariaDB, matching an unintended user record.

// config/auth.php — exposed configuration
'api' => [
    'driver'   => 'token',
    'provider' => 'users',
],

// Before the fix: only an emptiness check
if (empty($token)) {
    return null;
}
$user = $provider->retrieveByCredentials(['api_token' => $token]);

// Since 12.68.0 / 13.29.0: non-string values are rejected
if (empty($token) || ! is_string($token)) {
    return null;
}

#Who Is Exposed

Only applications that declare a guard using the token driver in config/auth.php are affected, and only on MySQL or MariaDB. Laravel Sanctum and Laravel Passport register their own guard drivers and are not covered by this advisory.

Two months separate the silent fix from its public disclosure — an unusual delay for a flaw that let an unauthenticated attacker impersonate any user.

#How to Respond

The fix is a version bump: run composer update laravel/framework to reach 12.68.0, 13.29.0 or later. Teams should then review config/auth.php for any guard configured with the token driver, prioritizing applications running on MySQL or MariaDB. A routine pass through composer audit, alongside the other command-line tools that make up a solid development workflow, would have surfaced the advisory as soon as it was published. More broadly, this flaw is a reminder that an API token is itself a form of application secret, deserving the same rigor as environment variables and credentials.

#What to Remember

• TokenGuard, Laravel’s token-based authentication guard, was vulnerable to account impersonation on MySQL and MariaDB before versions 12.68.0 and 13.29.0.
• The fix shipped on August 25, 2026, but the public advisory wasn’t published until October 19.
• Sanctum and Passport are not affected; only guards explicitly using the token driver are.
• A single update to laravel/framework also fixes the related JSON:API advisory.

#Go Further

Full security advisory: GHSA-f9x3-7vq9-cph6 on GitHub.