NexTool Solutions

Dos fallos críticos en el propio PHP, apodados PHP2Shell (CVE-2026-109618 y CVE-2026-109619), permiten ejecutar código en el servidor mediante peticiones sin iniciar sesión, antes de que se ejecute cualquier código de la aplicación. Afectan a toda instalación de PHP que atiende peticiones web, y GLPI funciona sobre PHP. La corrección está en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026. Esta guía explica qué son los fallos, por qué GLPI está en la línea de fuego, cómo averiguar dónde tiene PHP, cómo corregirlo en cada escenario, cómo saber si alguien ya ha entrado y qué hacer después.

Esta guía utiliza la información pública disponible el 22 de octubre de 2026. Los avisos de seguridad cambian rápido: consulte también el aviso de su proveedor o de su distribución antes de actuar.

Actualización: el 23 de octubre de 2026, PHP divulgó un tercer fallo, el CVE-2026-115560, todavía sin corrección. Consulte qué cambia y la configuración que protege.

Resumen para quien tiene cinco minutos

Actualización del 23/10: un tercer fallo, CVE-2026-115560

El 23 de octubre, el proyecto PHP publicó un aviso sobre un tercer fallo de ejecución remota de código, el CVE-2026-115560, relacionado con la función de progreso de subida de las sesiones (session upload progress). Es distinto de los dos de PHP2Shell, y las versiones del 21 y el 22 de octubre no lo corrigen. La corrección llegará en la próxima versión regular de PHP, todavía sin fecha, y el aviso completo se publicará junto con ella.

La vía de ataque es mucho más estrecha que la de PHP2Shell. Solo existe cuando se dan tres condiciones a la vez:

1. el php.ini define session.serialize_handler como php_binary o php_serialize;
2. la aplicación cambia ese valor a php durante la ejecución, con ini_set(), antes de abrir la sesión;
3. el progreso de subida de la sesión está activado, que es el valor por defecto de PHP.

GLPI no hace ese cambio. Hemos revisado el código de GLPI 10, 11 y 12: no modifica el serialize_handler y no usa el progreso de subida de la sesión. Un servidor que solo ejecuta GLPI, con la configuración por defecto de PHP, no queda expuesto por esta vía. El riesgo aparece cuando el mismo PHP atiende otras aplicaciones, como un sitio web, una tienda o un sistema heredado, que usted no puede auditar.

Aun así, la recomendación es desactivar la función ahora. El propio PHP ya lo había sugerido el 21 de octubre como medida de contención para el CVE-2026-109619, y GLPI no pierde nada:

session.upload_progress.enabled = Off

Ponga la línea en el php.ini del PHP que atiende la web o en el pool de PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off) y reinicie PHP-FPM o Apache. Configurarlo desde el código, con ini_set(), o en un archivo .user.ini no protege. Dónde está el archivo en cada escenario:

Para comprobarlo en el servidor, use PHP-FPM y no el PHP de línea de comandos, que lee otro archivo:

sudo php-fpm8.3 -i | grep session.upload_progress.enabled
grep -rn upload_progress /etc/php/8.3/fpm/

El resultado esperado es Off. Si algún pool tiene la línea con on, prevalece sobre el php.ini.

Consejo: esta configuración no sustituye la actualización de los fallos del 21 de octubre. Solo cierra el fallo nuevo hasta que salga la corrección. Cuando PHP publique la próxima versión, vuelva a actualizar.

Qué ha pasado

El proyecto PHP publicó correcciones de seguridad para dos fallos de ejecución remota de código en el núcleo del lenguaje. En el changelog oficial, las correcciones aparecen como "Avoid state corruption via bailout" (GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp). Fuentes de seguridad citan una puntuación de 9,2 en la escala CVSS 4.0, lo que los sitúa en la franja crítica. Algunas fuentes citan 9,8 en la escala CVSS 3.1 del NVD.

En términos sencillos:

• CVE-2026-109618: una condición de falta de memoria puede interrumpir PHP en mitad de una petición, con datos internos solo parcialmente inicializados. En la limpieza de la petición, PHP pasa a tratar esos datos inválidos como válidos.
• CVE-2026-109619: un estado interno de una petición puede sobrevivir después de que se haya liberado su memoria. La petición siguiente, atendida por el mismo proceso, puede usar ese estado antes de que se reinicialice.

Ambos casos son problemas de gestión de memoria dentro del intérprete, y eso es lo que los hace graves. Según los análisis publicados, una sola petición sin autenticación puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación. Es decir: la pantalla de inicio de sesión de GLPI, los permisos de perfil y las reglas de la aplicación ni siquiera llegan a consultarse.

