Faille critique du TokenGuard de Laravel : passer en 12.68 ou 13.29

Une API protégée par le guard token de Laravel, sur une base MySQL ou MariaDB, peut laisser quelqu'un se connecter à la place de n'importe quel utilisateur existant, sans connaître son jeton. La note de gravité est de 9,8 sur 10 en CVSS 3.1 (9,2 en CVSS v4). Le correctif est livré dans Laravel 12.68.0 et 13.29.0 : avant de lancer la mise à jour, il faut juste savoir si vous êtes concerné.

Quelle est cette faille, et quelles versions touche-t-elle ?

Elle porte la référence CVE-2026-114509 (avis GHSA-f9x3-7vq9-cph6). Le guard token lit un jeton dans la requête, puis cherche l'utilisateur correspondant dans la base. Quand la valeur reçue n'est pas une simple chaîne de caractères, la requête SQL peut désigner un autre utilisateur que celui visé : l'attaquant est alors authentifié comme lui, sans compte ni jeton valide.

L'avis précise deux conditions : le guard token standard doit protéger des routes, et la base doit être MySQL ou MariaDB. Il ne liste aucun contournement. Sanctum et Passport ont leurs propres guards et ne sont pas cités par l'avis. Une preuve de concept publique a été signalée peu après la publication : mieux vaut ne pas attendre.

Comment savoir si votre application utilise ce guard ?

Cherchez le pilote token dans la configuration des guards :

// config/auth.php
'guards' => [
    'api' => [
        'driver' => 'token',
        'provider' => 'users',
        'hash' => false,
    ],
],

Si vous n'y trouvez aucun 'driver' => 'token', ou si vos routes d'API passent par Sanctum ou Passport, vous n'êtes pas dans le cas décrit. Vérifiez aussi quelle version tourne réellement :

grep -n "'driver' => 'token'" config/auth.php
grep -rn "auth:api" routes/
composer show laravel/framework | grep versions

Comment corriger ?

Mettez à jour le framework, vérifiez la version, lancez les tests puis déployez :

composer update laravel/framework
composer show laravel/framework | grep versions
php artisan test

Si votre contrainte est ^12.0 ou ^13.0, composer update suffit. Les sources que nous avons consultées divergent sur un correctif pour Laravel 11 et les versions plus anciennes : consultez l'avis officiel du dépôt laravel/framework. Si vous êtes sur une branche non corrigée, la vraie solution est de migrer vers Sanctum (jetons hachés, révocables) ou de monter de version, pas de patcher à la main. Sur un serveur, pensez à redémarrer les workers de file d'attente après le déploiement avec php artisan queue:restart.

Peut-on savoir si quelqu'un a déjà essayé ?

Pas de façon certaine. Une première piste : chercher dans les journaux du serveur web des requêtes où le paramètre api_token est envoyé sous forme de tableau :

zgrep -E 'api_token(\[|%5B)' /var/log/nginx/access.log*

Cette recherche ne voit que l'adresse des requêtes : un jeton envoyé dans le corps JSON n'apparaît pas dans ces journaux. Regardez aussi les connexions et actions inhabituelles des comptes sensibles (administrateurs, comptes avec droits de facturation), et, si le doute persiste, régénérez leurs jetons.

Le suivi de ce type d'alerte fait partie de notre offre d'hébergement et de maintenance. Si vous voulez qu'on regarde une application avec vous, écrivez-nous.

Sources : avis CVE-2026-114509 sur GitLab Advisory Database et avis GHSA-f9x3-7vq9-cph6.

Questions fréquentes