Laravel Fixes a Critical TokenGuard Authentication Vulnerability (GHSA-f9x3-7vq9-cph6)

On October 19, 2026, the Laravel team published security advisory GHSA-f9x3-7vq9-cph6, a critical vulnerability in the token-based authentication guard known as TokenGuard.

According to the advisory, an unauthenticated attacker can send a specially crafted value that is not a string. The application mishandles it during the authentication lookup and may end up matching a different user. As a result, the attacker acts as that user without knowing their token.

The flaw has already been fixed. The solution is to update laravel/framework to a version that includes the patch.

Quick summary

• Advisory: GHSA-f9x3-7vq9-cph6, published on October 19, 2026.
• Severity: critical, with a CVSS v4 score of 9.2.
• At the time of writing, the advisory has no CVE assigned.
• Affected component: Laravel's built-in TokenGuard.
• Affects applications using MySQL or MariaDB, under certain database configurations.
• The attacker does not need to be authenticated and no user interaction is required.
• Fixed versions: 12.68.0 and 13.29.0.
• The advisory offers no temporary workaround: the only fix it lists is to update.

What is TokenGuard?

In Laravel, a guard defines how the person making a request is identified. TokenGuard is the built-in guard that identifies a user from a token sent with the request.

It should not be confused with other authentication packages that have their own mechanism. The advisory refers to the framework's standard TokenGuard and does not mention Sanctum or Passport. That is why the right approach is to check which guards your application uses instead of assuming anything.

What impact can it have?

Any route protected by the affected guard could be exposed. If an attacker manages to act as another user, they can access that account's data and perform the actions that account is allowed to perform.

It is important to understand the scope: this is a flaw inside the application. It does not imply access to the server or operating system administrator privileges.

Affected and fixed versions

The advisory only lists these two branches. If your project uses an older version, check the official advisory before considering the matter closed.

How do I know if I need to act?

1. Check the installed version

bash
composer show laravel/framework
php artisan --version

Compare the result with the table above.

2. Check the configured guards

Open config/auth.php and look for guards with the token driver:

php
'guards' => [
    'api' => [
        'driver' => 'token',
        'provider' => 'users',
    ],
],

3. Check the protected routes

Look for routes that use that guard, for example with auth:api.

4. Check the database

The advisory states that the problem affects applications using MySQL or MariaDB.

How to read the result

text
Affected version + token guard + MySQL/MariaDB
        ↓
High priority: update immediately

Affected version, no token guard
        ↓
Still update in the next deployment window

Even if you do not use the affected guard, it is worth updating: the fixed versions also include other security and maintenance fixes.

How to mitigate it

The only mitigation listed by the advisory is to update the framework.

1. Update Laravel

bash
composer update laravel/framework --with-dependencies

Then confirm the installed version:

bash
php artisan --version

2. Test before deploying

Run your test suite and pay special attention to login and protected routes.

3. Deploy with pinned versions

Commit the updated composer.lock and install exactly those versions on the server:

bash
composer install --no-dev --optimize-autoloader

Do not run composer update directly in production.

4. Clear and rebuild caches

bash
php artisan config:clear && php artisan config:cache
php artisan route:clear && php artisan route:cache
php artisan view:clear && php artisan view:cache
php artisan queue:restart

The queue:restart command matters: queue workers that are already running keep using the old code until they are restarted. If your server uses OPcache with revalidation disabled, restart PHP-FPM as well.

Suggested acceptance tests

After updating, verify in a test environment that:

• A request without a token to a protected route returns 401.
• A valid token keeps working normally.
• An invalid token returns 401.
• Sending the token as an array or object instead of a string does not authenticate any user.

If you suspect it was already exploited

• Review access logs for unusual requests to protected routes.
• Review recent activity on the most privileged accounts.
• Rotate access tokens for sensitive accounts.
• As far as we know, the advisory does not include indicators of compromise, so the review has to be general.

Does it affect my VPS or server?

The vulnerability lives in the Laravel code running inside your application. It is not an operating system flaw, so updating the server's packages does not fix it. You need to update the application's dependencies.

Conclusion

GHSA-f9x3-7vq9-cph6 is a critical vulnerability that allows impersonating another user in applications that use Laravel's built-in TokenGuard with MySQL or MariaDB. It is fixed in 12.68.0 and 13.29.0.

The steps are simple: check your version, find out whether you use a token guard, update, test, and deploy while clearing caches and restarting queues.

Since the advisory offers no temporary workaround, waiting only prolongs the exposure.

Note: This article is based on the official advisory GHSA-f9x3-7vq9-cph6, published by the Laravel team on October 19, 2026 and reported by KIKOmanasijev. Details may be updated over time. Before acting, consult the original advisory: https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6