Tutor LMS : une faille permet à un simple compte étudiant d'exécuter du code sur 100 000 sites WordPress (CVE-2026-78175)

Tutor LMS : une faille critique pour les plateformes de cours en ligne

Le 17 septembre 2026, Wordfence a publié l'analyse d'une vulnérabilité découverte le 23 août par Argus, son agent de recherche automatisé, dans Tutor LMS, l'extension de Themeum qui équipe plus de 100 000 sites de formation. La faille, référencée CVE-2026-78175 et notée 8.8 sur 10, permet à tout utilisateur connecté avec le rôle d'abonné d'exécuter du code arbitraire sur le serveur. Themeum a reconnu le problème le 24 août et publié la version corrigée 4.0.8 le 10 septembre.

La note « élevée » plutôt que « critique » vient de la condition d'authentification. Mais, comme le souligne Wordfence, Tutor LMS est construit autour de l'inscription des étudiants et la plupart des installations laissent l'inscription ouverte par défaut : un visiteur anonyme peut se créer un compte via l'action tutor_register_student et obtenir en quelques secondes tout ce qu'il faut pour atteindre le code vulnérable. La barrière est donc, en pratique, très basse. Il faut en plus que la fonction de monétisation de l'extension soit activée, ce qui est le cas dès que le site vend des cours.

Élément	Détail
Extension	Tutor LMS – eLearning and online course solution (Themeum), plus de 100 000 installations actives
Référence	CVE-2026-78175, CVSS 8.8 (élevée)
Versions vulnérables	4.0.7 et antérieures
Version corrigée	4.0.8, publiée le 10 septembre 2026
Accès requis	Compte abonné (étudiant) ; inscription ouverte sur la plupart des sites, fonction de monétisation activée
Découverte	Wordfence Argus et Chloe Chamberland, 23 août 2026
Règle de pare-feu Wordfence	25 août pour Premium, Care et Response ; 24 septembre pour la version gratuite

Comment un compte étudiant devient une exécution de code

La chaîne décrite par Wordfence est instructive, parce qu'elle ne repose sur aucun bug spectaculaire : chaque maillon, pris isolément, ressemble à une simple négligence.

Un point d'entrée sans contrôle de rôle

Le gestionnaire AJAX tutor_save_withdraw_account, qui enregistre les coordonnées de paiement d'un formateur pour ses retraits, est enregistré sur le seul hook wp_ajax_, réservé aux utilisateurs connectés, sans aucune vérification de capacité. Sa seule protection est un nonce, et ce nonce est émis sur chaque page publique du site par wp_localize_script : n'importe quel abonné l'obtient en chargeant la page d'accueil. Le gestionnaire voisin, tutor_make_an_withdraw, vérifie bien que l'utilisateur est formateur ; celui-ci ne le fait pas.

Un mauvais usage d'esc_sql() qui corrompt les données sérialisées

Les valeurs envoyées passent par esc_sql() avant d'être stockées avec update_user_meta(). Or esc_sql() est prévu pour une requête SQL brute, pas pour une donnée qui sera sérialisée. Cette fonction remplace chaque caractère % par un jeton de substitution de 66 octets, que WordPress retire juste avant d'exécuter la requête. Résultat : la chaîne est sérialisée avec sa longueur gonflée (par exemple s:71:), puis le jeton est retiré au moment de l'écriture en base. La base contient donc une chaîne qui annonce 71 octets et n'en contient que 6.

À la lecture suivante, unserialize() lit 71 octets et déborde de 65 octets sur l'élément suivant du tableau. Comme les clés de ce tableau proviennent directement des noms de champs POST, sans aucun filtrage, l'attaquant y place un flux d'objets sérialisés de son choix. Il suffit d'envoyer la même requête une seconde fois : WordPress relit l'ancienne valeur pour la comparer à la nouvelle, la désérialise, et les objets injectés prennent vie. Afficher la page de retrait dans le tableau de bord déclenche aussi la charge.

Une chaîne de gadgets fournie par l'extension elle-même

Le premier objet injecté porte un nom de classe inexistant, construit pour que le chargeur automatique de l'extension le traduise en chemin de fichier et inclue, via require_once, l'autoloader Composer de la bibliothèque PayPal embarquée. Cet autoloader rend disponible la hiérarchie de classes GuzzleHttp, et le second objet, un GuzzleHttp\Cookie\FileCookieJar authentique, peut alors être instancié. Quand PHP détruit cet objet, son destructeur écrit le contenu des cookies dans le fichier indiqué par sa propriété filename. L'attaquant contrôle les deux : le nom du fichier, un .php dans wp-content/uploads, et le nom d'un cookie, qui contient <?php echo shell_exec(...); ?>. Une porte dérobée est écrite sur le disque ; une simple requête HTTP vers ce fichier exécute des commandes système avec les droits du serveur web.

Le correctif de la version 4.0.8

