PHP2Shell, due falle critiche minacciano PHP sui server Web: cosa fare

Due vulnerabilità critiche individuate in PHP hanno spinto il team di sviluppo a programmare un aggiornamento di sicurezza straordinario. Le falle, entrambe classificate con un punteggio CVSS 4.0 pari a 9,2, potrebbero consentire l’esecuzione di codice da remoto sui server vulnerabili. I ricercatori hanno già iniziato a riferirsi al problema con il nome PHP2Shell, mentre gli amministratori dei sistemi PHP devono prepararsi a intervenire rapidamente.

La gravità della situazione dipende soprattutto dalla diffusione del linguaggio. Nato nel 1995 e diventato uno dei principali strumenti per sviluppare applicazioni Web dinamiche, PHP continua a costituire una componente fondamentale di piattaforme come WordPress, Drupal, Joomla e Magento, oltre che di numerosi software aziendali e pannelli di amministrazione dei servizi di hosting. Una vulnerabilità nel motore PHP può quindi avere conseguenze molto più ampie rispetto a un difetto circoscritto a un singolo CMS o plugin.

Il comunicato ufficiale pubblicato il 20 ottobre 2026 conferma l’esistenza di due problemi critici e annuncia il rilascio delle correzioni per oggi, mercoledì 21 ottobre alle 16 italiane. Si tratta di una decisione insolita rispetto al normale calendario degli aggiornamenti, accelerata dalla diffusione anticipata di alcune informazioni riservate.

PHP2Shell: cosa sappiamo delle due vulnerabilità critiche

Le vulnerabilità sono associate agli identificativi CVE-2026-109618 e CVE-2026-109619, emersi attraverso una comunicazione non ufficiale e successivamente ripresi dai ricercatori di sicurezza.

Secondo le informazioni raccolte da watchTowr e Huntress, si tratterebbe di vulnerabilità di tipo Remote Code Execution (RCE): una categoria di problemi che permette potenzialmente a un aggressore di eseguire codice sul sistema bersaglio senza avere accesso fisico alla macchina.

Al momento, però, non sono noti il componente vulnerabile di PHP, le condizioni necessarie per attivare il difetto e l’eventuale presenza di prerequisiti quali particolari estensioni, configurazioni o modalità di esecuzione.

Il punteggio CVSS di 9,2 segnala una criticità elevatissima, ma non fornisce alcuna indicazione sul procedimento di attacco.

Quali versioni PHP rischiano di essere vulnerabili

Le prime indiscrezioni indicano un possibile coinvolgimento delle versioni PHP a partire dalla famiglia 5. La situazione, però, è resa complessa dal ciclo di manutenzione del linguaggio: come conferma la documentazione ufficiale sulle versioni supportate, infatti, le famiglie PHP mantenute dal progetto sono soltanto quattro, ovvero 8.2, 8.3, 8.4 e 8.5.

PHP 8.2 e PHP 8.3 ricevono esclusivamente aggiornamenti di sicurezza, mentre PHP 8.4 e PHP 8.5 si trovano ancora nella fase di supporto attivo.

Il team di sviluppo non distribuisce più patch correttive per i rami che hanno terminato il rispettivo ciclo di vita, come PHP 8.1, 8.0, tutte le versioni 7.x e precedenti.

I ricercatori della società di sicurezza Mallory hanno esaminato i dati raccolti da Shodan, motore di ricerca specializzato nell’individuazione dei servizi accessibili attraverso Internet. Il 20 ottobre 2026, circa 884.000 host esposti su Internet dichiaravano una versione PHP pari o precedente alla 8.1. La cifra rappresenta approssimativamente il 59% degli 1,5 milioni di host che comunicano esplicitamente una versione del linguaggio.

La rilevazione mette in evidenza un problema ben conosciuto dagli amministratori: la presenza di installazioni PHP obsolete, spesso legate ad applicazioni che non possono essere aggiornate facilmente per ragioni di compatibilità.

Un gestionale aziendale realizzato molti anni fa, ad esempio, potrebbe dipendere da funzioni rimosse nelle versioni più recenti del linguaggio. Aggiornare PHP senza verificare il funzionamento dell’applicazione rischierebbe di interrompere servizi essenziali; mantenere indefinitamente una versione non supportata, però, significa accumulare problemi di sicurezza che nessuna correzione ufficiale futura potrà risolvere.

