NexTool Solutions

Deux failles critiques dans PHP lui-même, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), permettent d'exécuter du code sur le serveur au moyen de requêtes sans authentification, avant même que le code de l'application ne s'exécute. Elles touchent toute installation de PHP qui traite des requêtes web, et GLPI fonctionne sous PHP. Le correctif se trouve dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Ce guide explique ce que sont ces failles, pourquoi GLPI est en première ligne, comment savoir où vous avez du PHP, comment corriger dans chaque scénario, comment savoir si quelqu'un est déjà entré et quoi faire ensuite.

Ce guide s'appuie sur les informations publiques disponibles le 22 octobre 2026. Les avis de sécurité évoluent vite : consultez aussi l'avis de votre fournisseur ou de votre distribution avant d'agir.

Mise à jour : le 23 octobre 2026, PHP a divulgué une troisième faille, la CVE-2026-115560, encore sans correctif. Consultez ce qui change et la configuration qui protège.

Résumé pour ceux qui ont cinq minutes

Mise à jour du 23/10 : une troisième faille, CVE-2026-115560

Le 23 octobre, le projet PHP a publié un avis sur une troisième faille d'exécution de code à distance, la CVE-2026-115560, liée à la fonction de progression de l'upload des sessions (session upload progress). Elle est différente des deux failles de PHP2Shell, et les versions des 21 et 22 octobre ne la corrigent pas. Le correctif arrivera avec la prochaine version régulière de PHP, encore sans date, et l'avis complet sera publié en même temps.

Le chemin d'attaque est bien plus étroit que celui de PHP2Shell. Il n'existe que lorsque trois conditions sont réunies :

1. le php.ini définit session.serialize_handler à php_binary ou php_serialize ;
2. l'application remplace cette valeur par php pendant l'exécution, avec ini_set(), avant d'ouvrir la session ;
3. la progression de l'upload de session est activée, ce qui est le réglage par défaut de PHP.

GLPI ne fait pas ce changement. Nous avons vérifié le code de GLPI 10, 11 et 12 : il ne modifie pas le serialize_handler et n'utilise pas la progression de l'upload de session. Un serveur qui n'exécute que GLPI, avec la configuration par défaut de PHP, n'est pas exposé par ce chemin. Le risque apparaît lorsque le même PHP sert d'autres applications, comme un site, une boutique ou un ancien système, que vous ne pouvez pas auditer.

Malgré tout, la recommandation est de désactiver la fonction dès maintenant. PHP lui-même l'avait déjà suggéré le 21 octobre comme mesure d'atténuation pour la CVE-2026-109619, et GLPI n'y perd rien :

session.upload_progress.enabled = Off

Ajoutez la ligne dans le php.ini du PHP qui sert le web ou dans le pool PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off), puis redémarrez PHP-FPM ou Apache. La configurer dans le code, avec ini_set(), ou dans un fichier .user.ini ne protège pas. Où se trouve le fichier dans chaque scénario :

Pour vérifier sur le serveur, utilisez PHP-FPM et non le PHP en ligne de commande, qui lit un autre fichier :

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

Le résultat attendu est Off. Si un pool contient la ligne avec on, elle l'emporte sur le php.ini.

Astuce : ce réglage ne remplace pas la mise à jour pour les failles du 21 octobre. Il ferme seulement la nouvelle faille en attendant le correctif. Quand PHP publiera la prochaine version, mettez de nouveau à jour.

Ce qui s'est passé

Le projet PHP a publié des correctifs de sécurité pour deux failles d'exécution de code à distance dans le cœur du langage. Dans le changelog officiel, les correctifs apparaissent sous l'intitulé "Avoid state corruption via bailout" (GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp). Des sources spécialisées citent un score de 9,2 sur l'échelle CVSS 4.0, ce qui les place dans la catégorie critique. Certaines sources citent 9,8 sur l'échelle CVSS 3.1 du NVD.

En termes simples :

