NexTool Solutions

Due vulnerabilità critiche nello stesso PHP, soprannominate PHP2Shell (CVE-2026-109618 e CVE-2026-109619), permettono di eseguire codice sul server tramite richieste senza login, prima che venga eseguito qualsiasi codice dell'applicazione. Riguardano ogni installazione di PHP che gestisce richieste web, e GLPI gira su PHP. La correzione è nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, rilasciate il 21 ottobre 2026. Questa guida spiega che cosa sono le vulnerabilità, perché GLPI è nel mirino, come scoprire dove ha PHP, come correggere in ogni scenario, come capire se qualcuno è già entrato e che cosa fare dopo.

Questa guida si basa sulle informazioni pubbliche disponibili il 22 ottobre 2026. Gli avvisi di sicurezza cambiano rapidamente: verifichi anche l'avviso del Suo fornitore o della Sua distribuzione prima di intervenire.

Aggiornamento: il 23 ottobre 2026 PHP ha divulgato una terza vulnerabilità, la CVE-2026-115560, ancora senza correzione. Veda che cosa cambia e la configurazione che protegge.

Riepilogo per chi ha cinque minuti

Aggiornamento del 23/10: una terza vulnerabilità, CVE-2026-115560

Il 23 ottobre il progetto PHP ha pubblicato un avviso su una terza vulnerabilità di esecuzione remota di codice, la CVE-2026-115560, legata alla funzione di avanzamento del caricamento delle sessioni (session upload progress). È diversa dalle due di PHP2Shell, e le versioni del 21 e 22 ottobre non la correggono. La correzione arriverà con la prossima versione regolare di PHP, ancora senza data, e l'avviso completo uscirà insieme a essa.

Il percorso di attacco è molto più stretto di quello di PHP2Shell. Esiste solo quando si verificano insieme tre condizioni:

1. il php.ini imposta session.serialize_handler su php_binary o php_serialize;
2. l'applicazione cambia questo valore in php durante l'esecuzione, con ini_set(), prima di aprire la sessione;
3. l'avanzamento del caricamento della sessione è attivo, che è l'impostazione predefinita di PHP.

GLPI non fa questo cambio. Abbiamo verificato il codice di GLPI 10, 11 e 12: non modifica il serialize_handler e non usa l'avanzamento del caricamento della sessione. Un server che esegue solo GLPI, con la configurazione predefinita di PHP, non è esposto attraverso questo percorso. Il rischio compare quando lo stesso PHP serve altre applicazioni, come un sito, un negozio o un sistema legacy, che Lei non può sottoporre ad audit.

Anche così, la raccomandazione è disattivare la funzione subito. Lo stesso PHP lo aveva già suggerito il 21 ottobre come misura di contenimento per la CVE-2026-109619, e GLPI non perde nulla:

session.upload_progress.enabled = Off

Inserisca la riga nel php.ini del PHP che serve il web o nel pool di PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off) e riavvii PHP-FPM o Apache. Impostarla dal codice, con ini_set(), o in un file .user.ini non protegge. Dove si trova il file in ogni scenario:

Per verificare sul server, usi PHP-FPM e non il PHP da riga di comando, che legge un altro file:

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

Il risultato atteso è Off. Se un pool contiene la riga con on, questa prevale sul php.ini.

Suggerimento: questa configurazione non sostituisce l'aggiornamento per le vulnerabilità del 21 ottobre. Chiude solo la nuova vulnerabilità finché non esce la correzione. Quando PHP pubblicherà la prossima versione, aggiorni di nuovo.

Che cosa è successo

Il progetto PHP ha pubblicato correzioni di sicurezza per due vulnerabilità di esecuzione remota di codice nel nucleo del linguaggio. Nel changelog ufficiale, le correzioni compaiono come "Avoid state corruption via bailout" (GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp). Fonti di sicurezza citano un punteggio di 9,2 sulla scala CVSS 4.0, che le colloca nella fascia critica. Alcune fonti citano 9,8 sulla scala CVSS 3.1 del NVD.

In parole semplici:

• CVE-2026-109618: una condizione di memoria esaurita può interrompere PHP a metà di una richiesta, con dati interni solo parzialmente inizializzati. Durante la pulizia della richiesta, PHP finisce per trattare questi dati non validi come validi.
• CVE-2026-109619: uno stato interno di una richiesta può sopravvivere dopo che la sua memoria è stata liberata. La richiesta successiva, gestita dallo stesso processo, può usare quello stato prima che venga reinizializzato.

