Laravel corrige une faille critique d’authentification dans TokenGuard

Le mainteneur du framework a publié le 19 octobre l’avis GHSA-f9x3-7vq9-cph6, qui décrit une faille critique (CVSS 9.2) dans TokenGuard, le garde d’authentification par jeton intégré à Laravel. Sur une base MySQL ou MariaDB, un attaquant non authentifié pouvait usurper l’identité de n’importe quel utilisateur existant sans connaître son jeton API. Le correctif, lui, avait été livré deux mois plus tôt, discrètement, dans les versions 12.68.0 et 13.29.0.

#Un correctif publié avant sa propre divulgation

Les versions 12.68.0 et 13.29.0 sont sorties le 25 août 2026. À l’époque, les notes de version ne mentionnaient rien qui laissait deviner la gravité du problème corrigé. Ce n’est que le 19 octobre, près de deux mois plus tard, que l’avis de sécurité GHSA-f9x3-7vq9-cph6 a détaillé la faille, selon un calendrier de divulgation désormais habituel chez les mainteneurs de frameworks : corriger silencieusement, laisser le temps aux équipes de monter de version, puis documenter publiquement le risque réel. La dernière publication majeure du framework, en version 13.36, avait déjà musclé la fiabilité des files d’attente ; la 13.29 qui corrige TokenGuard se situe quelques versions plus tôt dans la même branche.

#Le mécanisme de la faille

TokenGuard est le garde d’authentification le plus simple proposé par Laravel pour protéger une API : il compare le jeton transmis par le client à celui stocké pour l’utilisateur. Avant le correctif, la classe se contentait de vérifier que le jeton n’était pas vide avant de le transmettre au fournisseur d’utilisateurs. Un attaquant pouvait alors soumettre une valeur d’identifiant non textuelle, spécialement construite, que la recherche en base interprétait de façon imprévue sur MySQL et MariaDB, au point de faire correspondre un enregistrement utilisateur non visé.

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

// Avant le correctif : seule une vérification de non-vacuité
if (empty($token)) {
    return null;
}
$user = $provider->retrieveByCredentials(['api_token' => $token]);

// Depuis 12.68.0 / 13.29.0 : rejet explicite des valeurs non textuelles
if (empty($token) || ! is_string($token)) {
    return null;
}

#Qui est exposé

Seules les applications qui déclarent un garde utilisant le pilote token dans config/auth.php sont concernées, et uniquement sur MySQL ou MariaDB. Laravel Sanctum et Laravel Passport enregistrent leurs propres pilotes de garde et ne sont pas visés par cet avis.

Deux mois séparent le correctif silencieux de sa divulgation publique, un délai inhabituel pour une faille permettant à un attaquant non authentifié de se faire passer pour n’importe quel utilisateur.

#Comment réagir

La correction consiste à monter de version : composer update laravel/framework vers 12.68.0, 13.29.0 ou une version ultérieure. Les équipes peuvent ensuite passer en revue config/auth.php pour repérer tout garde configuré avec le pilote token, en priorisant les applications hébergées sur MySQL ou MariaDB. Un passage régulier par composer audit, au même titre que les autres outils en ligne de commande qui jalonnent une routine de développement, aurait permis de repérer l’avis dès sa publication. Plus largement, cette faille rappelle qu’un jeton d’API reste une forme de secret applicatif, à traiter avec la même rigueur que les identifiants et variables d’environnement d’un projet.

#Ce qu’il faut retenir

• TokenGuard, le garde d’authentification par jeton de Laravel, était vulnérable à une usurpation de compte sur MySQL et MariaDB avant les versions 12.68.0 et 13.29.0.
• Le correctif est sorti le 25 août 2026, mais l’avis public n’a été publié que le 19 octobre.
• Sanctum et Passport ne sont pas concernés ; seuls les gardes utilisant explicitement le pilote token le sont.
• Une mise à jour de laravel/framework suffit à corriger également le second avis touchant JSON:API.

#Pour aller plus loin

Avis de sécurité complet : GHSA-f9x3-7vq9-cph6 sur GitHub.