Laravel : contournement d'authentification critique (CVSS 9.2)

Le framework PHP Laravel corrige deux vulnérabilités, dont un contournement du guard d'authentification par token noté 9.2 (critique). Le CERT-FR a publié l'alerte CERTFR-2026-AVI-1343 le 20 octobre ; les avis éditeur sont datés du 19 octobre. Si vous opérez une application Laravel exposant une API protégée par token, montez en 12.68.0 (branche 12.x) ou 13.29.0 (branche 13.x).

Aucun identifiant CVE n'a été attribué à ce stade : les deux failles sont référencées uniquement par leurs avis GitHub, GHSA-f9x3-7vq9-cph6 et GHSA-5wcm-3v2w-8362, qui sont la source primaire.

Les deux failles

Contournement d'authentification (GHSA-f9x3-7vq9-cph6) — critique, CVSS v4 9.2. Le guard de token intégré peut être contourné quand une application utilise un guard d'API standard basé sur token. Sur MySQL ou MariaDB, un attaquant peut envoyer une valeur d'identifiant non-chaîne spécialement forgée que la requête d'authentification interprète mal, de sorte qu'elle correspond à un utilisateur non prévu. Aucun token valide n'est nécessaire, et la faille peut mener à une prise de contrôle de compte sur les routes protégées par le guard.

• Versions concernées : < 12.68.0 (branche 12.x) et < 13.29.0 (branche 13.x).
• Correctifs : 12.68.0 et 13.29.0.

Destruction de données non autorisée (GHSA-5wcm-3v2w-8362) — modéré, CVSS v3.1 6.5. Le traitement de l'inclusion de relations sur certains endpoints en lecture est en cause. Dans des conditions spécifiques, une requête forgée vers un endpoint en lecture seule peut déclencher une opération destructrice sur une table liée au lieu de se contenter de lire. Conséquence : « A user with only read access could cause irreversible data loss » — un utilisateur disposant d'un accès en lecture seule peut provoquer une perte de données irréversible.

• Versions concernées : >= 12.45.0 et < 13.27.0.
• Correctifs : 12.68.0 et 13.27.0.

Le correctif de la destruction de données est arrivé en 13.27.0, mais celui du contournement d'authentification exige 13.29.0 — c'est donc 13.29.0 qui couvre les deux sur la branche 13.x.

Statut d'exploitation

Aucun code d'exploitation public ni exploitation observée n'est signalé par les avis à l'heure de la publication. Le contournement d'authentification ne vise que les déploiements MySQL/MariaDB utilisant le guard de token — un périmètre large, mais pas universel.

Que faire

1. Identifiez vos applications Laravel en 12.x (>= 12.45.0) et 13.x, et leur SGBD.
2. Montez en 12.68.0 ou 13.29.0 (13.29.0, pas 13.27.0, si vous êtes sur la branche 13.x).
3. Si vous utilisez un guard d'API par token sur MySQL/MariaDB, traitez-le en priorité : la faille 9.2 est pré-authentifiée et mène à la prise de contrôle de compte.
4. En attendant le déploiement, auditez les journaux d'authentification pour des accès API réussis sans token valide, et les endpoints en lecture pour des suppressions anormales.

Contexte

Le contournement repose sur un classique : un identifiant non-chaîne mal typé qu'une requête SQL interprète trop largement — la même famille de bugs que les contournements d'authentification vus ailleurs quand le typage côté application fait confiance au SGBD. Laravel motorise une part majeure de l'écosystème PHP ; un contournement d'auth noté 9.2 sur un guard d'API par défaut mérite un déploiement rapide, pas une fenêtre de maintenance au mois prochain.