Entrambi i casi sono problemi di gestione della memoria all'interno dell'interprete, ed è questo che li rende gravi. Secondo le analisi pubblicate, una sola richiesta non autenticata può innescare l'attacco prima che venga eseguito qualsiasi codice dell'applicazione. In altre parole: la schermata di login di GLPI, i permessi dei profili e le regole dell'applicazione non vengono nemmeno consultati.

Quali installazioni sono esposte

Tutti i modi di eseguire PHP per il web compaiono negli avvisi: PHP-FPM (il più comune con Nginx e con Apache moderno), Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Le analisi indicano mod_php come lo scenario a più alto rischio.

Il PHP da riga di comando (CLI), che esegue le azioni automatiche di GLPI tramite cron, non gestisce richieste web. Di solito è alla stessa versione e viene aggiornato insieme.

Non è solo GLPI

La vulnerabilità è in PHP, non in un'applicazione. Per questo qualsiasi sistema in PHP che serve il web è esposto, e la correzione è la stessa per tutti: aggiornare PHP e riavviare il servizio. Aggiornare WordPress, GLPI o un plugin non risolve.

L'allerta non è rimasta confinata agli addetti IT: Mercado Pago, per esempio, ha avvisato i commercianti che usano WooCommerce, PrestaShop e Adobe Commerce (Magento) di verificare il PHP dei loro negozi.

In pratica, chi si occupa di GLPI quasi sempre si occupa anche di altri server con PHP: il sito aziendale, la intranet, il monitoraggio, il sistema legacy che nessuno ha spento. Correggere solo GLPI lascia la porta aperta sul server accanto. Nel Passo 1 mostriamo come usare l'inventario di GLPI stesso per trovarli tutti.

Sono già sfruttate?

Le fonti divergono, e questo non cambia la raccomandazione:

• Amazon: secondo Help Net Security, il team di threat intelligence di Amazon ha registrato un tentativo di sfruttamento nella propria rete di honeypot (MadPot) il 17 ottobre, quattro giorni prima della divulgazione pubblica.
• watchTowr: nelle sue domande frequenti su PHP2Shell, ha comunicato il 21 ottobre di aver osservato lo sfruttamento delle vulnerabilità nella propria rete di honeypot.
• CISA (agenzia per la cybersicurezza degli Stati Uniti): nell'allerta del 21 ottobre ha dichiarato di non aver osservato sfruttamenti fino a quel momento, ma ha chiesto l'aggiornamento immediato. A chi non può aggiornare ha raccomandato di mettere offline i sistemi in PHP fino alla correzione. L'NCSC del Regno Unito ha dato la stessa raccomandazione.

Quando ci sono già tentativi registrati, anche prima della divulgazione, e un'allerta governativa chiede di spegnere ciò che non può essere corretto, il tempo tra "possibile" e "sta succedendo" è di solito questione di giorni. Lo tratti come un'emergenza.

Perché GLPI è nel mirino

GLPI è una classica applicazione PHP: server web, PHP e database. Ogni richiesta a GLPI passa per PHP, comprese quelle che arrivano prima del login. E GLPI di solito ha più porte aperte verso internet di quanto sembri:

Poiché l'attacco avviene prima che venga eseguito il codice di GLPI, qualsiasi di questi URL può fare da porta. Non importa se l'API richiede un token o se il portale richiede il login: la richiesta malevola non viene nemmeno verificata.

E ciò che si trova dietro quella porta è sensibile. Il server di GLPI custodisce l'accesso al database con tutti i ticket, gli allegati, i dati degli utenti e l'inventario dell'azienda. Nella cartella config si trovano la password del database e la chiave che protegge le password salvate in GLPI (raccoglitore di e-mail, LDAP, SMTP). Chi esegue codice sul server ha tutto questo a portata di mano.

Tre trappole comuni

• Aggiornare GLPI non aggiorna PHP. Se è appena passato a GLPI 12, non è protetto automaticamente: GLPI 12 richiede PHP 8.3, ma funziona con una 8.3 precedente alla correzione.
• Il numero di versione può ingannare. Ubuntu di solito applica la correzione al pacchetto e mantiene il numero (la 24.04 mostra 8.3.6 anche se aggiornata). Debian a volte fa lo stesso e a volte passa alla nuova versione. Un numero "vecchio" non prova che il server sia vulnerabile, e un pacchetto nuovo non prova che il servizio sia stato riavviato. Questa volta Debian ha cambiato il numero (8.4.27 su Debian 13 e 8.2.35 su Debian 12): lì un numero vecchio indica un pacchetto non corretto.
• PHP 8.1 su GLPI 10 è la combinazione più rischiosa: PHP senza versione corretta ufficiale e GLPI senza supporto. Veda la sezione su PHP 8.1 più avanti.