Qué instalaciones están expuestas

Todas las formas de ejecutar PHP para la web aparecen en los avisos: PHP-FPM (la más común con Nginx y con Apache moderno), Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los análisis señalan mod_php como el escenario de mayor riesgo.

El PHP de línea de comandos (CLI), que ejecuta las acciones automáticas de GLPI mediante cron, no atiende peticiones web. Suele estar en la misma versión y actualizarse a la vez.

No es solo GLPI

El fallo está en PHP, no en una aplicación. Por eso, cualquier sistema en PHP que atienda la web está expuesto, y la corrección es la misma para todos: actualizar PHP y reiniciar el servicio. Actualizar WordPress, GLPI o un plugin no lo resuelve.

La alerta no se ha limitado a los profesionales de TI: Mercado Pago, por ejemplo, avisó a los comercios que usan WooCommerce, PrestaShop y Adobe Commerce (Magento) de que revisaran el PHP de sus tiendas.

En la práctica, quien se ocupa de GLPI casi siempre se ocupa también de otros servidores con PHP: el sitio web de la empresa, la intranet, la monitorización, el sistema heredado que nadie apagó. Corregir solo GLPI deja la puerta abierta en el servidor de al lado. En el Paso 1 mostramos cómo usar el propio inventario de GLPI para encontrarlos todos.

¿Ya los están explotando?

Las fuentes discrepan, y eso no cambia la recomendación:

• Amazon: según Help Net Security, el equipo de inteligencia de amenazas de Amazon registró un intento de explotación en su red de honeypots (MadPot) el 17 de octubre, cuatro días antes de la divulgación pública.
• watchTowr: en sus preguntas frecuentes sobre PHP2Shell, informó el 21 de octubre que observó explotación de los fallos en su red de honeypots.
• CISA (agencia de ciberseguridad de EE. UU.): en la alerta del 21 de octubre, dijo que no había observado explotación hasta ese momento, pero pidió actualizar de inmediato. Para quien no pueda actualizar, recomendó desconectar los sistemas en PHP hasta corregirlos. El NCSC del Reino Unido hizo la misma recomendación.

Cuando ya hay intentos registrados, incluso antes de la divulgación, y una alerta gubernamental que pide apagar lo que no se puede corregir, el tiempo entre "posible" y "está ocurriendo" suele ser de días. Trátelo como una emergencia.

Por qué GLPI está en la línea de fuego

GLPI es una aplicación PHP clásica: servidor web, PHP y base de datos. Toda petición a GLPI pasa por PHP, incluidas las que llegan antes del inicio de sesión. Y GLPI suele tener más puertas abiertas a internet de lo que parece:

Como el ataque ocurre antes de que se ejecute el código de GLPI, cualquiera de estas URL sirve de puerta. Da igual que la API exija token o que el portal exija inicio de sesión: la petición maliciosa ni siquiera llega a verificarse.

Y lo que hay detrás de esa puerta es sensible. El servidor de GLPI guarda el acceso a la base de datos con todos los tickets, adjuntos, datos de usuarios e inventario de la empresa. En la carpeta config están la contraseña de la base de datos y la clave que protege las contraseñas guardadas en GLPI (recolector de correo, LDAP, SMTP). Quien ejecuta código en el servidor tiene todo eso a su alcance.

Tres trampas comunes

• Actualizar GLPI no actualiza PHP. Si acaba de pasar a GLPI 12, no está protegido automáticamente: GLPI 12 exige PHP 8.3, pero funciona con una 8.3 anterior a la corrección.
• El número de versión puede engañar. Ubuntu suele aplicar la corrección en el paquete y mantener el número (la 24.04 muestra 8.3.6 aun estando actualizada). Debian a veces hace lo mismo y a veces sube a la versión nueva. Un número "antiguo" no prueba que el servidor sea vulnerable, y un paquete nuevo no prueba que el servicio se haya reiniciado. Esta vez Debian sí subió el número (8.4.27 en Debian 13 y 8.2.35 en Debian 12): allí, un número antiguo indica un paquete sin corregir.
• PHP 8.1 en GLPI 10 es la combinación más arriesgada: PHP sin versión corregida oficial y GLPI sin soporte. Consulte la sección sobre PHP 8.1 más abajo.

Paso 1: averigüe dónde tiene PHP

