GLPI : le CERT-FR alerte sur 7 vulnérabilités — SSRF, XSS et atteinte à l'intégrité des données
Le CERT-FR a publié le 7 mai 2026 l'avis CERTFR-2026-AVI-0551 documentant sept vulnérabilités dans GLPI, la solution open-source de gestion de parc informatique utilisée par des milliers d'organisations européennes. Pour les DPO et RSSI, l'enjeu n'est pas seulement technique : GLPI concentre des données personnelles d'employés, des inventaires d'actifs et des tickets de support qui décrivent souvent des incidents sensibles. Une exploitation de ces failles déclenche immédiatement la chaîne d'obligations RGPD.
Ce qui s'est passé
L'ANSSI documente sept CVE — CVE-2026-32312, CVE-2026-40108, CVE-2026-42317, CVE-2026-42318, CVE-2026-42320, CVE-2026-42321 et CVE-2026-5385 — affectant toutes les versions de GLPI antérieures à 10.0.25 (branche stable) et 11.0.7 (nouvelle branche majeure). Les risques identifiés couvrent un spectre inquiétant pour un outil ITSM : atteinte à l'intégrité des données, contournement de la politique de sécurité, falsification de requêtes côté serveur (SSRF) et injection de code indirecte à distance (XSS).
Le bulletin éditeur du 29 avril 2026 référencé par le CERT-FR fournit les correctifs. Aucune alerte d'exploitation active dans la nature n'est mentionnée à ce stade, mais le détail public des CVE constitue déjà un guide pour les attaquants opportunistes.
Pourquoi c'est important pour les DPO et RSSI
GLPI n'est pas un outil neutre du point de vue des données personnelles. Il stocke généralement des annuaires complets d'employés, des affectations de matériel, l'historique des tickets de support — souvent enrichi de captures d'écran, de fichiers joints et de contenu d'emails — et parfois des informations sur des prestataires ou des clients. Un SSRF combiné à un XSS ouvre la voie à des scénarios d'exfiltration ou de pivot interne particulièrement graves.
Du côté du droit, deux régimes se cumulent. L'article 32 du RGPD impose de mettre en œuvre les mesures techniques et organisationnelles appropriées pour assurer un niveau de sécurité adapté au risque, ce qui inclut le maintien à niveau des correctifs sur tout système traitant des données personnelles. En cas de violation avérée, l'article 33 du RGPD oblige à notifier la CNIL dans les 72 heures. Pour les entités essentielles ou importantes au sens de la directive NIS 2, l'ANSSI doit en outre être informée dans un délai de 24 heures pour les incidents significatifs.
Cette publication s'inscrit dans une série continue d'avis CERT-FR ces dernières semaines. Le même mécanisme a été activé pour Apache HTTP Server et pour PaperCut NG/MF : la cadence des avis s'accélère, et la marge de manœuvre des équipes IT pour temporiser les patchs se réduit.
Ce que ça change concrètement
Quatre actions s'imposent dans les heures qui suivent la prise en compte de l'avis.
1. Inventorier l'exposition. Identifier toutes les instances GLPI déployées, internes comme exposées sur Internet, et confirmer leur version exacte. Les déploiements oubliés (instances de test, environnements de pré-production accessibles) sont les premiers exploités.
2. Patcher en priorité. Migrer vers GLPI 10.0.25 ou 11.0.7. Si le patching n'est pas immédiat, restreindre l'accès réseau de l'instance, durcir la configuration des extensions et activer la journalisation détaillée le temps d'appliquer le correctif.
3. Auditer les logs sur 30 jours minimum. Rechercher des appels SSRF anormaux, des injections dans les champs de tickets, des connexions depuis des IP inhabituelles. La méthodologie de réponse à une violation de données personnelles doit être déclenchée formellement si un indicateur de compromission est identifié.
4. Documenter la décision. Que vous patchiez immédiatement ou que vous conserviez la version vulnérable derrière des contrôles compensatoires, la décision et son rationnel doivent être tracés dans le registre des traitements et dans le tableau de bord des risques. C'est cette traçabilité que la CNIL et l'ANSSI examinent en cas de contrôle.
Ce que Leto pense de cette décision
L'avis GLPI confirme une tendance que nous observons depuis le début de l'année : les outils ITSM, longtemps traités comme des back-offices techniques, deviennent des vecteurs d'incident RGPD majeurs. Concentration de données personnelles, exposition réseau historique, dépendance à des extensions communautaires — le profil de risque ressemble désormais à celui d'un CRM. La conséquence pratique pour les DPO : intégrer GLPI (et ses équivalents) au registre des traitements sensibles, et imposer un SLA de patching aligné sur la criticité des données qu'il abrite.
Sources :