• CVE-2026-109618 : une condition de mémoire insuffisante peut interrompre PHP au milieu d'une requête, alors que des données internes ne sont que partiellement initialisées. Lors du nettoyage de la requête, PHP traite alors ces données invalides comme valides.
• CVE-2026-109619 : un état interne d'une requête peut subsister après la libération de sa mémoire. La requête suivante, traitée par le même processus, peut utiliser cet état avant qu'il soit réinitialisé.

Les deux cas sont des problèmes de gestion de la mémoire au sein de l'interpréteur, et c'est ce qui les rend graves. D'après les analyses publiées, une seule requête non authentifiée peut déclencher l'attaque avant que le moindre code de l'application ne s'exécute. Autrement dit : l'écran de connexion de GLPI, les droits des profils et les règles de l'application ne sont même pas consultés.

Quelles installations sont exposées

Toutes les façons d'exécuter PHP pour le web figurent dans les avis : PHP-FPM (le plus courant avec Nginx et avec un Apache moderne), Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les analyses désignent mod_php comme le scénario le plus risqué.

Le PHP en ligne de commande (CLI), qui exécute les actions automatiques de GLPI via cron, ne traite pas de requêtes web. Il est généralement dans la même version et mis à jour en même temps.

Il n'y a pas que GLPI

La faille se trouve dans PHP, pas dans une application. C'est pourquoi tout système en PHP qui sert le web est exposé, et le correctif est le même pour tous : mettre PHP à jour et redémarrer le service. Mettre à jour WordPress, GLPI ou un plugin ne règle pas le problème.

L'alerte ne s'est pas limitée aux professionnels de l'informatique : Mercado Pago, par exemple, a demandé aux commerçants qui utilisent WooCommerce, PrestaShop et Adobe Commerce (Magento) de vérifier le PHP de leurs boutiques.

En pratique, la personne qui s'occupe de GLPI s'occupe presque toujours aussi d'autres serveurs PHP : le site de l'entreprise, l'intranet, la supervision, l'ancien système que personne n'a éteint. Corriger uniquement GLPI laisse la porte ouverte sur le serveur d'à côté. À l'étape 1, nous montrons comment utiliser l'inventaire de GLPI lui-même pour tous les retrouver.

Les failles sont-elles déjà exploitées ?

Les sources divergent, et cela ne change pas la recommandation :

• Amazon : selon Help Net Security, l'équipe de renseignement sur les menaces d'Amazon a enregistré une tentative d'exploitation sur son réseau de honeypots (MadPot) le 17 octobre, quatre jours avant la divulgation publique.
• watchTowr : dans sa FAQ sur PHP2Shell, elle a indiqué le 21 octobre avoir observé l'exploitation des failles sur son réseau de honeypots.
• CISA (agence de cybersécurité des États-Unis) : dans son alerte du 21 octobre, elle a déclaré ne pas avoir observé d'exploitation jusque-là, mais a demandé une mise à jour immédiate. Pour ceux qui ne peuvent pas mettre à jour, elle a recommandé de mettre hors ligne les systèmes PHP jusqu'à leur correction. Le NCSC britannique a fait la même recommandation.

Quand des tentatives ont déjà été enregistrées, y compris avant la divulgation, et qu'une alerte gouvernementale demande d'éteindre ce qui ne peut pas être corrigé, le délai entre "possible" et "en cours" se compte généralement en jours. Traitez cela comme une urgence.

Pourquoi GLPI est en première ligne

GLPI est une application PHP classique : serveur web, PHP et base de données. Toute requête vers GLPI passe par PHP, y compris celles qui arrivent avant la connexion. Et GLPI a souvent plus de portes ouvertes sur internet qu'il n'y paraît :

Comme l'attaque a lieu avant l'exécution du code de GLPI, n'importe laquelle de ces URL peut servir de porte. Peu importe que l'API exige un jeton ou que le portail exige une connexion : la requête malveillante n'est même pas vérifiée.

