In questo articolo Indice dei contenuti 3 sezioni
Le due vulnerabilità critiche battezzate PHP2Shell hanno messo in evidenza un problema che molti amministratori di sistema conoscono da tempo ma che quasi nessuno affronta con la dovuta serietà. Si tratta di individuare tutte le installazioni PHP presenti in un’infrastruttura aziendale, comprese quelle che nessuno ricorda più di aver configurato. L’aggiornamento straordinario del 21 ottobre 2026, rilasciato per chiudere due falle che consentono l’esecuzione di codice da remoto, ha trasformato una semplice questione di inventario software in un’emergenza di sicurezza a tutti gli effetti.
Il motivo è facile da intuire. Secondo le rilevazioni aggiornate proprio al 21 ottobre 2026, PHP è usato dal 69,3% dei siti per i quali si riesce a identificare il linguaggio lato server. Una diffusione enorme che rende la faccenda piuttosto delicata, anche perché qui il difetto sta nel motore del linguaggio e aggiornare il CMS o i plugin non serve a nulla. Molti professionisti e imprese, poi, gestiscono server, apparati e applicazioni web che non compaiono negli elenchi ufficiali. E quando esplode una falla grave diventa complicato capire dove mettere le mani e con quale urgenza.
Perché aggiornare i server conosciuti non basta
Il team di sviluppo ha pubblicato una patch fuori calendario per due vulnerabilità che hanno ricevuto entrambe un punteggio di 9,2 sulla scala CVSS 4.0. Le versioni indicate sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le falle permettono a un aggressore non autenticato di eseguire codice sul server e riguardano le installazioni che elaborano richieste web tramite FPM, Apache con il modulo integrato, la modalità CGI, FrankenPHP e LiteSpeed. Lo scenario peggiore coinvolge mod_php, visto che il progetto conferma l’esistenza di una tecnica d’attacco in grado di raggiungere il codice vulnerabile prima ancora che l’applicazione cominci a girare.
Il guaio vero, però, è il PHP nascosto dentro software e appliance. Un servizio installato anni fa per esigenze amministrative può continuare a funzionare senza che il personale sappia bene di cosa sia fatto. Capita spesso con applicazioni fornite da terzi che includono Apache, PHP e un database nella propria cartella. Il sistema operativo viene aggiornato con regolarità ma l’interprete incorporato resta fermo alla versione originale del fornitore. Lo stesso vale per gestionali documentali, portali interni, pannelli di amministrazione e apparati con interfaccia web, senza dimenticare pannelli di hosting come cPanel e Plesk che gestiscono le versioni del linguaggio per conto proprio.
Come scovare gli interpreti su Linux e Windows
Su Linux il primo passo è controllare i pacchetti installati con gli strumenti del sistema, quindi dpkg su Debian e Ubuntu oppure rpm sulle distribuzioni come RHEL e derivate. Il risultato però è parziale, perché PHP potrebbe trovarsi in directory esterne come /opt oppure essere stato compilato a mano. Conviene quindi cercare direttamente i file eseguibili dentro /usr, /opt e /srv e verificarne poi la versione, evitando di lanciare alla cieca binari sconosciuti. In certi casi è meglio controllarne prima provenienza, firma e dipendenze.
Serve anche capire quali processi siano davvero attivi. Analizzare i processi in esecuzione, le unità systemd e la configurazione di Apache o Nginx aiuta a distinguere una copia dimenticata da un runtime che risponde alle richieste. Sullo stesso server possono convivere più versioni, magari PHP 8.4 da riga di comando, PHP 8.2 in un pool FPM e un terzo runtime gestito dal pannello di hosting. Per avere un quadro affidabile bisogna collegare ogni applicazione all’eseguibile che elabora le sue richieste HTTP.
Su Windows la ricerca può partire da PowerShell, cercando in modo ricorsivo php.exe e la sua variante CGI in Program Files e in inetpub. Meglio però non fermarsi lì, perché applicazioni portabili e stack indipendenti potrebbero stare su altri dischi. Vanno controllate anche le associazioni FastCGI di IIS, mentre i sistemi EDR possono rendere la caccia molto più rapida su centinaia o migliaia di macchine.
Container e numeri di versione ingannevoli
I container rappresentano una categoria particolarmente insidiosa. Su un host con Docker può non esserci alcuna traccia di PHP nel gestore dei pacchetti, mentre i singoli container eseguono interpreti diversi. La verifica deve coprire immagini, container attivi e dipendenze. Un tag come php:8.5 non garantisce che la correzione sia presente, perché può indicare una famiglia di versioni e l’immagine scaricata potrebbe essere precedente alla patch. Per le applicazioni sviluppate in casa conviene aggiornare l’immagine di base, ricostruire il container e distribuire la nuova versione.
Anche il confronto con i numeri di versione pubblicati dal team PHP è solo un primo passaggio. Le distribuzioni Linux con supporto a lungo termine possono infatti applicare le correzioni di sicurezza a versioni precedenti del software lasciando invariato il numero della versione principale.
Fonte: TecnoAndroid