Perché una vulnerabilità del motore PHP può essere più pericolosa di una falla in WordPress

Quando emerge una vulnerabilità in un plugin WordPress, generalmente il problema interessa le installazioni che utilizzano quello specifico componente, spesso soltanto in determinate versioni o configurazioni. Una falla nel motore PHP ha una portata differente: il linguaggio interpreta ed esegue il codice delle applicazioni, gestisce variabili, oggetti, richieste HTTP, interazioni con file e database attraverso le sue funzionalità e le estensioni disponibili.

Su molti server Linux, ad esempio, Nginx comunica con PHP attraverso PHP-FPM (FastCGI Process Manager), che gestisce i processi incaricati di eseguire gli script. Apache può invece utilizzare mod_php oppure inoltrare le richieste a PHP-FPM. Esistono anche installazioni che impiegano PHP-CGI, comprese alcune configurazioni Windows.

Se una vulnerabilità interessa una funzionalità raggiungibile durante la normale elaborazione di una richiesta web, il rischio può estendersi alle diverse applicazioni che sfruttano quella stessa funzionalità: non è necessario che WordPress, Drupal o il codice personalizzato contengano a loro volta un errore di programmazione.

Il meccanismo specifico di PHP2Shell, però, non è ancora pubblico: non possiamo quindi stabilire se tutte le modalità di esecuzione appena citate siano effettivamente interessate oppure se il difetto richieda condizioni più restrittive.

Di solito PHP-FPM esegue i processi applicativi con un utente non privilegiato, differente da root; una compromissione potrebbe quindi consentire l’accesso ai file, ai database e alle credenziali disponibili per quell’utente, senza necessariamente garantire il controllo amministrativo dell’intera macchina.

La situazione peggiora quando le applicazioni condividono lo stesso account, conservano password in file leggibili dal processo web oppure dispongono di autorizzazioni eccessive. Una buona separazione dei privilegi può limitare i danni anche quando la vulnerabilità iniziale non è ancora corretta.

Cosa fare subito sui server PHP e sugli hosting WordPress

La prima attività consigliabile consiste nell’identificare le versioni PHP effettivamente utilizzate dai servizi in produzione. Su un server Linux, il comando php -v permette di controllare la versione dell’interprete disponibile nella shell. Non garantisce però che il server Web utilizzi la medesima installazione.

Su macchine che ospitano più versioni PHP, la CLI potrebbe infatti utilizzare un binario differente rispetto ai processi PHP-FPM associati ai singoli siti: è quindi bene controllare anche i servizi attivi, i pool PHP-FPM, i percorsi dei relativi eseguibili e le impostazioni del server Web.

Chi gestisce un hosting con cPanel, Plesk o altri pannelli amministrativi deve considerare anche le versioni PHP selezionate per ogni dominio. Un unico server può eseguire contemporaneamente siti con PHP 8.4, 8.2 e vecchie versioni 7.x per esigenze applicative differenti.

Per WordPress è possibile controllare la versione utilizzata dal sito attraverso Strumenti, Salute del sito, Informazioni, Server, quando la relativa sezione è disponibile. Si tratta di una verifica utile, ma non sostituisce l’inventario delle altre installazioni PHP presenti sulla macchina.

Il secondo intervento consiste nel preparare l’applicazione degli aggiornamenti ufficiali. Per i sistemi gestiti tramite distribuzioni Linux è opportuno verificare i repository e gli avvisi del manutentore: una distribuzione potrebbe integrare la correzione mediante backport, senza cambiare il numero della versione principale dell’interprete.

Nei sistemi containerizzati occorre verificare le immagini utilizzate e ricreare i container con versioni corrette; aggiornare la copia di PHP installata sull’host non modifica automaticamente l’interprete presente dentro un container Docker.

Per chi utilizza hosting condivisi o gestiti, invece, il primo riferimento resta il fornitore del servizio: prima di modificare autonomamente la configurazione, conviene verificare quali aggiornamenti siano già programmati e se l’hosting gestisca direttamente le release di sicurezza.