Et ce qui se trouve derrière cette porte est sensible. Le serveur GLPI détient l'accès à la base de données contenant tous les tickets, pièces jointes, données des utilisateurs et l'inventaire de l'entreprise. Le dossier config contient le mot de passe de la base et la clé qui protège les mots de passe stockés dans GLPI (collecteur de courriels, LDAP, SMTP). Quiconque exécute du code sur le serveur a tout cela à portée de main.

Trois pièges courants

• Mettre à jour GLPI ne met pas à jour PHP. Si vous venez de passer à GLPI 12, vous n'êtes pas automatiquement protégé : GLPI 12 exige PHP 8.3, mais il fonctionne avec une 8.3 antérieure au correctif.
• Le numéro de version peut tromper. Ubuntu applique généralement le correctif au paquet et conserve le numéro (la 24.04 affiche 8.3.6 même à jour). Debian fait parfois de même et passe parfois à la nouvelle version. Un numéro "ancien" ne prouve pas que le serveur est vulnérable, et un paquet récent ne prouve pas que le service a été redémarré. Cette fois, Debian a bien changé le numéro (8.4.27 sous Debian 13, 8.2.35 sous Debian 12) : là, un numéro ancien signale un paquet non corrigé.
• PHP 8.1 sous GLPI 10 est la combinaison la plus risquée : un PHP sans version corrigée officielle et un GLPI sans support. Consultez la section sur PHP 8.1 plus bas.

Étape 1 : identifiez où vous avez du PHP

La CISA commence sa recommandation par là : inventorier tous les systèmes équipés de PHP. GLPI n'est que l'un d'eux. On y trouve souvent aussi le site de l'entreprise, l'intranet, Zabbix, phpMyAdmin, Moodle, l'ancien outil de tickets que personne n'a éteint.

Utilisez GLPI lui-même pour cela

Si vous utilisez GLPI Agent, l'inventaire logiciel sait déjà où se trouve PHP :

1. Allez dans Parc > Logiciels et recherchez php.
2. Ouvrez les éléments comme php8.3-fpm, php8.3-common, libapache2-mod-php8.3 ou php-fpm, selon la distribution.
3. Dans l'onglet des installations, voyez sur quels ordinateurs chaque version est installée.

La version affichée par l'agent est celle du paquet, avec le suffixe de la distribution (par exemple, 8.3.6-0ubuntu0.24.04.x). C'est exactement ce que vous devez comparer avec l'avis de sécurité de la distribution. L'inventaire ne voit ni le PHP à l'intérieur des conteneurs Docker, ni le PHP décompressé sous Windows ou dans XAMPP.

Vérifiez le PHP qui sert GLPI

Le PHP en ligne de commande peut être différent de celui qui sert le site. Pour voir celui qui compte :

• Dans GLPI : dans Configuration > Générale > Système, la section du serveur indique la version de PHP utilisée par GLPI.
• Sur le serveur : regardez quel service tourne et quelle version il utilise.

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

Remplacez 8.3 par la version qui apparaît dans la liste des services. Sous Red Hat et dérivés, utilisez sudo php-fpm -v.

Étape 2 : mettez à jour selon votre scénario

Ubuntu et Debian avec le PHP de la distribution

Les distributions reçoivent les correctifs avant la divulgation publique et publient les paquets dans leurs avis de sécurité (pour Ubuntu, l'USN-8948-1 du 21/10 ; pour Debian, le DSA-6574-1 et le DLA-4848-1). Sous Ubuntu, le numéro principal ne change pas ; vérifiez par le paquet :

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]'

La dernière commande lit le changelog du paquet installé et doit afficher CVE-2026-109618 et CVE-2026-109619. Si les mises à jour de sécurité automatiques sont activées, le paquet est peut-être déjà arrivé ; même dans ce cas, le service n'utilise le nouveau code qu'après avoir été redémarré.

Versions de référence par distribution :

PHP d'un dépôt tiers (ondrej/php, sury.org) ou d'un panneau d'hébergement

