Faille Laravel token guard : votre application est-elle concernée ?

Une faille critique touche le guard "token" de Laravel, mais seulement les applications qui l'ont activé et qui stockent leurs utilisateurs dans MySQL ou MariaDB. Dans ce cas, la mise à jour vers Laravel 12.68.0 ou 13.29.0 (ou plus récent) s'impose.

Ce que dit l'avis de sécurité

Laravel est un framework PHP, la base sur laquelle sont construites de nombreuses applications métier. Son avis, référencé GHSA-f9x3-7vq9-cph6, décrit un contournement d'authentification noté 9,2 sur 10 en gravité (échelle CVSS v4.0). Un visiteur non identifié peut se connecter comme un utilisateur existant, sans connaître son jeton.

Un jeton (token) est une longue chaîne de caractères qui sert de mot de passe à une API, la porte d'entrée par laquelle des logiciels échangent des données.

Selon l'analyse publiée sur dev.to, le correctif date d'août 2026. L'avis, lui, n'est devenu public que le 19 octobre 2026. Pendant près de deux mois, une application non mise à jour n'avait donc aucune alerte publique à suivre.

Comment un simple tableau ouvre une session

Le guard devait vérifier que le jeton reçu était une chaîne de texte. Il vérifiait seulement qu'il n'était pas vide. Un tableau de valeurs, envoyé à la place du jeton, passait le contrôle et arrivait jusqu'à la recherche en base de données.

C'est là que MySQL et MariaDB interviennent. Quand on compare une colonne de texte à un nombre, ces bases convertissent le texte en nombre, et un texte qui ne commence pas par un chiffre devient 0. L'auteur de dev.to l'a testé sur MariaDB avec deux utilisateurs dont le jeton commence par des lettres : la comparaison avec le nombre 0 renvoie les deux lignes, la comparaison avec le texte "0" n'en renvoie aucune. Il n'a pas testé d'autres bases.

L'attaquant ne choisit pas fiablement le compte obtenu, qui dépend des données en base. Si l'un de ces comptes est celui d'un administrateur, la nuance console peu.

Êtes-vous concerné ?

Le guard doit avoir été activé dans config/auth.php, avec la mention 'driver' => 'token'. Sanctum et Passport, deux outils d'authentification d'API, ne sont pas listés comme affectés. Le guard de session, celui des connexions classiques par formulaire, non plus.

Les applications récentes sont donc rarement exposées. Les squelettes Laravel anciens, jusqu'à la version 7 environ, incluaient un guard api basé sur ce driver : les applications historiques sont les premières à vérifier. Regardez aussi les routes protégées par auth:api ou équivalent, pour être sûr que le guard utilisé n'est pas celui-là.

Une recherche de 'driver' => 'token' dans le fichier, puis composer show laravel/framework pour la version, donnent la réponse en quelques minutes. composer audit peut confirmer, mais les sources divergent sur sa fiabilité : un dépôt de reproduction indique que les scanners ne signalent pas la faille sur d'anciennes versions. Ne vous y fiez pas seul.

Corriger : version, déploiement, logs

Selon Laravel News, les versions corrigées sont la 12.68.0 et la 13.29.0, publiées le 25 août 2026. Le contrôle de type apparaît dans le code dès la 13.27.0, mais 13.29.0 est la version annoncée : visez celle-ci ou plus récent.

Pour les branches 11 et 10, les sources divergent. Le code de la 11.56.1 contient le contrôle, celui de la 10.49.0 non. Consultez l'avis pour votre branche, ou passez à une version maintenue.

Après la mise à jour, déployez et redémarrez les processus PHP qui tournent en arrière-plan. Il n'existe aucun contournement officiel. Si le guard ne sert à rien, le retirer de la configuration empêche toute route de l'utiliser. Quand les jetons sont stockés hachés (hash à true), une requête piégée provoque une erreur au lieu d'une connexion, mais l'avis n'exempte pas ces configurations.

Reste la relecture des logs d'accès depuis août : connexions inhabituelles sur les routes à jeton, comptes qui n'auraient pas dû être atteints. Ces comptes sont à considérer comme suspects.

Sur l'exploitation réelle, les sources se contredisent. Un dépôt public de reproduction existe, mais aucune attaque en production n'était observée au dernier rapport consulté.

Ce qu'une PME peut en retenir

Un second avis, de gravité moyenne (GHSA-5wcm-3v2w-8362), concerne les ressources JSON:API de Laravel 12.45 et suivants : une simple lecture pouvait déclencher une suppression sur une table liée. Il est corrigé dans les mêmes versions, ce qui rend la mise à jour utile même sans token guard.

Pour un dirigeant, la question à poser à son prestataire tient en une ligne : quelle version de Laravel tourne chez nous, et le guard "token" est-il actif ? Une application qui n'a pas été touchée depuis des années est le premier cas à regarder.

Ce suivi relève de l'hébergement et de la maintenance, et une application ancienne peut justifier une reprise avant tout autre chantier. Nous avions détaillé la même logique pour une autre faille côté PHP. Making Digital accompagne des entreprises du secteur, à Aix-en-Provence et en Provence, sur ces vérifications.

Questions fréquentes