Is your GLPI instance exposed to already-catalogued vulnerabilities without you knowing? In most of the environments we take over for maintenance, no one can immediately say which CVE affects the version in production, or whether PHP has the right security flags set. The NexTool CVE Scan Vulnerabilities module cross-references the installed version against public CVE databases and audits 17 critical points of the environment in seconds, producing a visual Security Score.
The problem
Service desk teams running GLPI rarely have a formal process to track vulnerabilities tied to the version in production. NVD (NIST) and the GitHub Advisory Database publish CVEs continuously, but tracking that manually, version by version, is unworkable for people who also open and close tickets all day.
Worse: the software version is only half the risk. The PHP environment and server configuration introduce silent flaws - display_errors left on in production leaking paths and stack traces, a session cookie without HttpOnly, a missing Content-Security-Policy or Strict-Transport-Security. Each of these is an attack surface that usually only surfaces after an incident, when it is already too late.
How CVE Scan works
When you run the scan, the module detects the version via the GLPI_VERSION constant and cross-references it with a dynamic CVE base built from three sources:
- NVD / NIST - the authoritative source for the CVSS score and official metadata of each flaw.
- GitHub Advisory Database - advisory links and details of flaws reported by the community.
- Static fallback base - guarantees coverage even when the external APIs are unavailable or the request limit has been exceeded.
The merge is done by CVE ID: NVD wins for the CVSS, GitHub supplies the advisory links. A local cache is refreshed daily by cron and on demand on every manual run. In parallel with the CVE cross-check, the module runs 17 security checks of the environment, grouped in four categories: PHP configuration (8 checks), GLPI-specific checks (3), HTTP headers (3) and others (3), such as end-of-life PHP. The result becomes a Security Score from 0 to 100, with a colour band - red for critical, yellow for moderate and green for healthy - and each item shows its status, the version that fixes the flaw and the remediation instruction.
What it sees that native GLPI does not
| Audited point | Native GLPI | CVE Scan module |
|---|---|---|
| CVEs of the installed version | No warning | Cross-references GLPI_VERSION with NVD and GitHub Advisory |
| Leftover install/ directory | Warning on the login screen | Consolidated in the score, with a removal instruction |
| display_errors in production | Not checked | Dedicated check |
| CSP / HSTS / X-Frame-Options headers | Not checked | Three HTTP header checks |
| config_db.php permission | No warning | Dedicated check |
| Risk evolution over time | Absent | Security Score recorded on every scan |
What we learned running this in the field
In maintenance, the check that most often fails in a client environment is session.cookie_secure - and it is almost always a misread false alarm. GLPI sits behind a reverse proxy that terminates TLS, so PHP sees the connection as http and does not mark the cookie as secure. The fix is not in GLPI: it is getting the X-Forwarded-Proto header right on the proxy and forcing HSTS at the edge. The runner-up is the install/ directory forgotten after setup. GLPI does warn about it on the login screen, but across a fleet of dozens of instances that warning goes unnoticed - the consolidated score is what forces the team to look. That is why we treat CVE Scan as a thermometer, not a verdict: it points to the spot, but the decision to fix it at the right source still belongs to whoever runs the environment.
Checking the same points by hand
Before installing anything, you can reproduce part of the diagnosis directly on the server. These are exactly some of the points the module audits in PHP and on the filesystem:
# PHP flags that CVE Scan audits (run on the GLPI server)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'
# Permission of the database credentials file: must be 400 or 440, never 644
stat -c '%a %n' /var/www/glpi/config/config_db.php
# Installation directory that should have been removed after setup
test -f /var/www/glpi/install/install.php && echo 'ALERT: install/ still present - remove it'
# PHP version: warn if it is end-of-life (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'The module automates this, adds the cross-check with the CVE databases and keeps the history - but running the commands above already shows why manual auditing does not scale past two or three instances.
How to enable it
- Install the NexTool plugin on your GLPI.
- Go to Setup > NexTool > Modules.
- Find the CVE Scan Vulnerabilities card, click Install and then Enable.
- Open the module and click Run Scan on the features tab.
- Optional: enter a GitHub token and an NVD API Key on the settings tab to raise the request limits of the external databases.
Who it is for (and when it is not)
It is for GLPI administrators who need a fast, recurring security audit, teams facing internal or external audits that need evidence of the environment state, and managers who want to track the security posture over time through the scan history. It is not a silver bullet: it does not replace a pentest, it fixes nothing on its own, and it must not become an excuse to postpone the GLPI upgrade. If your environment already has a corporate scanner (Nessus, Qualys) pointing at the same host, CVE Scan is a light, GLPI-specific complement, not a competitor.
Compatibility
- GLPI: 10.x and 11.x
- Plan: FREE
- Plugin: NexTool 3.x or later
Next step
CVE Scan Vulnerabilities is part of NexTool, the modular plugin for GLPI. Explore the other modules or talk to the team for a complete security assessment of your environment.
This content was produced with the help of artificial intelligence and reviewed by the NexTool Solutions team.