La CISA empieza su recomendación por aquí: inventariar todos los sistemas con PHP. GLPI es solo uno de ellos. También suelen aparecer el sitio web de la empresa, la intranet, Zabbix, phpMyAdmin, Moodle, el antiguo sistema de tickets que nadie apagó.

Use el propio GLPI para ello

Si usa GLPI Agent, el inventario de software ya sabe dónde hay PHP:

1. Vaya a Activos > Software y busque php.
2. Abra elementos como php8.3-fpm, php8.3-common, libapache2-mod-php8.3 o php-fpm, según la distribución.
3. En la pestaña de instalaciones, vea en qué equipos está instalada cada versión.

La versión que muestra el agente es la del paquete, con el sufijo de la distribución (por ejemplo, 8.3.6-0ubuntu0.24.04.x). Es exactamente lo que necesita comparar con el aviso de seguridad de la distribución. El inventario no ve el PHP dentro de contenedores Docker ni el PHP descomprimido en Windows o en XAMPP.

Compruebe el PHP que atiende a GLPI

El PHP de línea de comandos puede ser distinto del que atiende el sitio. Para ver el que importa:

• En GLPI: en Configuración > General > Sistema, la sección del servidor muestra la versión de PHP que usa GLPI.
• En el servidor: vea qué servicio está en ejecución y qué versión usa.

php -v
systemctl list-units --type=service | grep -Ei 'php|apache|httpd'
sudo php-fpm8.3 -v

Sustituya 8.3 por la versión que aparezca en la lista de servicios. En Red Hat y derivados, use sudo php-fpm -v.

Paso 2: actualice según su escenario

Ubuntu y Debian con el PHP de la propia distribución

Las distribuciones reciben las correcciones antes de la divulgación pública y publican los paquetes en sus avisos de seguridad (en Ubuntu, el USN-8948-1, del 21/10; en Debian, el DSA-6574-1 y el DLA-4848-1). En Ubuntu, el número principal no cambia; compruébelo por el paquete:

sudo apt-get update
apt-cache policy php8.3-fpm
sudo apt-get install --only-upgrade 'php8.3*'
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

El último comando lee el changelog del paquete instalado y debe mostrar CVE-2026-109618 y CVE-2026-109619. Si las actualizaciones automáticas de seguridad están activadas, el paquete puede haber llegado ya; aun así, el servicio solo usa el código nuevo después de reiniciarse.

Versiones de referencia por distribución:

PHP de repositorio de terceros (ondrej/php, sury.org) o panel de hosting

Estos paquetes llevan el número de la versión oficial (por ejemplo, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 en Ubuntu), así que la comprobación es directa. Las actualizaciones automáticas de la distribución normalmente no cubren estos repositorios, y lo mismo vale para los paneles que instalan el PHP de sury, como CloudPanel:

sudo apt update && sudo apt upgrade
php -v

En paneles como cPanel, Plesk o aaPanel, use la actualización de PHP del propio panel y compruebe la versión de cada sitio.

Red Hat, Rocky, AlmaLinux y Oracle Linux

sudo dnf check-update 'php*'
sudo dnf update 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

En el PHP del propio Red Hat (módulos de AppStream), el número tampoco cambia: lo que vale es el changelog. Si el PHP viene del repositorio Remi, la actualización llega con el número de la versión oficial (8.2 a 8.5, en RHEL 8, 9 y 10): compruébelo con php -v. El día de la divulgación Remi aún no tenía los paquetes y sus espejos estaban saturados: si dnf no ofrece la actualización, ejecute sudo dnf upgrade --refresh 'php*', que ignora la caché, y vuelva a intentarlo unos minutos después. En Remi en modo SCL, el servicio se llama, por ejemplo, php83-php-fpm.

Docker

El contenedor no se actualiza solo, y reiniciar el contenedor antiguo no cambia el PHP. Hay que descargar la imagen nueva y recrearlo. Antes, haga una copia de seguridad de la base de datos y confirme que la carpeta de archivos, la carpeta config y la base de datos están en volúmenes (docker inspect <container> --format '{{json .Mounts}}'); si no, recrear el contenedor borra los datos. Si la imagen usa la etiqueta latest, el pull puede traer otra versión de GLPI: fije la etiqueta. En docker compose, indique el servicio de GLPI (glpi en los comandos de abajo): sin el nombre, el pull descarga también la imagen de la base de datos, y con mariadb:latest eso puede traer una versión mayor de la base de datos.

docker compose pull glpi
docker compose build --pull glpi
docker compose up -d glpi
docker exec <container-do-glpi> php -v

