LMS : l'outil que toute l'entreprise utilise et que personne ne met à jour

Le monde de l'entreprise tourne sur des technologies qui vieillissent plus vite qu'on ne les remplace. Des plateformes de formation installées il y a dix ans, du PHP partout, des modules e-learning livrés aux clients sous forme de zip SCORM qu'on dépose sans trop regarder ce qu'il y a dedans. Rien de tout ça n'est honteux. Mais c'est là que les ennuis s'accumulent, en silence.

La faille PHP de cette semaine l'a rappelé. Dans son principe, une exécution de code à distance dans un moteur web n'a rien de nouveau. Elle a frappé fort parce qu'elle touchait énormément de monde d'un coup. Le LMS, le Learning Management System, est exactement dans cette situation : un logiciel que toute l'entreprise utilise, souvent écrit en PHP, rarement en haut de la liste des priorités de la DSI.

Je passe des audits de sécurité sur ces plateformes en continu, Moodle, Drupal et les SaaS du marché. Le LMS est souvent une faille. Pas parce que les éditeurs travaillent mal, mais à cause de la façon dont on le déploie.

Pourquoi le LMS est une cible sous-estimée

Le LMS cumule trois caractéristiques qu.on retrouve rarement ensemble.

• Tout le monde y a un compte. Salariés, intérimaires, parfois clients, partenaires ou apprenants externes. Quand il est branché au SSO de l'entreprise, chaque compte LMS est une identité d'entreprise.
• Il accepte du contenu actif. Un paquet SCORM ou xAPI est un site web en HTML et JavaScript, souvent produit par un prestataire, qu'on téléverse et qu'on exécute dans le navigateur des apprenants.
• Il est rarement mis à jour. On l'installe pour un projet, un prestataire le maintient tant que le contrat court, puis il vit sa vie.