Ces paquets portent le numéro de la version officielle (par exemple, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 sous Ubuntu), la vérification est donc directe. Les mises à jour automatiques de la distribution ne couvrent normalement pas ces dépôts, et il en va de même pour les panneaux qui installent le PHP de sury, comme CloudPanel :

sudo apt update && sudo apt upgrade
php -v

Dans des panneaux comme cPanel, Plesk ou aaPanel, utilisez la mise à jour de PHP du panneau lui-même et vérifiez la version de chaque site.

Red Hat, Rocky, AlmaLinux et Oracle Linux

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

Avec le PHP de Red Hat lui-même (modules AppStream), le numéro ne change pas non plus : c'est le changelog qui fait foi. Si PHP provient du dépôt Remi, la mise à jour arrive avec le numéro de la version officielle (8.2 à 8.5, sous RHEL 8, 9 et 10) : vérifiez avec php -v. Le jour de la divulgation, Remi n'avait pas encore les paquets et ses miroirs étaient saturés : si dnf ne propose pas la mise à jour, lancez sudo dnf upgrade --refresh 'php*', qui ignore le cache, et réessayez quelques minutes plus tard. Avec Remi en mode SCL, le service s'appelle par exemple php83-php-fpm.

Docker

Le conteneur ne se met pas à jour tout seul, et redémarrer l'ancien conteneur ne remplace pas PHP. Il faut télécharger la nouvelle image et recréer le conteneur. Au préalable, sauvegardez la base de données et vérifiez que le dossier des fichiers, le dossier config et la base sont sur des volumes (docker inspect <container> --format '{{json .Mounts}}') ; sinon, recréer le conteneur efface les données. Si l'image utilise le tag latest, le pull peut amener une autre version de GLPI : fixez le tag. Avec docker compose, nommez le service GLPI (glpi dans les commandes ci-dessous) : sans ce nom, le pull télécharge aussi l'image de la base de données, et avec mariadb:latest cela peut entraîner une montée de version majeure de la base.

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

Si vous utilisez l'image officielle glpi/glpi, elle est déjà sortie avec le PHP corrigé : le 22/10, tous les tags (latest, 12.0.0, 11.0.11, 10.0.28 et les nightly) embarquaient PHP 8.5.12, un pull suffit donc. Elle utilise Apache avec mod_php, le scénario le plus risqué, une raison de plus de ne pas attendre. Si votre image est construite à partir d'une image officielle de PHP (par exemple, php:8.3-fpm ou php:8.3-apache), les tags corrigés sont sortis au cours du 21/10 et ceux de FrankenPHP tôt le 22/10 (UTC) ; un pull fait avant cela a récupéré la version vulnérable. Deux précautions : l'apt upgrade dans le Dockerfile ne met pas à jour le PHP de ces images, compilé à part ; et le tag flottant peut apporter plus que PHP (le serveur web de l'image peut aussi changer de version). Avant de recréer, conservez l'image actuelle pour pouvoir revenir en arrière : docker tag "$(docker inspect --format '{{.Image}}' <conteneur-glpi>)" glpi-avant-correctif.

Windows (IIS, XAMPP, WampServer)

Téléchargez la version corrigée de votre branche sur le site officiel de PHP pour Windows et remplacez le dossier de PHP en conservant votre php.ini. Les paquets tout-en-un comme XAMPP mettent souvent du temps à publier la nouvelle version ; ne les attendez pas. Redémarrez ensuite IIS ou Apache.

Étape 3 : redémarrez et vérifiez

Mettre à jour le paquet ne suffit pas. Les processus déjà en cours d'exécution gardent l'ancien code chargé en mémoire jusqu'à leur redémarrage :

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

Sous Red Hat et dérivés, les services s'appellent généralement php-fpm et httpd. Après le redémarrage :

