Gli attacchi PHP2Shell continuano, ma non è stata riscontrata alcuna violazione di WordPress
Gli attacchi PHP2Shell continuano, ma al 28 ottobre 2026 Wordfence non era a conoscenza di alcun sito WordPress compromesso tramite CVE-2026-109618 o CVE-2026-109619. I suoi team di pulizia dei siti e incident response non avevano gestito alcun caso WordPress attribuito a una delle due vulnerabilità. Questo riscontro non significa che un server privo di patch sia sicuro: l'azione necessaria resta aggiornare il linguaggio di programmazione PHP utilizzato dal sito e riavviare il servizio che lo esegue.
Le due vulnerabilità critiche di PHP hanno ricevuto ciascuna un punteggio di 9,2 su 10 secondo CVSS v4.0, una scala standard per valutare la gravità delle vulnerabilità di sicurezza. Entrambe possono consentire remote code execution senza autenticazione, ossia permettere a qualcuno che non ha effettuato l'accesso di eseguire il proprio codice sul server. Una vulnerabilità riguarda il modo in cui PHP gestisce una request che esaurisce la memoria disponibile. L'altra può lasciare i dati di una request completata in un processo PHP, consentendo a una request successiva di utilizzarli in modo improprio. Si tratta di vulnerabilità presenti in PHP stesso, non in WordPress, nei plugin o nei theme.
Wordfence ha dichiarato che una regola di monitoraggio dedicata ha registrato circa 77.600 request correlate, provenienti da oltre 2.000 indirizzi IP, tra il 23 e il 27 ottobre, sugli oltre 5 milioni di siti che contribuisce a proteggere. La sua analisi non ha trovato corrispondenze che assomigliassero alla normale attività dei visitatori o dei siti web. Le request contenevano indicatori di attacco, si identificavano come tool di scanning o sembravano test automatizzati. Il 22 ottobre è stato inoltre osservato un insieme coordinato di 27 indirizzi IP, 26 dei quali hanno avviato le proprie request nell'arco di 13 minuti. Queste request rivelano tentativi di attività, non indicano se il codice sia stato effettivamente eseguito.
Le request tentavano di verificare se fosse possibile eseguire comandi, estrarre password di database e altri dati segreti dai file wp-config.php e .env, installare file backdoor per mantenere l'accesso nelle directory di upload, plugin o theme e, meno frequentemente, scaricare ed eseguire ulteriore codice malevolo. Wordfence ha inoltre rilevato tool creati per queste vulnerabilità circa quattro ore prima della divulgazione pubblica del 21 ottobre. Anche Amazon ha segnalato tentativi contro i propri honeypots, sistemi esca utilizzati per osservare gli attacchi, prima della divulgazione.
Le segnalazioni al di fuori di WordPress restano discordanti. Dream ha dichiarato che un attaccante ha adattato un exploit PHP2Shell a una piattaforma firewall non specificata e ha poi utilizzato una vulnerabilità di privilege escalation del Linux kernel, che consente a un attaccante di ottenere maggiori autorizzazioni di sistema. Secondo Dream, l'attaccante ha assunto il pieno controllo di 24 firewall esposti a internet e di un server interno di management, ha estratto la password di un account di servizio LDAP e ha elencato utenti e gruppi in un ambiente affiliato al governo degli Stati Uniti. Dream non ha identificato il vendor né pubblicato gli artifact recuperati e Wordfence non aveva verificato l'incidente in modo indipendente. L'incidente non riguardava WordPress.
Palo Alto Networks ha segnalato separatamente un'attività di active exploitation diretta contro interfacce di management PAN-OS esposte a internet, senza collegarla al resoconto di Dream. Il 27 ottobre Wiz ha dichiarato che nessuno dei tentativi osservati aveva avuto successo e che le prove pubbliche più solide da essa esaminate riguardavano attacchi riusciti contro honeypots. Il 28 ottobre Morphisec ha segnalato code execution presso un cliente che utilizzava Windows, IIS e PHP-CGI, una configurazione in cui PHP elabora le web request tramite la Common Gateway Interface. Il suo resoconto pubblico non riguardava WordPress e non conteneva dettagli tecnici sufficienti perché Wordfence potesse verificare in modo indipendente che il responsabile fosse PHP2Shell.
Un'exploitation affidabile sembra dipendere in larga misura dal target. Nel laboratorio di Wordfence, il codice di test è stato eseguito contro una build PHP configurata appositamente, ma ha semplicemente causato il crash di una normale build ottimizzata della stessa versione. Wiz ha segnalato errori in fasi diverse su configurazioni diverse, mentre Hacktron ha rilevato che un exploit funzionante in un ambiente richiedeva modifiche sostanziali per un altro. Le build PHP, le extension, i limiti di memoria e la gestione delle request possono influire sul risultato. Anche Address Space Layout Randomization, o ASLR, modifica il punto in cui un programma memorizza i dati nella memoria, rendendo più difficile per un attaccante prevedere il target. Gli amministratori Linux possono eseguire cat /proc/sys/kernel/randomize_va_space; un risultato pari a 2 indica la randomizzazione completa. Questi ostacoli possono impedire un attacco, ma non correggono nessuna delle due vulnerabilità.
Le release PHP corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. L'advisory PHP afferma che ogni installazione che gestisce web request è a rischio, incluse PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP-FPM è un servizio che gestisce i processi PHP per i siti web. È accettabile anche un package del vendor, se il provider conferma che entrambe le correzioni sono state incluse. L'aggiornamento di WordPress non aggiorna PHP.
Negli hosting gestiti o condivisi, i proprietari dei siti dovrebbero chiedere se il servizio PHP del proprio account dispone delle patch per entrambe le CVE ed è stato riavviato. Gli amministratori del proprio server o virtual private server, comunemente chiamato VPS, dovrebbero eseguire un backup, installare i package aggiornati e riavviare Apache, PHP-FPM o il relativo servizio PHP, in modo che un vecchio processo non possa continuare a utilizzare codice vulnerabile. I container devono essere ricostruiti e distribuiti nuovamente a partire da un'image aggiornata. Le agenzie dovrebbero controllare gli ambienti di produzione, staging e quelli meno recenti, anziché limitarsi al sito pubblico principale.
WordPress mostra la versione PHP in Strumenti, Salute del sito, Informazioni e quindi Server. Tale valore può essere diverso dall'output di php -v in un command prompt. Il solo numero di versione potrebbe non essere sufficiente per chiarire la situazione, perché le distribuzioni Linux e i vendor con supporto a lungo termine a volte aggiungono patch di sicurezza senza modificare la versione principale. Chi visualizza un numero meno recente dovrebbe chiedere se quello specifico package contiene entrambe le correzioni.
Tra i segnali di allarme figurano file PHP sconosciuti in wp-content/uploads o nelle cartelle di plugin e theme, in particolare file creati il 17 ottobre o successivamente, account amministratore sconosciuti, attività pianificate inattese, connessioni in uscita inspiegabili, crash PHP ripetuti, upload di form insolitamente grandi oppure un processo PHP o web server che avvia una command shell. Conservare backup e log web, PHP, firewall e di sistema almeno dal 17 ottobre fino al completamento dell'applicazione delle patch e del riavvio di PHP. Un log apparentemente normale non dimostra che non sia accaduto nulla. Se emergono prove sospette, conservare il sito attuale come backup, cambiare la password del database e i dati segreti memorizzati in wp-config.php o .env e avviare una pulizia completa.
PHP 8.1 e le versioni precedenti non ricevono più release dal progetto PHP, quindi gli utenti interessati necessitano di una correzione fornita dal vendor o di un upgrade. Sono state pubblicate patch minime del codice sorgente per PHP 7.4, 8.0 e 8.1 e alcuni vendor con supporto a lungo termine potrebbero aggiungerle ai package meno recenti. PHP 8.2 raggiungerà la fine del ciclo di vita il 31 dicembre 2026, rendendo PHP 8.3 o una versione successiva il percorso di upgrade a più lungo termine descritto da Wordfence.
Una distinta vulnerabilità priva di patch, CVE-2026-115560, è stata divulgata il 23 ottobre. Si applica solo quando un'applicazione modifica il session data format di PHP durante l'esecuzione e avvia poi una sessione mentre session upload progress è abilitato.