Continuano gli attacchi PHP2Shell, senza casi WordPress confermati
I tentativi di sfruttamento di PHP2Shell continuano, ma Wordfence afferma di non essere a conoscenza di compromissioni WordPress confermate attraverso le due falle critiche di PHP al 28 ottobre 2026. PHP è il linguaggio di programmazione su cui viene eseguito WordPress. L'assenza di un caso confermato non rende sicuro un server privo di patch: è necessario installare PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure un pacchetto del vendor di cui sia stata confermata l'inclusione di entrambe le correzioni, e quindi riavviare PHP.
PHP2Shell è il soprannome di CVE-2026-109618 e CVE-2026-109619. A ciascuna è stato assegnato un punteggio di 9,2 su 10 secondo CVSS v4.0, una scala standard per valutare la gravità delle vulnerabilità. Entrambe le falle possono consentire una remote code execution senza autenticazione, ossia permettere a qualcuno che non ha effettuato l'accesso di eseguire il proprio codice sul server. Una falla riguarda il modo in cui PHP gestisce una richiesta che esaurisce la memoria disponibile. L'altra coinvolge un processo PHP che conserva dati provenienti da una richiesta completata, dati che una richiesta successiva può utilizzare impropriamente. Si tratta di vulnerabilità di PHP stesso, non di WordPress, di un theme o di un plugin.
Wordfence ha analizzato i log di oltre 5 milioni di siti protetti e ha dichiarato che i suoi team addetti alla pulizia dei siti e alla risposta agli incidenti non avevano gestito alcuna violazione di WordPress attribuita a una delle due vulnerabilità. Una regola di monitoraggio dedicata ha registrato circa 77.600 richieste correlate provenienti da più di 2.000 indirizzi IP tra il 23 e il 27 ottobre. Wordfence ha esaminato ogni corrispondenza e ha individuato segnali di attacchi, strumenti di scansione che si identificavano come tali o altri test automatizzati, anziché normale attività di visitatori o siti web. Il 22 ottobre ha inoltre osservato 27 indirizzi IP coordinati, 26 dei quali hanno iniziato a inviare richieste nell'arco di 13 minuti.
Le richieste tentavano di eseguire comandi per verificare se lo sfruttamento avesse funzionato, estrarre password di database e altri dati segreti dai file di configurazione wp-config.php e .env e creare backdoors nelle directory di upload, plugin o theme. Una backdoor è un file o meccanismo nascosto che consente a un intruso di tornare successivamente. Più raramente, le richieste tentavano di scaricare ed eseguire ulteriore codice dannoso. Queste registrazioni mostrano le intenzioni degli aggressori, non l'avvenuta esecuzione con successo. Anche Amazon ha segnalato tentativi contro honeypots, sistemi-esca utilizzati per osservare gli attacchi, prima della divulgazione pubblica del 21 ottobre. Wordfence ha rilevato strumenti creati per queste falle circa quattro ore prima della divulgazione.
Le segnalazioni esterne a WordPress restano importanti, ma contengono questioni irrisolte. Dream ha dichiarato che un aggressore ha adattato PHP2Shell a una piattaforma firewall non specificata, utilizzando poi una falla di privilege escalation del kernel Linux per assumere il pieno controllo di 24 firewall esposti a internet e di un server di gestione interno. Dream ha affermato che l'aggressore ha estratto la password di un account di servizio LDAP, utilizzato per accedere a una directory centrale degli utenti, e ha enumerato utenti e gruppi in un ambiente affiliato al governo degli Stati Uniti. Il resoconto pubblico non identificava il vendor né forniva gli artefatti recuperati, e Wordfence ha dichiarato di non averlo verificato in modo indipendente. Separatamente, Palo Alto Networks ha segnalato attività di sfruttamento contro interfacce di gestione PAN-OS esposte a internet, senza collegare tale attività alla segnalazione di Dream.
Il 27 ottobre Wiz ha riferito che nessuno dei tentativi osservati era stato completato con successo e ha affermato che le prove pubbliche più solide da essa esaminate riguardavano lo sfruttamento riuscito di honeypots. Il 28 ottobre Morphisec ha segnalato l'esecuzione di codice sul server Windows di un cliente che utilizzava IIS, il software web server di Microsoft, e PHP-CGI, un metodo per eseguire PHP per le richieste web. Il suo resoconto pubblico non riguardava WordPress e non forniva dettagli tecnici sufficienti perché Wordfence potesse verificare in modo indipendente che l'incidente fosse stato causato da PHP2Shell.
Uno sfruttamento affidabile sembra dipendere dalla configurazione del sistema preso di mira. Wordfence ha scoperto che un exploit di prova eseguiva codice in una build PHP configurata appositamente, ma si limitava a provocare un crash in una normale build ottimizzata della stessa versione. Wiz ha segnalato errori in fasi diverse su differenti configurazioni server, mentre Hacktron ha rilevato che un exploit funzionante in un ambiente richiedeva modifiche sostanziali per funzionare in un altro. Tra i fattori rilevanti figurano la build PHP, le estensioni installate, i limiti di memoria, la gestione delle richieste e ASLR, ossia Address Space Layout Randomization, che modifica la posizione in cui un programma archivia i dati in memoria, rendendo più difficile per un aggressore prevedere dove colpire. Su Linux, gli amministratori possono eseguire cat /proc/sys/kernel/randomize_va_space; un risultato pari a 2 indica una randomizzazione completa. Questi ostacoli possono impedire uno sfruttamento su vasta scala, ma non sostituiscono l'installazione delle patch.
Secondo il security advisory di PHP, è a rischio ogni installazione PHP che gestisce richieste web, incluse PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Un'installazione WordPress aggiornata può quindi restare esposta perché l'aggiornamento di WordPress non aggiorna PHP. In WordPress, Strumenti, Salute del sito, Informazioni, Server mostra la versione che sta effettivamente gestendo il sito, che può essere diversa dal risultato di php -v in un prompt dei comandi. Una versione apparentemente meno recente non è sempre una prova conclusiva, perché le distribuzioni Linux e i vendor con supporto a lungo termine talvolta aggiungono correzioni di sicurezza senza modificare il numero della versione principale. In tal caso, l'hosting provider o il vendor deve confermare che il proprio pacchetto contenga entrambe le correzioni.
Su hosting gestiti o condivisi, i proprietari dei siti dovrebbero chiedere se il servizio PHP del loro specifico account dispone delle patch per entrambe le CVE ed è stato riavviato. Gli amministratori di un proprio server o virtual private server, ossia un ambiente server a noleggio, dovrebbero crearne un backup, installare i pacchetti aggiornati e riavviare Apache, PHP-FPM o il servizio PHP pertinente, affinché i vecchi processi non conservino codice vulnerabile. I container devono essere ricostruiti e nuovamente distribuiti a partire da un'image aggiornata. Le organizzazioni dovrebbero controllare gli ambienti pubblici, di staging e meno recenti, anziché esaminare soltanto il sito principale.
PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP, quindi gli utenti necessitano di una correzione fornita da un vendor oppure di un upgrade. Alcune distribuzioni Linux e alcuni vendor con supporto a lungo termine hanno aggiunto correzioni alle versioni meno recenti, mentre il team di sicurezza PHP ha pubblicato patch minime per il codice sorgente di PHP 7.4, 8.0 e 8.1. Una release supportata rappresenta la scelta migliore a lungo termine. PHP 8.2 raggiungerà l'end of life il 31 dicembre 2026, quindi PHP 8.3 o una versione successiva evita un'altra migrazione a breve termine.
I proprietari dei siti dovrebbero cercare file PHP sconosciuti in wp-content/uploads e nelle cartelle di plugin o theme, in particolare file creati il 17 ottobre o successivamente. Tra gli altri segnali di allarme figurano account amministratore sconosciuti, file di configurazione modificati, cron jobs imprevisti, ossia attività pianificate per essere eseguite automaticamente, connessioni in uscita inspiegabili, ripetuti crash di PHP, upload di moduli insolitamente grandi o un processo web che avvia una command shell. È necessario conservare i backup e i log di web server, PHP, firewall e sistema almeno dal 17 ottobre fino al riavvio del servizio PHP aggiornato con le patch. Un log apparentemente pulito non dimostra che non sia accaduto nulla.
Se emergono elementi sospetti, creare innanzitutto un backup dello stato attuale del sito per preservare le prove.