Ajoutez à ça des données personnelles (identité, parcours, résultats d'évaluation, présence, parfois éléments de financement de la formation) et vous avez une cible qui vaut le détour, avec une surface d'attaque large.

Les trois zones que j'audite en priorité sur un LMS, plus les intégrations qu'on oublie.

Premier angle mort : le LMS embarqué en iframe

Dans beaucoup d'entreprises, le LMS n'est pas consulté directement. Il est affiché dans une iframe, au milieu de l'intranet, du portail RH ou du SIRH. C'est pratique pour l'utilisateur. C'est aussi une série de compromis de sécurité, souvent faits sans s'en rendre compte pour « que ça marche ».

• Clickjacking. Pour pouvoir être embarqué, le LMS doit autoriser l'affichage en iframe. Si on lève la protection au lieu de la restreindre, n'importe quel site peut l'afficher sous un calque trompeur. La bonne pratique : une directive CSP frame-ancestors qui liste explicitement les portails autorisés, et rien d'autre.
• Cookies tiers. Pour que la session tienne dans une iframe d'un autre domaine, les cookies passent souvent en SameSite=None. On retire alors une protection utile contre les requêtes forgées.
• `postMessage`. Le portail et le LMS dialoguent souvent par messages entre fenêtres. Si l'origine n'est pas vérifiée, n'importe quelle page peut parler au LMS. La bibliothèque SCORM open source scorm-again le dit dans sa documentation : son origine par défaut est *, et il faut la restreindre en production.
• Paquets SCORM servis sur la même origine. C'est le point le plus sérieux. Un paquet SCORM exécute son JavaScript ; s'il est servi depuis le même domaine que le LMS, il hérite de la session de l'utilisateur. Rustici, l'éditeur de référence du SCORM, l'a documenté pour sa propre faille CVE-2022-2035 (corrigée en 2022) : quand le lecteur était hébergé sur le même domaine que l'application, un script malveillant pouvait envoyer des requêtes au nom de l'utilisateur connecté, et un jeton CSRF ne protégeait pas. Leur recommandation de mitigation : héberger le lecteur sur un domaine distinct, sans cookies ni CORS trop permissifs. Instructure a fait le même choix dans Canvas en 2025 en ajoutant un attribut sandbox aux iframes qui affichent des fichiers HTML téléversés.

Le zip SCORM envoyé par un prestataire, c'est du code tiers. Il mérite le même traitement qu'une dépendance.

Deuxième angle mort : toute l'entreprise est connectée, SSO compris

Le SSO est une bonne chose. Il évite des mots de passe en plus. Mais il change la nature du LMS : ce n'est plus un outil de formation isolé, c'est une application qui reçoit les identités de toute l'entreprise et, souvent, des attributs venus du SIRH (service, manager, site, contrat).

Ce que je vérifie systématiquement :

• La configuration SAML ou OIDC. Validation des signatures, audience, gestion des redirections après connexion, création automatique de comptes à la volée. Un plugin d'authentification mal configuré ou pas à jour reste un point de passage. Le plugin SAML2 très répandu sur Moodle a par exemple eu une faille de redirection ouverte (CVE-2022-39183), corrigée depuis.
• Le provisioning. Synchronisation SCIM ou export SIRH : quels attributs partent vers le LMS, qui peut les modifier, et que se passe-t-il au départ d'un salarié. Un compte qui survit à son propriétaire est un classique.
• Les rôles à privilèges. Sur Moodle, la RCE CVE-2024-43425, découverte par RedTeam Pentesting et corrigée en août 2024, demandait seulement le droit de créer ou modifier des questions de quiz, un droit que beaucoup de formateurs ont. En septembre 2026, MSA-26-0042 corrigeait une injection SQL accessible aux enseignants. Le rôle « formateur » n'est pas un rôle anodin.
• Les sessions et le MFA. Durée des sessions, MFA sur les administrateurs. Moodle a corrigé en juin 2026 un contournement du MFA par e-mail (CVE-2026-58332) : avoir activé le MFA ne dispense pas de le maintenir à jour.

Le rayon d'impact est le vrai sujet. Une faille dans le LMS ne touche pas « la formation » ; elle touche chaque salarié connecté et chaque application qui l'embarque.

Troisième angle mort : la plateforme qu'on ne met pas à jour

C'est le constat que je fais le plus souvent en audit : des LMS en production sur des versions qui ne reçoivent plus de correctifs, avec des plugins dont le développeur a disparu, et des instances oubliées chez un prestataire ou restées en ligne après un ancien projet. Je n'ai pas de statistique publique fiable sur la part des LMS non supportés en France ; en revanche, les calendriers des éditeurs sont clairs.

• Moodle. La version LTS 4.1 ne reçoit plus de correctifs de sécurité depuis le 8 décembre 2025, tout comme la 4.4. La 5.0 est sortie du support le 5 octobre 2026. Restent supportées la 4.5 LTS (jusqu'au 4 octobre 2027), la 5.1, la 5.2 et la 5.3 LTS sortie ce mois-ci. Et le rythme est soutenu : en 2026, le CERT-FR a publié des avis Moodle en avril (dont une exécution de code à distance via le plugin Google Drive, CVE-2026-7275), juillet, septembre et le 15 octobre (CERTFR-2026-AVI-1318, avec un défaut de contrôle d'accès sur les contenus H5P, visibles y compris par des utilisateurs non connectés).
• Drupal, souvent utilisé comme portail de formation, notamment via la distribution Opigno. Le 14 octobre 2026, SA-CORE-2026-014 corrigeait une exécution de code à distance critique dans le module Field UI ; selon l'équipe sécurité de Drupal, au moins un chemin d'exploitation ne demande pas d'authentification quand certains modules contribués sont présents. Seules les branches 10.6, 11.3 et 11.4 sont corrigées : tout ce qui est en dessous est en fin de vie. Drupal 7, lui, n'a plus aucun correctif depuis le 5 janvier 2025, et W3Techs mesurait encore 29,1 % des sites Drupal sur cette version au 20 octobre 2026.
• Chamilo, très présent dans l'enseignement et la formation francophones. CVE-2023-4220 permettait à un attaquant non authentifié de téléverser un web shell sur les versions jusqu'à 1.11.24. Le correctif existe depuis 2023, l'exploit est public. Une instance non mise à jour reste exposée.

Et sous tout ça, il y a PHP lui-même. Moodle, Drupal et Chamilo tournent dessus. La faille php2shell de cette semaine rappelle qu'il faut aussi maintenir le moteur, pas seulement l'application.

Et les SaaS : Cornerstone, Docebo, 360Learning ?

Avec un LMS en SaaS, vous ne gérez pas les correctifs du code, et c'est un vrai avantage. Mais la surface d'attaque ne disparaît pas, elle se déplace vers ce que vous configurez : le SSO, les rôles administrateurs, les intégrations avec le SIRH, les clés d'API et leurs droits, les connecteurs LTI vers des contenus tiers, les exports de données et l'embarquement en iframe dans vos portails. Les trois premiers angles morts s'appliquent donc presque tels quels. L'audit porte sur la configuration et les flux, pas sur le code, et il passe aussi par le contrat : notification des incidents, localisation des données, réversibilité.

Ce qui se passe quand ça lâche

Les plateformes du monde de l'enseignement et de la formation sont visées. En avril 2026, l'université d'Angers a porté plainte après l'extraction de 127 400 fiches de sa plateforme ip'Online, le réseau qui relie étudiants, anciens et personnels : noms, coordonnées, parcours académique et professionnel. L'université a précisé avoir pris des mesures « avec le prestataire » et notifié la CNIL. Ce n'était pas un LMS au sens strict, mais c'est le même schéma : une plateforme tierce, beaucoup de comptes, des données personnelles.

Le même mois, un groupe a revendiqué des fuites dans plusieurs universités françaises. Ces revendications n'ont pas été confirmées officiellement à ma connaissance, je ne les détaille donc pas.

La checklist d'audit d'un LMS

Voici ce que je passe en revue, dans cet ordre.

Inventaire

• Toutes les instances : production, préproduction, anciennes plateformes, instances hébergées par des prestataires.
• Versions exactes du LMS, de PHP, de la base de données, et date de fin de support de chacune.
• Liste des plugins et modules, avec leur mainteneur et leur dernière mise à jour.

Mises à jour

• Abonnement aux avis de sécurité de l'éditeur (moodle.org/security, drupal.org/security) et du CERT-FR.
• Délai réel entre un correctif publié et son déploiement, et qui en est responsable contractuellement.
• Plan de migration pour toute version hors support.

Iframe et contenus

• En-tête CSP frame-ancestors limité aux portails légitimes, pas de levée globale de X-Frame-Options.
• Attributs des cookies de session (Secure, HttpOnly, SameSite) et justification de tout SameSite=None.
• Vérification de l'origine dans les échanges postMessage.
• Paquets SCORM, xAPI et H5P servis depuis un domaine distinct ou dans une iframe sandbox, et analysés avant dépôt.
• Types de fichiers autorisés au téléversement.

Identité et accès

• Configuration SAML/OIDC : signatures, audience, redirections, création de comptes à la volée.
• Provisioning : attributs transmis, désactivation des comptes au départ.
• Revue des rôles (administrateurs, gestionnaires, formateurs) et des droits sensibles comme la création de questions.
• MFA obligatoire pour les administrateurs, durée des sessions.
• Comptes locaux restants en dehors du SSO, notamment les comptes d'urgence et de prestataires.

Intégrations et données

• Clés d'API, jetons SIRH, connecteurs LTI : périmètre, rotation, propriétaire.
• Exports, sauvegardes et fichiers de restauration : où ils sont, qui y accède (Moodle a corrigé en juin 2026 une lecture arbitraire de fichiers via la restauration de sauvegarde).
• Données personnelles des apprenants : durée de conservation, registre RGPD, sous-traitants.
• Journalisation des connexions administrateur et des actions sensibles.

Quand faire auditer

Au minimum dans ces cas : avant d'embarquer le LMS dans un nouveau portail ou de le brancher au SSO, à chaque changement de prestataire ou d'hébergeur, quand une version arrive en fin de support, et après un avis critique comme php2shell ou SA-CORE-2026-014 si vous n'êtes pas certain d'avoir tout corrigé. Et si personne dans l'équipe ne sait dire en cinq minutes quelle version tourne et qui la met à jour, c'est le bon moment.

Aller vite, mais avec quelqu'un qui regarde

Le vibe coding, les plateformes livrées en quelques semaines, l'élasticité du SaaS : tout ça a de la valeur, et je l'utilise. Mais la vitesse ne remplace pas quelqu'un qui garde un œil sur la sécurité et fait des préconisations, quitte à frustrer le client sur un délai de livraison ou sur une intégration qu'on aurait voulue plus souple. Un LMS embarqué partout, connecté à l'identité de toute l'entreprise et mis à jour une fois par an, c'est précisément le genre de dette qu'on ne voit pas tant qu'elle ne coûte rien. Les failles qui font du bruit sont rarement nouvelles ; elles touchent simplement beaucoup de monde en même temps.

Auditer et sécuriser votre LMS

>

Je sécurise des LMS et je passe des audits de sécurité en permanence : Moodle, Drupal, Chamilo, et les plateformes SaaS comme Cornerstone ou Docebo, côté configuration, SSO et intégrations. Le LMS est souvent une faille, il faut y faire très attention. Si vous voulez savoir où en est le vôtre, contactez-moi.

Sources

• Moodle, Security announcements, dont MSA-26-0044 (15 octobre 2026), MSA-26-0042 (22 septembre 2026), MSA-26-0006, CVE-2026-7275 (29 avril 2026), MSA-26-0013 (CVE-2026-58332) et MSA-26-0014 (CVE-2026-58333) (22 juin 2026).
• Moodle, MSA-24-0026 : Remote code execution via calculated question types, 19 août 2024, et RedTeam Pentesting, Back to School - Exploiting a Remote Code Execution Vulnerability in Moodle.
• Moodle, Releases et calendrier de support, et Historique des versions, consultés le 22 octobre 2026.
• CERT-FR, avis Moodle CERTFR-2026-AVI-0508, CERTFR-2026-AVI-0921, CERTFR-2026-AVI-1210 et CERTFR-2026-AVI-1318.
• Drupal, SA-CORE-2026-014 : Remote code execution, 14 octobre 2026, et PSA-2026-10-12.
• Drupal, Drupal 7 End of Life.
• W3Techs, Historical trends in the usage of Drupal versions, consulté le 22 octobre 2026.
• NVD, CVE-2023-4220 (Chamilo LMS).
• CVE, CVE-2022-39183 (plugin SAML2 pour Moodle).
• Rustici Software, Cross-Site Scripting Vulnerability, et Tenable, TRA-2022-21.
• scorm-again, Cross-Frame Communication.
• Instructure, commit Canvas LMS ajoutant un attribut sandbox, 26 mars 2025.
• France 3 Pays de la Loire, Piratage de données à l'université d'Angers, 16 avril 2026.