1. Ouvrez Configuration > Générale > Système dans GLPI et vérifiez la version de PHP.
2. Exécutez php -v sur le serveur et vérifiez aussi PHP-FPM (sudo php-fpm8.3 -v).
3. Avec le PHP de sury, de Remi, d'une image Docker officielle ou de Windows, GLPI doit afficher la version corrigée. S'il affiche l'ancienne, un ancien processus tourne encore ou un second PHP est installé.
4. Avec le PHP de la distribution, le numéro peut ne pas changer. Vérifiez le paquet (dpkg -l 'php8.3*' ou rpm -q php-fpm) et si le service a été redémarré après l'installation : systemctl status php8.3-fpm indique l'heure dans "active since". Sous Ubuntu, sudo needrestart -r l liste ce qui tourne encore avec l'ancien code ; sous Red Hat, sudo dnf needs-restarting -s.

Testez GLPI avant de considérer le travail terminé

Une mise à jour de PHP casse rarement GLPI, mais la règle de tout changement en production s'applique : si possible, appliquez-la d'abord sur une copie de préproduction et, dans tous les cas, faites une sauvegarde avant. Après la mise à jour, vérifiez en quelques minutes les fonctions qui ne peuvent pas s'arrêter :

1. Connexion, y compris via LDAP ou l'authentification unique (SSO), si vous les utilisez.
2. Création de tickets via le portail en libre-service et via les formulaires.
3. Collecteur de courriels : envoyez un courriel de test et vérifiez qu'il devient un ticket.
4. Notifications : vérifiez que GLPI continue d'envoyer des courriels.
5. Actions automatiques : dans Configuration > Actions automatiques, vérifiez que les tâches continuent de s'exécuter.
6. API et intégrations : inventaire des agents, chatbots, ERP et automatisations qui appellent GLPI.
7. Plugins : ouvrez les écrans des plugins que l'équipe utilise le plus.

Et si vous ne pouvez pas mettre à jour maintenant ?

• Retirez GLPI d'internet jusqu'à la correction. Ne laissez l'accès que par le réseau interne ou par VPN. Si le portail en libre-service doit rester ouvert, c'est la priorité numéro un de la mise à jour, pas une raison de la reporter.
• Restreignez ce qui doit rester ouvert, en amont de PHP. Faites la restriction dans le pare-feu ou le serveur web (allow/deny dans Nginx, Require ip dans Apache), jamais dans les options de GLPI lui-même, qui ne s'exécutent qu'après PHP. Et rappelez-vous : restreindre seulement l'inventaire et l'API sert à peu de chose si l'écran de connexion reste ouvert.
• Désactivez la progression de l'upload de session (session.upload_progress.enabled = Off), comme PHP l'a recommandé. Cela ferme la CVE-2026-115560 et réduit l'exposition à la CVE-2026-109619, mais ne remplace pas la mise à jour.
• Utilisez un pare-feu applicatif web (WAF) comme solution transitoire. Cloudflare a publié des règles initiales pour les vecteurs connus. Cela aide, mais ne corrige pas : AWS a d'ailleurs averti qu'aucune modification de configuration ne constitue une atténuation complète. Les règles sont aussi disponibles avec l'offre gratuite de Cloudflare.
• Renforcez la surveillance. Surveillez les processus PHP qui ouvrent un shell ou téléchargent des fichiers, c'est le signal que la CISA demande de surveiller.

Étape 4 : vérifiez si quelqu'un est déjà entré

Avant tout, de quoi vous rassurer : avoir fait tourner une version vulnérable ne prouve pas qu'il y a eu intrusion ou fuite de données. C'est seulement une raison de vérifier. La plus ancienne tentative enregistrée date du 17 octobre. Si votre GLPI a été exposé avec un PHP vulnérable pendant cette période, une vérification rapide après la correction vaut la peine. Aucune de ces commandes ne modifie quoi que ce soit.