Passo 1: scopra dove ha PHP

La CISA apre la sua raccomandazione proprio qui: fare l'inventario di tutti i sistemi con PHP. GLPI è solo uno di essi. Spesso compaiono anche il sito aziendale, la intranet, Zabbix, phpMyAdmin, Moodle, il vecchio sistema di ticketing che nessuno ha spento.

Usi GLPI stesso per farlo

Se usa GLPI Agent, l'inventario software sa già dove si trova PHP:

1. Vada in Asset > Software e cerchi php.
2. Apra elementi come php8.3-fpm, php8.3-common, libapache2-mod-php8.3 o php-fpm, a seconda della distribuzione.
3. Nella scheda delle installazioni, veda su quali computer è installata ciascuna versione.

La versione mostrata dall'agente è quella del pacchetto, con il suffisso della distribuzione (per esempio, 8.3.6-0ubuntu0.24.04.x). È esattamente ciò che deve confrontare con l'avviso di sicurezza della distribuzione. L'inventario non vede il PHP all'interno dei container Docker né il PHP decompresso su Windows o in XAMPP.

Controlli il PHP che serve GLPI

Il PHP da riga di comando può essere diverso da quello che serve il sito. Per vedere quello che conta:

• In GLPI: in Configurazione > Generale > Sistema, la sezione del server mostra la versione di PHP usata da GLPI.
• Sul server: veda quale servizio è in esecuzione e quale versione usa.

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

Sostituisca 8.3 con la versione che compare nell'elenco dei servizi. Su Red Hat e derivate, usi sudo php-fpm -v.

Passo 2: aggiorni in base al Suo scenario

Ubuntu e Debian con il PHP della distribuzione

Le distribuzioni ricevono le correzioni prima della divulgazione pubblica e pubblicano i pacchetti nei propri avvisi di sicurezza (su Ubuntu l'USN-8948-1 del 21/10; su Debian il DSA-6574-1 e il DLA-4848-1). Su Ubuntu il numero principale non cambia; verifichi tramite il pacchetto:

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

L'ultimo comando legge il changelog del pacchetto installato e deve mostrare CVE-2026-109618 e CVE-2026-109619. Se gli aggiornamenti automatici di sicurezza sono attivi, il pacchetto potrebbe essere già arrivato; anche in quel caso, il servizio usa il nuovo codice solo dopo essere stato riavviato.

Versioni di riferimento per distribuzione:

PHP da repository di terzi (ondrej/php, sury.org) o pannello di hosting

Questi pacchetti riportano il numero della versione ufficiale (per esempio, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 su Ubuntu), quindi la verifica è diretta. Gli aggiornamenti automatici della distribuzione normalmente non coprono questi repository, e lo stesso vale per i pannelli che installano il PHP di sury, come CloudPanel:

sudo apt update && sudo apt upgrade
php -v

In pannelli come cPanel, Plesk o aaPanel, usi l'aggiornamento di PHP del pannello stesso e verifichi la versione di ogni sito.

Red Hat, Rocky, AlmaLinux e Oracle Linux

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

Con il PHP di Red Hat stesso (moduli AppStream), anche qui il numero non cambia: fa fede il changelog. Se il PHP proviene dal repository Remi, l'aggiornamento arriva con il numero della versione ufficiale (dalla 8.2 alla 8.5, su RHEL 8, 9 e 10): verifichi con php -v. Il giorno della divulgazione Remi non aveva ancora i pacchetti e i mirror erano sovraccarichi: se dnf non propone l'aggiornamento, esegua sudo dnf upgrade --refresh 'php*', che ignora la cache, e riprovi qualche minuto dopo. Con Remi in modalità SCL, il servizio si chiama per esempio php83-php-fpm.

Docker

Il container non si aggiorna da solo, e riavviare il vecchio container non sostituisce PHP. Occorre scaricare la nuova immagine e ricrearlo. Prima, faccia un backup del database e verifichi che la cartella dei file, la cartella config e il database siano su volumi (docker inspect <container> --format '{{json .Mounts}}'); altrimenti, ricreare il container cancella i dati. Se l'immagine usa il tag latest, il pull può portare un'altra versione di GLPI: fissi il tag. Con docker compose, indichi il servizio di GLPI (glpi nei comandi qui sotto): senza il nome, il pull scarica anche l'immagine del database, e con mariadb:latest questo può portare con sé una versione maggiore del database.

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

Se usa l'immagine ufficiale glpi/glpi, è già uscita con il PHP corretto: il 22/10 tutti i tag (latest, 12.0.0, 11.0.11, 10.0.28 e le nightly) contenevano PHP 8.5.12, quindi basta il pull. Usa Apache con mod_php, lo scenario più rischioso, un motivo in più per non rimandare. Se la Sua immagine è costruita a partire da un'immagine ufficiale di PHP (per esempio, php:8.3-fpm o php:8.3-apache), i tag corretti sono usciti nel corso del 21/10 e quelli di FrankenPHP nelle prime ore del 22/10 (UTC); un pull fatto prima ha scaricato la versione vulnerabile. Due attenzioni: l'apt upgrade nel Dockerfile non aggiorna il PHP di queste immagini, che è compilato a parte; e il tag mobile può portare più del PHP (anche il web server dell'immagine può cambiare versione). Prima di ricreare, conservi l'immagine attuale per poter tornare indietro: docker tag "$(docker inspect --format '{{.Image}}' <container-glpi>)" glpi-prima-della-patch.

