PHP2Shell non è una vulnerabilità di WordPress. Colpisce PHP, cioè il runtime che molti server utilizzano per eseguire WordPress e altre applicazioni web. Aggiornare CMS, temi e plugin resta indispensabile, ma non installa automaticamente la correzione nel software amministrato dal provider o dal gestore del server.
Il progetto PHP ha pubblicato il 21 ottobre aggiornamenti per CVE-2026-109618 e CVE-2026-109619. In determinate condizioni, le falle possono consentire l’esecuzione remota di codice senza autenticazione. AWS e Cloudflare hanno osservato tentativi d’attacco sulle rispettive reti, compresi payload modificati e attività precedente alla divulgazione pubblica. Questo segnala un rischio operativo concreto, ma non dimostra che ogni richiesta malevola abbia compromesso il sistema raggiunto.
Per chi gestisce un sito, la priorità è quindi triplice: capire chi amministra PHP, verificare quale versione serve davvero il dominio e controllare ciò che è accaduto prima dell’aggiornamento.
WordPress e PHP sono due livelli diversi
WordPress è l’applicazione visibile; PHP è uno dei componenti che il server usa per eseguirla. Il pulsante nella bacheca aggiorna il CMS o le sue estensioni, non necessariamente i pacchetti del sistema operativo, i container o i processi PHP già attivi.
In un hosting condiviso il runtime viene normalmente gestito dal provider. Su un VPS non amministrato, un server dedicato o una macchina cloud, la responsabilità può invece ricadere sul cliente. Anche la formula “hosting gestito” non basta a chiarire il perimetro: staging, applicazioni personalizzate e container potrebbero seguire procedure differenti.
La domanda utile non è soltanto «WordPress è aggiornato?», ma «chi aggiorna il processo PHP che risponde alle richieste di questo dominio?».
Quali versioni bisogna controllare
Le release indicate dal progetto PHP come corrette per le due vulnerabilità principali sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Chi utilizza un ramo precedente deve chiedere al fornitore se esista una correzione mantenuta e documentata oppure programmare il passaggio a una versione supportata.
Il numero mostrato nel pannello dell’hosting è un buon punto di partenza, ma non sempre conclude la verifica. Alcune distribuzioni applicano correzioni ai propri pacchetti senza adottare immediatamente lo stesso numero della release ufficiale. In quel caso serve l’identificativo completo del pacchetto e un bollettino che confermi esplicitamente la correzione delle due CVE.
Conviene inoltre verificare se i processi interessati siano stati ricaricati o riavviati secondo le istruzioni del fornitore. Aver sostituito un pacchetto non prova, da solo, che ogni worker già in esecuzione stia usando il codice nuovo.
Cosa chiedere al provider
Chi non possiede accesso amministrativo dovrebbe aprire un ticket con domande verificabili:
- quale versione e quale pacchetto PHP servono effettivamente il dominio;
- se CVE-2026-109618 e CVE-2026-109619 risultano corrette;
- quando è stato applicato l’aggiornamento;
- se i processi PHP sono stati riavviati o ricaricati;
- se il controllo comprende sottodomini, staging, container e attività pianificate;
- se sono stati esaminati log, processi e file per individuare anomalie.
Una risposta generica come «il server è protetto» fornisce poche informazioni. Anche uno screenshot del selettore PHP può essere insufficiente: un ambiente di prova o una vecchia applicazione potrebbero usare un runtime diverso da quello associato al sito principale.
Patchare oggi non cancella il rischio di ieri
AWS riferisce un tentativo registrato il 17 ottobre, quattro giorni prima della pubblicazione delle patch, seguito da altri payload e infrastrutture il 21 ottobre. La stessa AWS precisa che non è possibile stabilire se i primi tentativi avrebbero avuto successo su sistemi reali.
La distinzione è essenziale: una scansione, una richiesta bloccata e una compromissione riuscita non sono la stessa cosa. L’attività osservata richiede attenzione, ma non giustifica conclusioni automatiche.
AWS raccomanda di avviare l’analisi almeno dal 17 ottobre, controllando richieste POST sospette, log del server web, esecuzioni inattese di processi e modifiche anomale ai file. Gli indirizzi pubblicati dalla società comprendono anche infrastrutture condivise: vanno quindi usati come elementi da investigare, non come una lista da bloccare indiscriminatamente.
Se emergono indicatori credibili, è prudente conservare log e copie dei file prima di rimuovere elementi sospetti. Chi non dispone delle competenze necessarie dovrebbe coinvolgere un professionista nella risposta all’incidente.
Il WAF aiuta, ma non sostituisce la patch
Cloudflare ha distribuito regole WAF prima della divulgazione e afferma di avere osservato traffico d’attacco contro i propri clienti, inclusi payload modificati per tentare di aggirare le protezioni. Non pubblica però i volumi numerici di questo traffico.
Un firewall applicativo può bloccare tecniche conosciute e ridurre l’esposizione mentre si aggiorna. Le regole devono tuttavia seguire l’evoluzione degli attacchi e la copertura può dipendere dalla configurazione. Cloudflare stessa invita ad aggiornare PHP: il WAF è una difesa aggiuntiva, non una correzione del runtime.
Il 23 ottobre il progetto PHP ha inoltre pubblicato un avviso separato su CVE-2026-115560. Il problema può manifestarsi soltanto con una combinazione insolita: determinati gestori di serializzazione, un cambio effettuato dall’applicazione prima dell’avvio della sessione e la funzione di avanzamento degli upload attiva. La mitigazione temporanea suggerita per questo caso non sostituisce le patch contro le due vulnerabilità principali.
Il perimetro è più ampio del sito pubblico
PHP può essere presente in sottodomini dimenticati, siti di staging, pannelli interni, container, applicazioni legacy e prodotti che lo incorporano. Correggere soltanto il dominio principale può quindi lasciare esposto un ingresso secondario.
Il NCSC raccomanda di censire tutte le installazioni, dando priorità a quelle raggiungibili da Internet. Per ciascuna servono almeno una versione, un responsabile, un livello di esposizione e una procedura di aggiornamento. Gli ambienti inutilizzati andrebbero spenti o rimossi; quelli necessari devono ricevere patch e monitoraggio.
Se un sistema esposto non può essere aggiornato e non è possibile applicare rapidamente le mitigazioni temporanee, il NCSC suggerisce di valutarne la sospensione. La continuità del servizio conta, ma lasciare online un componente critico e non protetto può produrre un costo molto maggiore.
Cosa fare oggi, in ordine
La sequenza più utile è identificare il gestore di PHP, ottenere una conferma documentata della correzione, controllare tutti gli ambienti collegati e riesaminare la telemetria almeno dal 17 ottobre. Subito dopo conviene verificare backup recenti, separati dal server e realmente ripristinabili.
WordPress, temi e plugin devono comunque restare aggiornati, perché proteggono altri livelli della piattaforma. La lezione pratica di PHP2Shell è che la sicurezza del sito non coincide con la bacheca del CMS. Applicazione, runtime, hosting e procedure di recupero formano una sola catena: aggiornare soltanto l’anello più visibile non basta.