PHP2Shell colpisce il software dietro milioni di siti: come difendersi

Quasi sette siti su dieci, tra quelli di cui si conosce il linguaggio usato sul server, utilizzano PHP. È la misura della superficie potenzialmente interessata da PHP2Shell: due vulnerabilità critiche scoperte nel linguaggio di programmazione che lavora dietro le pagine web. Il 21 ottobre 2026 il progetto PHP ha pubblicato quattro versioni corrette e ha chiesto di installarle immediatamente. Il dato sulla diffusione, rilevato da W3Techs il 22 ottobre, non significa però che sette siti su dieci siano stati violati, né che tutti siano vulnerabili: la loro esposizione dipende dalla versione di PHP installata e dalla configurazione.

Per capire perché la notizia riguarda anche chi non scrive codice, basta pensare a PHP come al motore nascosto di un sito: riceve richieste, elabora informazioni e prepara la pagina che vediamo. WordPress, Drupal e il software usato da Wikipedia fanno parte dell'ecosistema che vi si appoggia. In questo caso il problema è nel motore, non necessariamente nel sito costruito sopra: aggiornare soltanto WordPress, per esempio, non equivale ad aggiornare PHP.

La risposta non è stata solo teorica. La Wikimedia Foundation ha spiegato di aver disattivato per precauzione diversi servizi di supporto, mentre cercava di evitare interruzioni alle sue wiki. È un esempio concreto del dilemma per chi gestisce un servizio online: continuare a renderlo disponibile, oppure fermarlo finché non si può installare la correzione.

Le vulnerabilità sono identificate come CVE-2026-109618 e CVE-2026-109619. CVE, sigla di Common Vulnerabilities and Exposures, è il sistema che assegna un identificativo alle falle note; entrambe hanno ricevuto un punteggio di gravità di 9,2 su 10. Secondo l'avviso del progetto PHP, possono consentire l'esecuzione remota di codice: in determinate condizioni, un aggressore può far eseguire istruzioni al server senza possedere un account sul sito.

La prima falla riguarda la gestione di un errore quando PHP esaurisce la memoria disponibile per una richiesta. La seconda riguarda informazioni interne che possono rimanere in uno stato non valido ed essere riutilizzate dalla richiesta successiva. È un po' come consegnare a un nuovo cliente una cartellina che avrebbe dovuto essere svuotata dopo il cliente precedente: il difetto non è nella domanda che il cliente pone, ma nel modo in cui l'ufficio gestisce le cartelline. Il progetto PHP descrive questi due meccanismi nel proprio avviso di sicurezza.

I ricercatori coinvolti nella divulgazione hanno dimostrato attacchi contro ambienti di prova basati su WordPress, Drupal e Joomla; segnalano anche la possibilità di leggere dati sensibili dalla memoria dei processi PHP. La loro documentazione precisa un punto decisivo: quelle piattaforme sono esempi, non un requisito dell'attacco. Anche un'applicazione molto semplice può essere esposta se usa una versione interessata di PHP.

La percentuale di W3Techs va letta con precisione: il 69,3% riguarda i siti per cui il servizio riesce a identificare il linguaggio lato server, non una conta dei server esposti né dei siti compromessi. Dice comunque molto sulla dipendenza del web da PHP. Quando una falla si trova in un componente così diffuso, il lavoro di verifica ricade su organizzazioni molto diverse: dal grande portale al piccolo negozio online.

C'è poi la questione delle versioni vecchie. La ricerca su PHP2Shell ha individuato versioni interessate risalenti a PHP 5.4, mentre il progetto PHP pubblica nuove versioni corrette per i rami 8.2, 8.3, 8.4 e 8.5. Per PHP 8.1 e precedenti non sono previsti normali aggiornamenti ufficiali: alcuni fornitori possono però distribuire correzioni proprie per i sistemi che mantengono, e il progetto ha pubblicato modifiche minime al codice sorgente per i rami 7.4, 8.0 e 8.1. Un vecchio numero di versione, quindi, non basta da solo a stabilire se un pacchetto fornito da terzi sia stato corretto: serve verificare l'avviso del fornitore.

Il problema può nascondersi anche dove PHP non è evidente a chi visita una pagina: in servizi secondari, interfacce di amministrazione e prodotti che lo includono al proprio interno. L'agenzia olandese per la cybersicurezza NCSC-NL richiama l'attenzione proprio su questi componenti, che un amministratore potrebbe non poter aggiornare direttamente senza attendere il produttore. In Europa, Italia compresa, questo rende la verifica rilevante per chiunque gestisca servizi web basati su PHP, non solo per i grandi siti citati nelle cronache.

Le correzioni ufficiali sono arrivate il 21 ottobre 2026. Per ciascuno dei quattro rami PHP ancora aggiornati dal progetto, esiste una prima versione che include la riparazione delle due falle. La pagina ufficiale delle release invita a passare subito alla versione corretta del proprio ramo.

Installare il pacchetto è solo una parte dell'intervento: occorre anche riavviare i processi che stanno ancora usando la vecchia versione. I ricercatori di PHP2Shell ricordano inoltre che un sito può avere più ambienti PHP, per esempio uno per le pagine pubbliche e un altro per attività interne. Correggerne uno solo lascia scoperti gli altri.

Chi visita un sito non può correggere PHP dal proprio telefono o computer: l'aggiornamento riguarda il server ed è responsabilità di chi lo gestisce o del fornitore dell'hosting. Neppure aggiornare il browser risolve queste due falle. Per il visitatore, la distinzione importante è tra rischio di compromissione e compromissione accertata: la presenza di una vulnerabilità non dimostra da sola che qualcuno abbia avuto accesso ai dati.

Un'interruzione può anzi essere una misura prudente. Wikimedia ha dichiarato di aver fermato alcuni servizi di supporto finché non fosse possibile renderli di nuovo disponibili in sicurezza. Prima di attribuire un sito irraggiungibile a un attacco riuscito, dunque, conviene cercare una comunicazione del gestore: fermarsi per installare una correzione è diverso dall'essere stati violati.

PHP2Shell mostra quanto possa contare un componente che quasi nessuno vede. Il progetto PHP ha già pubblicato le correzioni, ma la loro efficacia dipende ora da un lavoro distribuito: trovare ogni installazione, aggiornarla e verificare che la modifica sia entrata davvero in funzione. Per chi possiede un sito, la domanda da fare oggi al proprio fornitore non è «WordPress è aggiornato?», ma «Quale PHP sta usando il mio sito, e include già la correzione?»