PHP2Shell, Google avverte: installare le patch potrebbe non essere sufficiente

Installare gli aggiornamenti di sicurezza per PHP2Shell potrebbe non essere sufficiente a proteggere un server Web. Anche dopo aver applicato le patch correttive, infatti, Apache, PHP-FPM e altri processi possono continuare a eseguire la vecchia versione vulnerabile di PHP, mantenendo esposte le applicazioni a possibili attacchi remoti. È uno degli aspetti sui quali Google Cloud insiste nella sua analisi delle vulnerabilità PHP2Shell, aggiornata di recente con ulteriori indicazioni provenienti da Mandiant.

Il problema assume particolare rilievo perché le due falle principali, CVE-2026-109618 e CVE-2026-109619, interessano direttamente il motore PHP e non una specifica applicazione. I ricercatori di Wiz hanno dimostrato la possibilità di sfruttarle per ottenere l’esecuzione remota di codice su siti WordPress, Drupal e Joomla, anche utilizzando versioni aggiornate dei CMS. Oltretutto, i ricercatori di VulnCheck hanno dimostrato che PHP2Shell può superare ASLR, difesa che permette di rendere aleatorio l’utilizzo degli indirizzi di memoria.

PHP è alla base di una quota significativa dei siti Web di tutto il mondo e accompagna la diffusione delle applicazioni dinamiche sin dagli anni ’90. Nel tempo, il linguaggio ha attraversato numerose revisioni, conservando però alcuni meccanismi interni di gestione della memoria risalenti a versioni molto precedenti. PHP2Shell sfrutta proprio due debolezze presenti nel codice runtime da oltre un decennio: le versioni interessate risalgono fino a PHP 5.4.

Il vero problema: PHP aggiornato sul disco, ma vulnerabile in memoria

Immaginiamo un amministratore che riceve una segnalazione di sicurezza, aggiorna i pacchetti PHP tramite il gestore della propria distribuzione Linux e verifica che l’operazione sia terminata correttamente. La procedura potrebbe sembrare conclusa; in alcuni casi non è proprio così.

Un server Web non rilegge continuamente dal disco i file eseguibili e le librerie che utilizza: quando avvia un processo, il sistema operativo carica in memoria il codice necessario; una successiva sostituzione dei file installati non modifica automaticamente quello già presente nello spazio di indirizzamento del processo.

Di conseguenza, un aggiornamento installato correttamente può lasciare attivi processi PHP vulnerabili: Google richiama espressamente il problema citando i binari php-fpm e le librerie libphp.so. Aggiornare i rispettivi pacchetti non sostituisce il codice che i worker hanno già caricato. L’amministratore deve quindi individuare i servizi effettivamente responsabili dell’esecuzione di PHP e procedere al loro riavvio.

Per Apache con il modulo mod_php occorre riavviare Apache; nelle configurazioni basate su PHP-FPM bisogna invece intervenire sul servizio FPM corrispondente alla versione utilizzata. Google menziona anche FrankenPHP e LiteSpeed, oltre agli eventuali processi gestiti da supervisori esterni.

Non basta nemmeno un generico reload della configurazione per avere la certezza che ogni processo sia stato sostituito. In particolare, Red Hat raccomanda esplicitamente un riavvio completo dei worker, osservando che alcuni possono conservare informazioni vulnerabili provenienti dalle richieste precedenti.

Non soltanto server Web: PHP può nascondersi nei sistemi di gestione

Google richiama l’attenzione su un rischio che non riguarda soltanto i server Web tradizionali. PHP può essere integrato in applicazioni aziendali, pannelli di amministrazione, gateway, appliance di rete, sistemi di archiviazione e altri prodotti che espongono interfacce Web. In alcuni casi, questi componenti utilizzano un interprete autonomo, che non dipende dai pacchetti PHP installati sul sistema operativo e che richiede aggiornamenti specifici del produttore.

Abbiamo già affrontato il problema nell’articolo PHP2Shell: come scoprire i server PHP nascosti e vulnerabili, illustrando come individuare gli interpreti dimenticati su Linux e Windows, riconoscere le installazioni incorporate nei software di terze parti, controllare le configurazioni di Apache, Nginx e IIS e censire i runtime presenti nei container Docker. Abbiamo inoltre spiegato perché il semplice comando php -v non permette di stabilire con certezza se un server sia protetto e come distinguere le versioni realmente vulnerabili da quelle che hanno ricevuto correzioni tramite backport.

L’analisi di Google aggiunge un aspetto particolarmente importante: anche dopo aver individuato tutte le installazioni e distribuito le correzioni, il codice vulnerabile potrebbe continuare a essere eseguito dai processi ancora attivi. Una vecchia libreria caricata in memoria non scompare automaticamente quando il gestore dei pacchetti sostituisce il file corrispondente sul disco. Lo stesso principio vale per i container che continuano a utilizzare immagini precedenti all’aggiornamento.

La verifica deve quindi spingersi oltre l’inventario dei componenti e la presenza delle patch: occorre controllare quali processi elaborano effettivamente le richieste, accertare che utilizzino gli eseguibili corretti e verificare che nessuna istanza obsoleta continui a ricevere traffico.

Per le appliance e i prodotti con PHP incorporato, Google raccomanda inoltre di consultare gli advisory dei rispettivi fornitori, poiché l’aggiornamento potrebbe richiedere un nuovo firmware o una release specifica dell’applicazione.