Si usa la imagen oficial glpi/glpi, ya salió con el PHP corregido: el 22/10, todas las etiquetas (latest, 12.0.0, 11.0.11, 10.0.28 y las nightly) traían PHP 8.5.12, así que basta con el pull. Usa Apache con mod_php, el escenario de mayor riesgo, un motivo más para no aplazarlo. Si su imagen se construye a partir de una imagen oficial de PHP (por ejemplo, php:8.3-fpm o php:8.3-apache), las etiquetas corregidas salieron a lo largo del 21/10 y las de FrankenPHP en la madrugada del 22/10 (UTC); un pull hecho antes trajo la versión vulnerable. Dos precauciones: el apt upgrade dentro del Dockerfile no actualiza el PHP de estas imágenes, que se compila aparte; y la etiqueta flotante puede traer más que el PHP (el servidor web de la imagen también puede cambiar de versión). Antes de recrear, guarde la imagen actual para poder volver atrás: docker tag "$(docker inspect --format '{{.Image}}' <contenedor-de-glpi>)" glpi-antes-del-parche.

Windows (IIS, XAMPP, WampServer)

Descargue la versión corregida de su rama desde el sitio oficial de PHP para Windows y sustituya la carpeta de PHP, conservando su php.ini. Paquetes listos como XAMPP suelen tardar en publicar la versión nueva; no los espere. Después, reinicie IIS o Apache.

Paso 3: reinicie y compruebe

Actualizar el paquete no basta. Los procesos que ya estaban en ejecución siguen con el código antiguo cargado en memoria hasta que se reinician:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

En Red Hat y derivados, los servicios suelen llamarse php-fpm y httpd. Después de reiniciar:

1. Abra Configuración > General > Sistema en GLPI y compruebe la versión de PHP.
2. Ejecute php -v en el servidor y compruebe también PHP-FPM (sudo php-fpm8.3 -v).
3. Con PHP de sury, de Remi, de imagen Docker oficial o de Windows, GLPI debe mostrar la versión corregida. Si muestra la antigua, todavía hay un proceso viejo en ejecución o un segundo PHP instalado.
4. Con el PHP de la propia distribución, el número puede no cambiar. Compruebe el paquete (dpkg -l 'php8.3*' o rpm -q php-fpm) y si el servicio se reinició después de la instalación: systemctl status php8.3-fpm muestra la hora en "active since". En Ubuntu, sudo needrestart -r l lista lo que todavía se ejecuta con código antiguo; en Red Hat, sudo dnf needs-restarting -s.

Pruebe GLPI antes de darlo por terminado

Una actualización de PHP rara vez rompe GLPI, pero vale la regla de cualquier cambio en producción: si puede, aplíquela primero en una copia de preproducción y, en cualquier caso, haga una copia de seguridad antes. Después de actualizar, compruebe en pocos minutos los flujos que no pueden detenerse:

1. Inicio de sesión, también por LDAP o por inicio de sesión único (SSO), si lo usa.
2. Apertura de tickets por el portal de autoservicio y por formulario.
3. Recolector de correo: envíe un correo de prueba y compruebe si se convierte en ticket.
4. Notificaciones: compruebe que GLPI sigue enviando correos.
5. Acciones automáticas: en Configuración > Acciones automáticas, compruebe que las tareas siguen ejecutándose.
6. API e integraciones: inventario de los agentes, chatbots, ERP y automatizaciones que llaman a GLPI.
7. Plugins: abra las pantallas de los plugins que más usa el equipo.

¿Y si no puede actualizar ahora?

• Retire GLPI de internet hasta corregirlo. Deje el acceso solo por la red interna o por VPN. Si el portal de autoservicio tiene que seguir abierto, esa es la prioridad número uno de la actualización, no el motivo para aplazarla.
• Restrinja lo que deba seguir abierto, antes de PHP. Haga la restricción en el firewall o en el servidor web (allow/deny en Nginx, Require ip en Apache), nunca en las opciones del propio GLPI, que solo se ejecutan después de PHP. Y recuerde: restringir solo el inventario y la API sirve de poco si la pantalla de inicio de sesión sigue abierta.
• Desactive el progreso de subida de la sesión (session.upload_progress.enabled = Off), como recomendó PHP. Esto cierra el CVE-2026-115560 y reduce la exposición al CVE-2026-109619, pero no sustituye la actualización.
• Use un firewall de aplicaciones web (WAF) como puente. Cloudflare publicó reglas iniciales para los vectores conocidos. Ayuda, pero no corrige: la propia AWS advirtió que ningún cambio de configuración es una mitigación completa. Las reglas están disponibles también en el plan gratuito de Cloudflare.
• Aumente la vigilancia. Esté atento a procesos de PHP que abran una shell o descarguen archivos, que es la señal que la CISA pide vigilar.

