Votre instance GLPI est-elle exposée à des vulnérabilités déjà répertoriées sans que vous le sachiez ? Dans la plupart des parcs que nous reprenons en maintenance, personne ne peut dire immédiatement quelle CVE touche la version en production ni si PHP a les bons drapeaux de sécurité. Le module CVE Scan Vulnérabilités de NexTool croise la version installée avec des bases publiques de CVE et audite 19 points critiques de l'environnement en quelques secondes, en produisant un Security Score visuel.
Le problème
Les équipes de service desk qui exploitent GLPI ont rarement un processus formel pour suivre les vulnérabilités liées à la version en production. Le NVD (NIST) et la GitHub Advisory Database publient des CVE en continu, mais suivre cela à la main, version par version, est irréaliste pour ceux qui ouvrent et ferment aussi des tickets toute la journée.
Pire : la version du logiciel n'est que la moitié du risque. L'environnement PHP et la configuration du serveur introduisent des failles silencieuses - display_errors activé en production qui fuit chemins et stack traces, un cookie de session sans HttpOnly, l'absence de Content-Security-Policy ou de Strict-Transport-Security. Chacun de ces détails est une surface d'attaque qui n'apparaît en général qu'après l'incident, quand il est déjà trop tard.
Comment fonctionne CVE Scan
Au lancement du scan, le module détecte la version via la constante GLPI_VERSION et la croise avec une base dynamique de CVE construite à partir de trois sources :
- NVD / NIST - la source de référence pour le score CVSS et les métadonnées officielles de chaque faille.
- GitHub Advisory Database - les advisories publiés par le projet GLPI lui-même, avec les versions touchées et la version qui corrige chaque faille par branche (comme 10.0 et 11.0), ainsi que le lien de l'advisory.
- Base statique de secours - liste intégrée au module avec les failles critiques et élevées, utilisée avant la première mise à jour de la base et dans les environnements qui n'atteignent ni GitHub ni le NVD.
La fusion se fait par CVE ID : le NVD prime pour le CVSS, GitHub apporte les plages de versions et les liens d'advisory. La base locale est mise à jour chaque jour par une tâche automatique et, à la demande, par le bouton Mettre à jour la base ; le scan lui-même n'interroge ni GitHub ni le NVD, et si les deux sources échouent la base précédente reste en vigueur. En parallèle du croisement des CVE, le module exécute 19 vérifications de sécurité de l'environnement, réparties en cinq catégories : configuration PHP (8 checks), vérifications propres à GLPI (4, dont les mots de passe par défaut des comptes d'installation), en-têtes HTTP (4), droits des fichiers (2) et version de PHP (1), qui signale un PHP sorti du support de sécurité. Le résultat devient un Security Score de 0 à 100, avec une plage de couleur - rouge pour critique, jaune pour modéré et vert pour sain - et chaque élément affiche son statut, la version qui corrige la faille et l'instruction de correction.
Ce qu'il voit et que GLPI natif ne montre pas
| Point audité | GLPI natif | Module CVE Scan |
|---|---|---|
| CVE de la version installée | Aucun avertissement | Croise GLPI_VERSION avec NVD et GitHub Advisory |
| Répertoire install/ oublié | Avertissement sur l'écran de connexion | Signalé dans le score quand l'installateur répond sur le web, avec instruction de suppression |
| display_errors en production | Non vérifié | Check dédié |
| En-têtes CSP / HSTS / X-Frame-Options / X-Content-Type-Options | Non vérifié | Quatre checks d'en-tête HTTP |
| Permission de config_db.php | Aucun avertissement | Check dédié |
| Évolution du risque dans le temps | Inexistant | Security Score enregistré à chaque scan |
Ce que nous avons appris sur le terrain
En maintenance, le check qui échoue le plus souvent chez un client est session.cookie_secure - et la cause est presque toujours hors de GLPI. GLPI est derrière un reverse proxy qui termine le TLS, donc PHP voit la connexion comme http et ne marque pas le cookie comme sécurisé. La correction n'est pas dans GLPI : il faut régler l'en-tête X-Forwarded-Proto sur le proxy et forcer HSTS en périphérie. Le deuxième plus fréquent est le répertoire install/ oublié après le setup. GLPI le signale bien sur l'écran de connexion, mais sur un parc de dizaines d'instances cet avertissement passe inaperçu - le score consolidé est ce qui oblige l'équipe à regarder. C'est pourquoi nous traitons CVE Scan comme un thermomètre, pas comme un verdict : il pointe l'endroit, mais la décision de corriger à la bonne source reste à celui qui exploite l'environnement.
Vérifier les mêmes points à la main
Avant d'installer quoi que ce soit, vous pouvez reproduire une partie du diagnostic directement sur le serveur. Voici précisément certains des points que le module audite dans PHP et sur le système de fichiers :
# Drapeaux PHP audites par CVE Scan (a executer sur le serveur GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'
# Permission du fichier d'identifiants de la base : doit etre 400 ou 440, jamais 644
stat -c '%a %n' /var/www/glpi/config/config_db.php
# Repertoire d'installation qui aurait du etre supprime apres le setup
test -f /var/www/glpi/install/install.php && echo 'ALERTE : install/ encore present - a supprimer'
# Version de PHP : alerter si elle est en fin de vie (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'Le module automatise cela, ajoute le croisement avec les bases de CVE et conserve l'historique - mais lancer les commandes ci-dessus montre déjà pourquoi l'audit manuel ne passe pas l'échelle au-delà de deux ou trois instances.
Comment l'activer
- Installez le plugin NexTool sur votre GLPI.
- Allez dans Configuration > NexTool > Modules.
- Repérez la carte CVE Scan Vulnérabilités, cliquez sur Installer puis Activer.
- Ouvrez le module et, dans le Tableau de bord, cliquez sur Mettre à jour la base puis sur Exécuter l'analyse.
- Optionnel : saisissez un token GitHub et une clé API NVD dans l'onglet de configuration pour relever les limites de requêtes des bases externes.
Pour qui (et quand non)
Pour les administrateurs GLPI qui ont besoin d'un audit de sécurité rapide et récurrent, les équipes qui subissent des audits internes ou externes et ont besoin de preuves de l'état de l'environnement, et les responsables qui veulent suivre la posture de sécurité dans le temps via l'historique des scans. Ce n'est pas une solution miracle : il ne remplace pas un pentest, ne corrige rien tout seul et ne doit pas servir d'excuse pour reporter la mise à jour de GLPI. Si votre environnement dispose déjà d'un scanner d'entreprise (Nessus, Qualys) pointant sur le même hôte, CVE Scan est un complément léger et spécifique à GLPI, pas un concurrent.
Compatibilité
- GLPI : 10.x et 11.x
- Plan : FREE
- Plugin : NexTool 6.11.0 ou supérieur
Étape suivante
CVE Scan Vulnérabilités fait partie de NexTool, le plugin modulaire pour GLPI. Découvrez les autres modules ou parlez à l'équipe pour une évaluation de sécurité complète de votre environnement.
Révisé par l'équipe NexTool Solutions.