Windows (IIS, XAMPP, WampServer)

Scarichi la versione corretta del Suo ramo dal sito ufficiale di PHP per Windows e sostituisca la cartella di PHP, mantenendo il Suo php.ini. I pacchetti pronti come XAMPP tendono a pubblicare la nuova versione in ritardo; non li aspetti. Poi riavvii IIS o Apache.

Passo 3: riavvii e verifichi

Aggiornare il pacchetto non basta. I processi già in esecuzione continuano a usare il vecchio codice caricato in memoria finché non vengono riavviati:

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

Su Red Hat e derivate, i servizi si chiamano di solito php-fpm e httpd. Dopo il riavvio:

1. Apra Configurazione > Generale > Sistema in GLPI e verifichi la versione di PHP.
2. Esegua php -v sul server e verifichi anche PHP-FPM (sudo php-fpm8.3 -v).
3. Con il PHP di sury, di Remi, di un'immagine Docker ufficiale o di Windows, GLPI deve mostrare la versione corretta. Se mostra quella vecchia, c'è ancora un vecchio processo in esecuzione o un secondo PHP installato.
4. Con il PHP della distribuzione, il numero può non cambiare. Verifichi il pacchetto (dpkg -l 'php8.3*' o rpm -q php-fpm) e se il servizio è stato riavviato dopo l'installazione: systemctl status php8.3-fpm mostra l'ora in "active since". Su Ubuntu, sudo needrestart -r l elenca ciò che gira ancora con codice vecchio; su Red Hat, sudo dnf needs-restarting -s.

Testi GLPI prima di considerare chiuso il lavoro

Un aggiornamento di PHP raramente compromette GLPI, ma vale la regola di qualsiasi modifica in produzione: se possibile, la applichi prima su una copia di collaudo e, in ogni caso, faccia prima un backup. Dopo l'aggiornamento, verifichi in pochi minuti i flussi che non possono fermarsi:

1. Login, anche tramite LDAP o single sign-on (SSO), se li usa.
2. Apertura di ticket dal portale self-service e tramite modulo.
3. Raccoglitore di e-mail: invii un'e-mail di prova e verifichi che diventi un ticket.
4. Notifiche: verifichi che GLPI continui a inviare e-mail.
5. Azioni automatiche: in Configurazione > Azioni automatiche, verifichi che le attività continuino a essere eseguite.
6. API e integrazioni: inventario degli agenti, chatbot, ERP e automazioni che chiamano GLPI.
7. Plugin: apra le schermate dei plugin che il team usa di più.

E se non può aggiornare subito?