Des fichiers PHP là où il ne devrait pas y en avoir. Le dossier de données de GLPI contient les pièces jointes, les images et les fichiers temporaires ; aucun fichier .php ne devrait y apparaître, à l'exception du cache (_cache) et des classes générées par des plugins comme Champs supplémentaires (Fields) et GenericObject, dans files/_plugins/fields et files/_plugins/genericobject. Ceux-ci apparaissent dans le résultat et sont normaux si les dates correspondent à des modifications que vous avez faites :

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 seconde recherche utilise la date de modification du fichier dans le système (ctime), qu'un attaquant ne peut pas maquiller avec touch. Adaptez les chemins à votre installation. Les fichiers de plugins et de GLPI que vous avez mis à jour pendant la période sont normaux ; ce qui doit inquiéter, c'est ce que personne ne se souvient d'avoir déposé.

Processus et connexions de l'utilisateur du serveur 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

Sous Red Hat, l'utilisateur est apache (crontab -u apache -l). L'utilisateur du serveur web ne devrait pas exécuter sh, bash, curl, wget ou nc, ni avoir de tâche planifiée que vous n'avez pas créée (la tâche du cron.php de GLPI est légitime). Méfiez-vous des connexions sortantes vers des IP autres que la base de données, le LDAP, le SMTP ou vos intégrations.