Paso 4: compruebe si alguien ya ha entrado

Antes de nada, un alivio: haber ejecutado una versión vulnerable no prueba que haya habido una intrusión ni una fuga de datos. Es solo el motivo para revisar. El intento más antiguo registrado es del 17 de octubre. Si su GLPI estuvo expuesto con PHP vulnerable en ese periodo, merece la pena una comprobación rápida después de corregir. Ninguno de estos comandos modifica nada.

Archivos PHP donde no debería haberlos. La carpeta de datos de GLPI guarda adjuntos, imágenes y temporales; ahí no debería aparecer ningún archivo .php, con excepción de la caché (_cache) y de las clases generadas por plugins como Campos adicionales (Fields) y GenericObject, en files/_plugins/fields y files/_plugins/genericobject. Estos aparecen en el resultado y son esperables si las fechas coinciden con cambios que usted hizo:

sudo find /var/lib/glpi/files /var/www/glpi/files -name '*.php' -not -path '*/_cache/*' 2>/dev/null
sudo find /var/www/glpi -type f -name '*.php' -newerct '2026-10-15' -not -path '*/files/_cache/*' 2>/dev/null

La segunda búsqueda usa la fecha de cambio del archivo en el sistema (ctime), que un intruso no puede maquillar con touch. Ajuste las rutas a su instalación. Los archivos de plugins y de GLPI que usted actualizó en el periodo son esperables; lo preocupante es lo que nadie recuerda haber puesto ahí.

Procesos y conexiones del usuario del servidor web:

ps -eo user,pid,ppid,lstart,cmd | grep -E '^(www-data|apache|nginx)' | grep -Ev 'php-fpm|apache2|httpd|nginx'
sudo ss -tnp | grep -E 'php|apache|httpd|"(sh|bash|dash|nc|ncat|perl|python[0-9.]*)"'
sudo crontab -u www-data -l

En Red Hat, el usuario es apache (crontab -u apache -l). El usuario del servidor web no debería estar ejecutando sh, bash, curl, wget o nc, ni tener una tarea programada que usted no creó (la tarea del cron.php de GLPI es legítima). Desconfíe de conexiones salientes hacia IP que no sean la base de datos, el LDAP, el SMTP o sus integraciones.

Cuentas y plugins nuevos en GLPI. En Administración > Usuarios, añada la columna Fecha de creación (icono de columnas), ordene por ella y compruebe si ha aparecido alguna cuenta desconocida desde el 17 de octubre, sobre todo con perfil Super-Admin. Revise también Administración > Perfiles (cambios de permisos), Configuración > Complementos (¿algún plugin que usted no instaló?) y los clientes de la API.

Registros del servidor web y de PHP. Los picos de peticiones extrañas, desde IP desconocidas, seguidos de errores 500, merecen atención, sobre todo en las URL de la tabla anterior. En el registro de PHP-FPM, las secuencias de "Allowed memory size exhausted" y los procesos terminados por señal (por ejemplo, "exited on signal 11") también merecen un vistazo.

Si encuentra señales de intrusión

1. Aísle el servidor de la red, sin apagarlo, para preservar las evidencias.
2. Guarde los registros y una copia del disco antes de cualquier limpieza.
3. Reconstruya a partir de una base limpia y restaure los datos de una copia de seguridad anterior a la intrusión, evaluando lo que haya que rehacer después de esa fecha. Limpiar solo el archivo encontrado no garantiza que no haya quedado otra puerta.
4. Cambie todos los secretos que guardaba el servidor, solo después de aislarlo y reconstruirlo. Si el atacante sigue en el entorno, las contraseñas nuevas se filtran junto con las antiguas. El orden es: contener, limpiar y solo entonces cambiar:
5. la contraseña de la base de datos, que está en config/config_db.php (o en /etc/glpi/ en instalaciones por paquete);
6. la clave glpicrypt.key, que protege las contraseñas guardadas en GLPI: genere una nueva con php bin/console glpi:security:change_key, que vuelve a cifrar los datos (cambiar el archivo a mano deja los secretos ilegibles), y después cambie las propias contraseñas: recolectores de correo, cuenta de lectura del LDAP, SMTP y proxy;
7. las contraseñas de los administradores locales de GLPI, porque los hashes estaban en la base de datos;
8. los tokens de la API (de aplicación y de usuarios) y los secretos de OAuth;
9. las credenciales de las integraciones a las que llama GLPI (ERP, chatbot, automatizaciones).
10. Evalúe la notificación: si pueden haberse accedido datos personales, involucre al delegado de protección de datos (DPO) y al departamento jurídico. La LGPD brasileña (art. 48) prevé comunicar a la ANPD y a los titulares cuando el incidente puede causar un riesgo o daño relevante, y el reglamento de la ANPD fija un plazo corto para ello (fuera de Brasil, rige la normativa local de protección de datos, por ejemplo el RGPD en Europa).