• Tolga GLPI da internet fino alla correzione. Lasci l'accesso solo dalla rete interna o tramite VPN. Se il portale self-service deve restare aperto, questa è la priorità numero uno dell'aggiornamento, non il motivo per rinviarlo.
• Limiti ciò che deve restare aperto, prima di PHP. Applichi la restrizione nel firewall o nel server web (allow/deny in Nginx, Require ip in Apache), mai nelle opzioni di GLPI stesso, che vengono eseguite solo dopo PHP. E ricordi: limitare solo l'inventario e l'API serve a poco se la schermata di login resta aperta.
• Disattivi l'avanzamento del caricamento della sessione (session.upload_progress.enabled = Off), come raccomandato da PHP. Questo chiude la CVE-2026-115560 e riduce l'esposizione alla CVE-2026-109619, ma non sostituisce l'aggiornamento.
• Usi un web application firewall (WAF) come soluzione ponte. Cloudflare ha pubblicato regole iniziali per i vettori noti. Aiuta, ma non corregge: la stessa AWS ha avvertito che nessuna modifica di configurazione è una mitigazione completa. Le regole sono disponibili anche nel piano gratuito di Cloudflare.
• Aumenti la sorveglianza. Tenga d'occhio i processi PHP che aprono una shell o scaricano file, che è il segnale che la CISA chiede di monitorare.

Passo 4: verifichi se qualcuno è già entrato

Prima di tutto, una rassicurazione: aver usato una versione vulnerabile non prova che ci sia stata un'intrusione o una fuga di dati. È solo il motivo per controllare. Il tentativo più vecchio registrato risale al 17 ottobre. Se il Suo GLPI è rimasto esposto con PHP vulnerabile in quel periodo, conviene un controllo rapido dopo la correzione. Nessuno di questi comandi modifica nulla.

File PHP dove non dovrebbero esserci. La cartella dei dati di GLPI contiene allegati, immagini e file temporanei; lì non dovrebbe comparire alcun file .php, a eccezione della cache (_cache) e delle classi generate da plugin come Campi aggiuntivi (Fields) e GenericObject, in files/_plugins/fields e files/_plugins/genericobject. Questi compaiono nel risultato e sono attesi se le date corrispondono a modifiche fatte da Lei:

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 seconda ricerca usa la data di modifica del file nel sistema (ctime), che un intruso non può falsificare con touch. Adatti i percorsi alla Sua installazione. I file di plugin e di GLPI aggiornati da Lei nel periodo sono attesi; ciò che preoccupa è quello che nessuno ricorda di aver messo lì.

Processi e connessioni dell'utente del server 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

