¿Tu instancia de GLPI está expuesta a vulnerabilidades ya catalogadas sin que lo sepas? En la mayoría de los entornos que asumimos para mantenimiento, nadie puede decir de inmediato qué CVE afecta a la versión en producción ni si PHP tiene las banderas de seguridad correctas. El módulo CVE Scan Vulnerabilidades de NexTool cruza la versión instalada con bases públicas de CVE y audita 19 puntos críticos del entorno en segundos, generando un Security Score visual.
El problema
Los equipos de service desk que operan GLPI rara vez tienen un proceso formal para rastrear las vulnerabilidades asociadas a la versión en producción. El NVD (NIST) y la GitHub Advisory Database publican CVEs continuamente, pero seguir eso a mano, versión por versión, es inviable para quien también abre y cierra tickets todo el día.
Peor: la versión del software es solo la mitad del riesgo. El entorno PHP y la configuración del servidor introducen fallos silenciosos - display_errors activo en producción filtrando rutas y stack traces, una cookie de sesión sin HttpOnly, la ausencia de Content-Security-Policy o de Strict-Transport-Security. Cada uno de esos detalles es una superficie de ataque que suele aparecer solo después del incidente, cuando ya es tarde.
Cómo funciona CVE Scan
Al ejecutar el escaneo, el módulo detecta la versión mediante la constante GLPI_VERSION y la cruza con una base dinámica de CVEs armada a partir de tres fuentes:
- NVD / NIST - la fuente autoritativa para la puntuación CVSS y los metadatos oficiales de cada fallo.
- GitHub Advisory Database - los advisories publicados por el propio proyecto GLPI, con las versiones afectadas y la versión que corrige cada fallo por línea de versión (como 10.0 y 11.0), además del enlace del advisory.
- Base estática de reserva - lista integrada en el módulo con los fallos críticos y altos, usada antes de la primera actualización de la base y en entornos que no alcanzan GitHub ni el NVD.
La combinación se hace por CVE ID: el NVD prevalece para el CVSS, GitHub aporta los rangos de versión y los enlaces de advisory. La base local se actualiza todos los días con una tarea automática y, bajo demanda, con el botón Actualizar base; el escaneo en sí no consulta GitHub ni el NVD, y si las dos fuentes fallan la base anterior sigue vigente. En paralelo al cruce de CVEs, el módulo ejecuta 19 verificaciones de seguridad del entorno, agrupadas en cinco categorías: configuración de PHP (8 checks), verificaciones específicas de GLPI (4, entre ellas las contraseñas por defecto de las cuentas de instalación), cabeceras HTTP (4), permisos de archivos (2) y versión de PHP (1), que señala un PHP fuera del soporte de seguridad. El resultado se convierte en un Security Score de 0 a 100, con una banda de color - rojo para crítico, amarillo para moderado y verde para saludable - y cada ítem muestra su estado, la versión que corrige el fallo y la instrucción de corrección.
Lo que ve que GLPI nativo no muestra
| Punto auditado | GLPI nativo | Módulo CVE Scan |
|---|---|---|
| CVEs de la versión instalada | No avisa | Cruza GLPI_VERSION con NVD y GitHub Advisory |
| Directorio install/ olvidado | Aviso en la pantalla de login | Señalado en el score cuando el instalador responde por la web, con instrucción de eliminación |
| display_errors en producción | No verifica | Check dedicado |
| Cabeceras CSP / HSTS / X-Frame-Options / X-Content-Type-Options | No verifica | Cuatro checks de cabecera HTTP |
| Permiso de config_db.php | No avisa | Check dedicado |
| Evolución del riesgo en el tiempo | Inexistente | Security Score registrado en cada escaneo |
Lo que aprendimos ejecutándolo en campo
En el mantenimiento, el check que más falla en un entorno de cliente es session.cookie_secure - y casi siempre la causa está fuera de GLPI. GLPI está detrás de un proxy inverso que termina el TLS, así que PHP ve la conexión como http y no marca la cookie como segura. La corrección no está en GLPI: es acertar la cabecera X-Forwarded-Proto en el proxy y forzar HSTS en el borde. El segundo campeón es el directorio install/ olvidado tras el setup. GLPI avisa de eso en la pantalla de login, pero en un parque de decenas de instancias ese aviso pasa desapercibido - el score consolidado es lo que obliga al equipo a mirar. Por eso tratamos CVE Scan como termómetro, no como veredicto: señala el punto, pero la decisión de corregir en el origen correcto sigue siendo de quien mantiene el entorno.
Verificando los mismos puntos a mano
Antes de instalar nada, puedes reproducir parte del diagnóstico directamente en el servidor. Estos son exactamente algunos de los puntos que el módulo audita en PHP y en el sistema de archivos:
# Banderas de PHP que CVE Scan audita (ejecutar en el servidor de GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'
# Permiso del archivo de credenciales de la base: debe ser 400 o 440, nunca 644
stat -c '%a %n' /var/www/glpi/config/config_db.php
# Directorio de instalacion que deberia haberse eliminado tras el setup
test -f /var/www/glpi/install/install.php && echo 'ALERTA: install/ aun presente - eliminar'
# Version de PHP: avisar si esta en fin de vida (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'El módulo automatiza esto, añade el cruce con las bases de CVE y guarda el historial - pero ejecutar los comandos de arriba ya muestra por qué la auditoría manual no escala más allá de dos o tres instancias.
Cómo activarlo
- Instala el plugin NexTool en tu GLPI.
- Accede a Configuración > NexTool > Módulos.
- Localiza la tarjeta CVE Scan Vulnerabilidades, pulsa Instalar y luego Activar.
- Abre el módulo y, en el Panel, pulsa Actualizar base y luego Ejecutar escaneo.
- Opcional: introduce un token de GitHub y una API Key del NVD en la pestaña de configuración para elevar los límites de petición de las bases externas.
Para quién es (y cuándo no)
Es para administradores de GLPI que necesitan una auditoría de seguridad rápida y recurrente, equipos que enfrentan auditorías internas o externas y necesitan evidencia del estado del entorno, y responsables que quieren seguir la postura de seguridad en el tiempo mediante el historial de escaneos. No es una bala de plata: no reemplaza un pentest, no corrige nada por sí solo y no debe ser excusa para posponer la actualización de GLPI. Si tu entorno ya tiene un escáner corporativo (Nessus, Qualys) apuntando al mismo host, CVE Scan es un complemento ligero y específico de GLPI, no un competidor.
Compatibilidad
- GLPI: 10.x y 11.x
- Plan: FREE
- Plugin: NexTool 6.11.0 o superior
Siguiente paso
CVE Scan Vulnerabilidades forma parte de NexTool, el plugin modular para GLPI. Conoce los demás módulos o habla con el equipo para una evaluación de seguridad completa de tu entorno.
Revisado por el equipo de NexTool Solutions.