Nouveaux comptes et plugins dans GLPI. Dans Administration > Utilisateurs, ajoutez la colonne Date de création (icône des colonnes), triez sur cette colonne et vérifiez si un compte inconnu est apparu depuis le 17 octobre, en particulier avec le profil Super-Admin. Vérifiez aussi Administration > Profils (modifications de droits), Configuration > Plugins (un plugin que vous n'avez pas installé ?) et les clients de l'API.

Journaux du serveur web et de PHP. Des pics de requêtes étranges, provenant d'IP inconnues, suivis d'erreurs 500, méritent votre attention, surtout sur les URL du tableau ci-dessus. Dans le journal de PHP-FPM, les séquences de "Allowed memory size exhausted" et les processus terminés par un signal (par exemple, "exited on signal 11") méritent aussi un coup d'œil.

Si vous trouvez des signes d'intrusion

1. Isolez le serveur du réseau, sans l'éteindre, pour préserver les preuves.
2. Conservez les journaux et une copie du disque avant tout nettoyage.
3. Reconstruisez à partir d'une base saine et restaurez les données depuis une sauvegarde antérieure à l'intrusion, en évaluant ce qui doit être refait après cette date. Supprimer uniquement le fichier trouvé ne garantit pas qu'aucune autre porte n'a été laissée.
4. Changez tous les secrets que le serveur détenait, mais seulement après l'avoir isolé et reconstruit. Si l'attaquant est encore dans l'environnement, les nouveaux mots de passe fuiteront avec les anciens. L'ordre est : contenir, nettoyer et seulement ensuite changer :
5. le mot de passe de la base de données, qui se trouve dans config/config_db.php (ou dans /etc/glpi/ pour les installations par paquet) ;
6. la clé glpicrypt.key, qui protège les mots de passe stockés dans GLPI : générez-en une nouvelle avec php bin/console glpi:security:change_key, qui rechiffre les données (remplacer le fichier à la main rend les secrets illisibles), puis changez les mots de passe eux-mêmes : collecteurs de courriels, compte de lecture LDAP, SMTP et proxy ;
7. les mots de passe des administrateurs locaux de GLPI, car les hashes se trouvaient dans la base ;
8. les jetons de l'API (d'application et d'utilisateurs) et les secrets OAuth ;
9. les identifiants des intégrations que GLPI appelle (ERP, chatbot, automatisations).
10. Évaluez la notification : si des données personnelles ont pu être consultées, impliquez le délégué à la protection des données (DPO) et le service juridique. La LGPD brésilienne (art. 48) prévoit d'informer l'ANPD et les personnes concernées lorsque l'incident peut entraîner un risque ou un préjudice important, et le règlement de l'ANPD fixe un délai court pour cela (hors du Brésil, ce sont les règles locales de protection des données qui s'appliquent, par exemple le RGPD en Europe).

PHP 8.1 ou plus ancien : le problème est plus grave

PHP 8.1 et les versions antérieures ne sont plus supportés par le projet PHP et ne reçoivent donc pas la version corrigée officielle. L'équipe PHP elle-même a publié des correctifs minimaux en code source pour 7.4, 8.0 et 8.1 : si vous compilez PHP vous-même, vous pouvez les appliquer ; sinon, vous dépendez de la publication du paquet par votre fournisseur ou votre distribution. PHP 5 et 7.0 à 7.3 n'ont aucun correctif (c'est le cas de ceux qui utilisent encore GLPI 9.5). Sous Ubuntu 22.04, par exemple, PHP 8.1 est maintenu par Canonical elle-même : l'USN-8948-1 du 21/10 inclut déjà le correctif. Sury et le PPA ondrej/php maintiennent aussi des paquets de 7.4 à 8.1 ; vérifiez s'ils intègrent déjà le correctif. Si GLPI est sur un hébergement infogéré, demandez à l'hébergeur un paquet corrigeant les deux failles ou un plan de migration prioritaire vers une version supportée, avec une date.

Les environnements qui tournent encore en PHP 8.1 sont généralement aussi sous GLPI 10, qui a perdu son support avec l'arrivée de GLPI 12. GLPI 11 exige PHP 8.2 ou plus récent, et GLPI 12 exige la 8.3. Si c'est votre cas, corriger cette faille et quitter GLPI 10 sont devenus un seul et même projet : consultez les risques de rester sur GLPI 10 et la feuille de route pour migrer.

Après la correction : rendez la prochaine alerte moins grave

• Retirez d'internet ce qui n'a pas besoin d'y être. Inventaire uniquement depuis les IP des agents, API uniquement depuis les serveurs qui l'utilisent, zone d'administration uniquement par VPN, toujours avec la règle dans le pare-feu ou le serveur web.
• Masquez la version de PHP. Avec expose_php = Off dans le php.ini, le serveur cesse d'annoncer la version dans l'en-tête de réponse. Cela réduit le balayage automatisé, mais ne protège pas : l'attaque n'a pas besoin de connaître la version.
• Activez les mises à jour de sécurité automatiques de la distribution, en vous rappelant qu'elles ne couvrent ni les dépôts tiers ni les images Docker.
• Disposez d'une sauvegarde testée de la base de données et du dossier des fichiers de GLPI. La restauration est le plan B de toute faille critique.
• Suivez les failles de votre environnement. CVE Scan est gratuit : il vérifie la version de GLPI et de PHP, les en-têtes de sécurité et les permissions, et indique ce qu'il faut corriger en premier.

Chronologie

La checklist du jour

1. Lister tous les serveurs équipés de PHP, pas seulement celui de GLPI (l'inventaire de GLPI aide).
2. Vérifier la version dans Configuration > Générale > Système et le paquet sur le serveur.
3. Mettre à jour, en commençant par ce qui est exposé sur internet.
4. Redémarrer PHP-FPM ou Apache et vérifier à nouveau.
5. Si la mise à jour est impossible aujourd'hui, couper l'accès externe.
6. Lancer les vérifications d'intrusion et conserver le résultat.
7. Restreindre l'inventaire, l'API et la zone d'administration au strict nécessaire.
8. Désactiver session.upload_progress.enabled dans le php.ini ou dans le pool PHP-FPM, redémarrer et vérifier.

Besoin d'aide pour mettre à jour le serveur GLPI ou revoir l'exposition de votre environnement ? Parlez-nous.

Sources : avis de sécurité de PHP des 21 et 23/10/2026, alerte de la CISA (21/10/2026), changelog officiel de PHP (php.net), bulletin de sécurité d'AWS, article de Help Net Security sur PHP2Shell, FAQ de watchTowr, avis d'Ubuntu (USN-8948-1), suivi de sécurité de Debian et avis de Mercado Pago aux développeurs (21/10/2026). GLPI est une marque déposée de Teclib'. NexTool n'est pas affiliée à Teclib'.