Su Red Hat, l'utente è apache (crontab -u apache -l). L'utente del server web non dovrebbe eseguire sh, bash, curl, wget o nc, né avere attività pianificate che Lei non ha creato (l'attività del cron.php di GLPI è legittima). Diffidi delle connessioni in uscita verso IP diversi dal database, dal LDAP, dall'SMTP o dalle Sue integrazioni.

Account e plugin nuovi in GLPI. In Amministrazione > Utenti, aggiunga la colonna Data di creazione (icona delle colonne), ordini in base a essa e verifichi se è comparso qualche account sconosciuto dal 17 ottobre, soprattutto con profilo Super-Admin. Controlli anche Amministrazione > Profili (modifiche ai permessi), Configurazione > Plugin (qualche plugin che Lei non ha installato?) e i client dell'API.

Log del server web e di PHP. Picchi di richieste strane, da IP sconosciuti, seguiti da errori 500, meritano attenzione, soprattutto sugli URL della tabella precedente. Nel log di PHP-FPM, anche le sequenze di "Allowed memory size exhausted" e i processi terminati da un segnale (per esempio, "exited on signal 11") meritano un'occhiata.

Se trova segni di intrusione

1. Isoli il server dalla rete, senza spegnerlo, per preservare le prove.
2. Conservi i log e una copia del disco prima di qualsiasi pulizia.
3. Ricostruisca partendo da una base pulita e ripristini i dati da un backup precedente all'intrusione, valutando che cosa occorre rifare dopo quella data. Pulire solo il file trovato non garantisce che non sia rimasta un'altra porta.
4. Cambi tutti i segreti che il server custodiva, ma solo dopo averlo isolato e ricostruito. Se l'attaccante è ancora nell'ambiente, le nuove password trapelano insieme a quelle vecchie. L'ordine è: contenere, ripulire e solo allora cambiare:
5. la password del database, che si trova in config/config_db.php (o in /etc/glpi/ nelle installazioni da pacchetto);
6. la chiave glpicrypt.key, che protegge le password salvate in GLPI: ne generi una nuova con php bin/console glpi:security:change_key, che ricifra i dati (sostituire il file a mano rende i segreti illeggibili), e poi cambi le password stesse: raccoglitori di e-mail, account di lettura LDAP, SMTP e proxy;
7. le password degli amministratori locali di GLPI, perché gli hash erano nel database;
8. i token dell'API (di applicazione e degli utenti) e i segreti OAuth;
9. le credenziali delle integrazioni chiamate da GLPI (ERP, chatbot, automazioni).
10. Valuti la notifica: se i dati personali possono essere stati consultati, coinvolga il responsabile della protezione dei dati (DPO) e l'ufficio legale. La LGPD brasiliana (art. 48) prevede di comunicare l'incidente all'ANPD e agli interessati quando può causare un rischio o un danno rilevante, e il regolamento dell'ANPD fissa un termine breve per farlo (fuori dal Brasile si applica la normativa locale sulla protezione dei dati, per esempio il GDPR in Europa).

PHP 8.1 o precedente: il problema è più grande

PHP 8.1 e le versioni precedenti non sono più supportati dal progetto PHP e per questo non ricevono la versione corretta ufficiale. Il team di PHP ha pubblicato correzioni minime in codice sorgente per 7.4, 8.0 e 8.1: se compila PHP in proprio può applicarle; altrimenti dipende dalla pubblicazione del pacchetto da parte del Suo fornitore o della Sua distribuzione. PHP 5 e dalla 7.0 alla 7.3 non hanno alcuna correzione (è il caso di chi usa ancora GLPI 9.5). Su Ubuntu 22.04, per esempio, PHP 8.1 è mantenuto dalla stessa Canonical: l'USN-8948-1 del 21/10 include già la correzione. Anche sury e il PPA ondrej/php mantengono pacchetti dalla 7.4 alla 8.1; verifichi se includono già la correzione. Se GLPI si trova su un hosting gestito, chieda al provider un pacchetto con la correzione delle due vulnerabilità o un piano prioritario di migrazione verso una versione supportata, con una data.

Chi usa ancora PHP 8.1 di solito è anche su GLPI 10, che ha perso il supporto con l'arrivo di GLPI 12. GLPI 11 richiede PHP 8.2 o successivo, e GLPI 12 richiede la 8.3. Se è il Suo caso, correggere questa vulnerabilità e lasciare GLPI 10 sono diventati lo stesso progetto: veda i rischi di restare su GLPI 10 e il percorso per migrare.

Dopo la correzione: renda più piccolo il prossimo spavento

• Tolga da internet ciò che non ha bisogno di esserci. Inventario solo dagli IP degli agenti, API solo dai server che la usano, area amministrativa solo tramite VPN, sempre con la regola nel firewall o nel server web.
• Nasconda la versione di PHP. Con expose_php = Off nel php.ini, il server smette di annunciare la versione nell'intestazione della risposta. Riduce la scansione automatica, ma non protegge: l'attacco non ha bisogno di conoscere la versione.
• Attivi gli aggiornamenti automatici di sicurezza della distribuzione, ricordando che non coprono i repository di terzi né le immagini Docker.
• Abbia un backup testato del database e della cartella dei file di GLPI. Il ripristino è il piano B di ogni vulnerabilità critica.
• Tenga sotto controllo le vulnerabilità del Suo ambiente. CVE Scan è gratuito: verifica la versione di GLPI e di PHP, le intestazioni di sicurezza e i permessi, e mostra che cosa correggere per primo.

Cronologia

La checklist di oggi

1. Elencare tutti i server con PHP, non solo quello di GLPI (l'inventario di GLPI aiuta).
2. Verificare la versione in Configurazione > Generale > Sistema e il pacchetto sul server.
3. Aggiornare, partendo da ciò che è esposto su internet.
4. Riavviare PHP-FPM o Apache e verificare di nuovo.
5. Se oggi non è possibile aggiornare, togliere l'accesso esterno.
6. Eseguire i controlli di intrusione e conservare il risultato.
7. Limitare inventario, API e area amministrativa allo stretto necessario.
8. Disattivare session.upload_progress.enabled nel php.ini o nel pool di PHP-FPM, riavviare e verificare.

Ha bisogno di aiuto per aggiornare il server di GLPI o rivedere l'esposizione del Suo ambiente? Ci contatti.

Fonti: avvisi di sicurezza di PHP del 21 e 23/10/2026, allerta della CISA (21/10/2026), changelog ufficiale di PHP (php.net), bollettino di sicurezza di AWS, articolo di Help Net Security su PHP2Shell, FAQ di watchTowr, avviso di Ubuntu (USN-8948-1), tracker di sicurezza di Debian e avviso di Mercado Pago agli sviluppatori (21/10/2026). GLPI è un marchio registrato di Teclib'. NexTool non è affiliata a Teclib'.