Themeum a corrigé la faille en plusieurs points, et Wordfence salue une remédiation en profondeur : ajout d'un contrôle de capacité sur le gestionnaire, abandon d'esc_sql() au profit de sanitize_text_field() et sanitize_email() selon le type de champ, rejet des valeurs de type tableau, et surtout construction du tableau enregistré à partir de la liste des champs définis par la méthode de paiement, et non plus à partir des noms de champs envoyés par le client. Chacune des trois premières mesures aurait suffi à bloquer l'exploitation ; les avoir toutes appliquées ferme aussi les variantes que personne n'a encore trouvées.

Ce n'est pas la première alerte de l'été pour cette extension : le rapport hebdomadaire de Wordfence du 24 au 30 août recensait déjà une faille critique dans Tutor LMS 4.0.5 et antérieures, CVE-2026-19092, une invocation de fonction sans authentification signalée par Jakub Herman et corrigée depuis. Un site qui a sauté ces mises à jour cumule donc deux failles graves.

Que faire si votre site utilise Tutor LMS

Mettre à jour vers la 4.0.8 ou plus

C'est la seule mesure qui ferme la faille. Vérifiez la version installée dans « Extensions » ou en ligne de commande :

wp plugin get tutor --field=version
wp plugin update tutor

Si vous utilisez Tutor LMS Pro, mettez aussi à jour l'extension premium via votre compte Themeum. Un site avec des étudiants inscrits et des ventes de cours est exactement le profil visé : ne repoussez pas la mise à jour pour attendre un créneau calme.

Chercher les traces d'une exploitation

La faille est publique depuis le 17 septembre avec une analyse technique complète, et les sites sans pare-feu ou avec la version gratuite de Wordfence ne recevront la règle que le 24 septembre. Entre les deux, et pour toute la période depuis le 23 août, vérifiez :

1. Les comptes créés récemment. Un attaquant s'inscrit comme étudiant avant d'attaquer. Listez les abonnés inscrits depuis fin août, puis vérifiez qu'aucun n'a changé de rôle ; notre article sur l'administrateur inconnu dans WordPress donne les requêtes.
2. Les métadonnées de retrait. La charge s'enregistre dans la clé _tutor_withdraw_method_data de la table des métadonnées utilisateur. Une valeur anormalement longue, ou contenant O: suivi d'un nom de classe, est un indicateur direct.
3. Les fichiers PHP dans uploads. Le destructeur écrit la porte dérobée là où l'attaquant l'a décidé, le plus souvent sous wp-content/uploads.
4. Les journaux d'accès. Des requêtes POST vers admin-ajax.php avec action=tutor_save_withdraw_account venant d'un compte fraîchement créé, en particulier deux requêtes rapprochées depuis la même adresse.

wp user list --role=subscriber --field=user_registered --format=csv | sort | tail -20
wp db query "SELECT user_id, LENGTH(meta_value) AS taille FROM wp_usermeta WHERE meta_key='_tutor_withdraw_method_data' ORDER BY taille DESC LIMIT 20"
wp db query "SELECT user_id FROM wp_usermeta WHERE meta_key='_tutor_withdraw_method_data' AND meta_value LIKE '%O:%'"
find wp-content/uploads -name "*.php" -newermt "2026-08-23"
grep "tutor_save_withdraw_account" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head

Si l'un de ces contrôles est positif, considérez le site comme compromis : le fichier écrit par la faille est une porte dérobée, et l'attaquant a pu en poser d'autres. Suivez notre guide de nettoyage d'un site WordPress piraté ou confiez-nous le nettoyage.

Réduire l'impact de la prochaine faille du même type

• Bloquer l'exécution de PHP dans uploads. La chaîne se termine par l'écriture d'un fichier PHP dans wp-content/uploads. Une règle serveur qui refuse d'exécuter du PHP dans ce dossier ne corrige pas la faille, mais elle transforme une exécution de code en simple fichier inerte. Voir notre tutoriel pour bloquer l'exécution PHP dans uploads.
• Surveiller les fichiers. Un nouveau .php dans uploads doit déclencher une alerte le jour même : c'est le rôle d'une surveillance d'intégrité des fichiers.
• Limiter ce qu'un abonné peut faire. Passez en revue les rôles et permissions : un compte étudiant ne devrait accéder à aucun tableau de bord WordPress, et les gestionnaires AJAX exposés aux abonnés sont une cible de choix.
• Pare-feu applicatif. Les utilisateurs de Wordfence Premium étaient protégés dès le 25 août, seize jours avant le correctif. Ce délai entre découverte et correctif est précisément ce qu'un pare-feu à règles couvre.

Cette faille s'ajoute aux deux chaînes critiques trouvées par le même agent dans The Events Calendar et aux onze correctifs de WordPress 7.1.1 la même semaine : septembre 2026 est un mois où les mises à jour ne peuvent pas attendre.

Sources

• Wordfence, Chloe Chamberland, « 100,000 WordPress Sites Exposed to Remote Code Execution via PHP Object Injection Vulnerability Found by Wordfence Argus in Tutor LMS », 17 septembre 2026, wordfence.com
• Wordfence Intelligence, « Wordfence Intelligence Weekly WordPress Vulnerability Report (August 24, 2026 to August 30, 2026) », 3 septembre 2026, wordfence.com
• WordPress.org, fiche de l'extension « Tutor LMS – eLearning and online course solution », wordpress.org