PHP 8.1 o anterior: el problema es mayor

PHP 8.1 y las versiones anteriores ya no tienen soporte del proyecto PHP y por eso no reciben la versión corregida oficial. El propio equipo de PHP publicó correcciones mínimas en código fuente para 7.4, 8.0 y 8.1: si compila PHP usted mismo, puede aplicarlas; si no, depende de que su proveedor o distribución publique el paquete. PHP 5 y 7.0 a 7.3 no tienen ninguna corrección (es el caso de quien todavía usa GLPI 9.5). En Ubuntu 22.04, por ejemplo, PHP 8.1 lo mantiene la propia Canonical: el USN-8948-1, del 21/10, ya incluye la corrección. Sury y el PPA ondrej/php también mantienen paquetes de 7.4 a 8.1; compruebe si ya incluyen la corrección. Si GLPI está en un hosting gestionado, pida al proveedor un paquete con la corrección de los dos fallos o un plan prioritario de migración a una versión con soporte, con fecha.

Quien todavía ejecuta PHP 8.1 normalmente también está en GLPI 10, que perdió el soporte con la llegada de GLPI 12. GLPI 11 exige PHP 8.2 o posterior, y GLPI 12 exige la 8.3. Si es su caso, corregir este fallo y salir de GLPI 10 se han convertido en el mismo proyecto: consulte los riesgos de seguir en GLPI 10 y la hoja de ruta para migrar.

Después de la corrección: que el próximo susto sea menor

• Retire de internet lo que no necesita estar ahí. Inventario solo desde las IP de los agentes, API solo desde los servidores que la usan, área de administración solo por VPN, siempre con la regla en el firewall o en el servidor web.
• Oculte la versión de PHP. Con expose_php = Off en el php.ini, el servidor deja de anunciar la versión en la cabecera de respuesta. Eso reduce el escaneo automático, pero no protege: el ataque no depende de conocer la versión.
• Active las actualizaciones automáticas de seguridad de la distribución, y recuerde que no cubren repositorios de terceros ni imágenes Docker.
• Tenga una copia de seguridad probada de la base de datos y de la carpeta de archivos de GLPI. Restaurar es el plan B de todo fallo crítico.
• Siga los fallos de su entorno. CVE Scan es gratuito: verifica la versión de GLPI y de PHP, las cabeceras de seguridad y los permisos, y muestra qué corregir primero.

Cronología

Lista de verificación de hoy

1. Listar todos los servidores con PHP, no solo el de GLPI (el inventario de GLPI ayuda).
2. Comprobar la versión en Configuración > General > Sistema y el paquete en el servidor.
3. Actualizar, empezando por lo que está expuesto en internet.
4. Reiniciar PHP-FPM o Apache y volver a comprobar.
5. Si no puede actualizar hoy, retirar el acceso externo.
6. Ejecutar las comprobaciones de intrusión y guardar el resultado.
7. Restringir inventario, API y área de administración a lo necesario.
8. Desactivar session.upload_progress.enabled en el php.ini o en el pool de PHP-FPM, reiniciar y comprobar.

¿Necesita ayuda para actualizar el servidor de GLPI o revisar la exposición de su entorno? Hable con nosotros.

Fuentes: avisos de seguridad de PHP del 21 y 23/10/2026, alerta de la CISA (21/10/2026), changelog oficial de PHP (php.net), boletín de seguridad de AWS, artículo de Help Net Security sobre PHP2Shell, FAQ de watchTowr, aviso de Ubuntu (USN-8948-1), rastreador de seguridad de Debian y aviso de Mercado Pago a los desarrolladores (21/10/2026). GLPI es una marca registrada de Teclib'. NexTool no está afiliada a Teclib'.