Sept failles. Une seule application. Un référentiel SI complet à portée d'attaquant. GLPI, la solution open source de gestion de parc informatique éditée par Teclib, est massivement déployée dans les directions des systèmes d'information françaises et européennes, où elle sert de référentiel central pour le matériel, les utilisateurs et les tickets de support.
Le CERT-FR a publié le 7 mai 2026 un avis, référencé CERTFR-2026-AVI-0551, consacré à ces sept vulnérabilités. Les correctifs sont disponibles. La fenêtre d'action est courte.
Sept CVE, plusieurs catégories de risques
L'avis du CERT-FR identifie sept vulnérabilités distinctes : CVE-2026-32312, CVE-2026-40108, CVE-2026-42317, CVE-2026-42318, CVE-2026-42320, CVE-2026-42321 et CVE-2026-5385. Toutes les versions de GLPI antérieures à 10.0.25 sur la branche stable, et antérieures à 11.0.7 sur la branche majeure récente, sont concernées. Les versions correctives 10.0.25 et 11.0.7 ont été publiées en réponse directe à ces signalements.
Les catégories de risques documentées par l'éditeur couvrent un spectre étendu. On y trouve des atteintes à l'intégrité des données, des contournements de la politique de sécurité, une faille de type SSRF (Server-Side Request Forgery) permettant de manipuler le serveur GLPI pour qu'il effectue des requêtes HTTP vers des ressources internes normalement inaccessibles depuis l'extérieur, ainsi que des injections de code indirectes à distance, autrement dit du XSS. Une partie des failles correspond enfin à une catégorie non spécifiée par l'éditeur. À la date de publication de l'avis, aucune exploitation active n'a été signalée dans la nature. La publication publique des sept CVE constitue en elle-même une feuille de route pour les attaquants opportunistes, et la fenêtre avant exploitation se réduit généralement à quelques jours après une divulgation publique. Cela réduit drastiquement le temps dont disposent les équipes pour prioriser les CVE réellement exploitées et appliquer les correctifs.
Pourquoi GLPI constitue une cible de valeur
GLPI n'est pas un outil périphérique. Dans une organisation qui l'utilise sérieusement, il concentre des données particulièrement sensibles : annuaire complet du personnel, affectations matérielles, historique des tickets de support, souvent enrichi de captures d'écran, fichiers joints et correspondances email. Certaines instances stockent également des informations sur les prestataires ou les clients de l'entreprise. Un attaquant qui obtient un accès administrateur à GLPI met la main sur une cartographie quasi exhaustive du système d'information, comme le souligne également l'analyse publiée par Leto Legal.
C'est précisément ce que rend possible une faille XSS bien placée dans une plateforme de ticketing. Le scénario est classique : injection d'un payload JavaScript dans un champ de ticket, consultation du ticket par un administrateur, vol du token de session dans son navigateur. À partir de là, l'attaquant dispose d'un accès administrateur complet. Les indices de compromission associés à ce type d'attaque sont souvent ténus, car l'action initiale ressemble à une consultation légitime.
La faille SSRF, un pivot vers le réseau interne
La SSRF mérite une attention particulière. GLPI est typiquement déployé en interne, avec une visibilité réseau étendue. Le serveur GLPI peut souvent contacter directement les contrôleurs de domaine, les interfaces d'administration d'équipements réseau, les hyperviseurs, les solutions de sauvegarde, autant de cibles qui ne sont jamais exposées sur Internet. Une SSRF transforme alors GLPI en relais d'attaque.
L'attaquant n'a pas besoin d'accéder directement à ces systèmes. Il manipule GLPI pour qu'il émette les requêtes à sa place, depuis le surface d'attaque interne de l'organisation. C'est un schéma de pivot redoutable : une faille web visible depuis Internet ou depuis un compte utilisateur peu privilégié devient un point d'appui pour atteindre des interfaces d'administration critiques. Le contournement de la segmentation réseau, c'est exactement ce que ce type de vulnérabilité offre.
Calendrier de mise à jour
La recommandation est directe : déployer 10.0.25 ou 11.0.7 sans délai. Le choix entre les deux branches dépend de la version actuellement en production et de la politique de mise à jour de l'organisation. Les correctifs sont publiés sur le dépôt GitHub officiel du projet.
Avant la mise à jour, plusieurs précautions s'imposent. Sauvegarder la base de données GLPI ainsi que le répertoire des fichiers joints. Tester la nouvelle version dans un environnement de préproduction si le parc applicatif a fait l'objet de personnalisations ou de plugins tiers. Vérifier ensuite l'état des sessions actives et forcer une réauthentification des comptes à privilèges après la bascule.
Pour les organisations qui ne peuvent pas mettre à jour immédiatement, plusieurs mesures de réduction du risque sont applicables. Restreindre l'accès à l'interface GLPI aux seuls réseaux légitimes, via filtrage IP ou VPN. Limiter les comptes administrateurs au strict nécessaire. Surveiller les logs d'accès, notamment les requêtes sortantes inhabituelles depuis le serveur GLPI, qui peuvent trahir une tentative de SSRF. À plus long terme, ce type d'incident est aussi l'occasion de réinterroger les critères de threat intel qui alimentent la veille vulnérabilités de l'équipe.
Un signal à ne pas sous-estimer
L'absence d'exploitation active signalée à ce jour ne doit pas conduire à temporiser. La divulgation publique des CVE constitue en elle-même une feuille de route pour les attaquants opportunistes, même sans preuve de concept publiée. Les équipes de reverse engineering offensives savent extraire les détails d'une vulnérabilité à partir d'un diff de code entre la version vulnérable et la version corrigée. Le délai entre la publication d'un avis et l'apparition d'exploits fonctionnels se compte désormais en jours, parfois en heures pour les cibles à forte valeur.
GLPI fait clairement partie de ces cibles. Sa popularité dans l'écosystème francophone, sa position centrale dans la cartographie SI et sa connectivité réseau étendue en font un point d'entrée stratégique. La mise à jour vers 10.0.25 ou 11.0.7 doit figurer en haut de la file d'attente des opérations de sécurité de la semaine.
Questions fréquentes
GLPI est-il activement exploité actuellement ?
Aucune exploitation active n'est signalée à la date de publication de l'avis CERTFR-2026-AVI-0551. Cela dit, la divulgation publique des sept CVE (CVE-2026-32312, CVE-2026-40108, CVE-2026-42317, CVE-2026-42318, CVE-2026-42320, CVE-2026-42321 et CVE-2026-5385) oriente directement les attaquants vers les zones vulnérables du code, et un diff entre la version 10.0.24 et 10.0.25 suffit souvent à reconstituer un exploit fonctionnel. Le délai entre publication d'un avis et apparition d'exploits opportunistes se compte en jours, parfois en heures sur des cibles à forte valeur comme GLPI. Concrètement, ne traitez pas l'absence de PoC public comme un répit : planifiez le déploiement de 10.0.25 ou 11.0.7 cette semaine.
Comment une faille SSRF dans GLPI peut-elle compromettre le réseau interne ?
L'attaquant n'a besoin que d'un point d'entrée pour forcer le serveur GLPI à émettre des requêtes HTTP vers des ressources qu'il ne pourrait pas atteindre directement depuis l'extérieur. Or GLPI est typiquement déployé en interne avec une visibilité réseau large : il peut joindre les contrôleurs de domaine, les interfaces d'administration des équipements réseau, les hyperviseurs et les solutions de sauvegarde. La faille web devient alors un point de pivot qui contourne la segmentation prévue par l'architecture, sans que l'attaquant ait jamais besoin d'un accès direct à ces systèmes. Côté détection, surveillez les requêtes sortantes inhabituelles émises depuis le serveur GLPI dans les logs d'accès : c'est le signal le plus exploitable en attendant le correctif.
Faut-il mettre à jour même si GLPI n'est pas exposé sur Internet ?
Oui, sans hésitation. Les failles XSS de cet avis peuvent être déclenchées par un utilisateur interne malveillant ou par un simple lien piégé envoyé à un administrateur via email ou messagerie, le payload JavaScript étant alors injecté dans un champ de ticket consulté ensuite par la cible. Le risque est d'autant plus réel que GLPI concentre l'annuaire du personnel, les affectations matérielles, les pièces jointes des tickets et parfois les informations sur les prestataires : un vol de token de session suffit à exposer toute cette cartographie. L'exposition réseau n'est qu'un critère parmi d'autres, et un GLPI accessible uniquement en interne reste une cible légitime pour quiconque dispose d'un accès au ticketing.
