Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Meno di cinque ore. Tanto è bastato perché, dopo il rilascio del nuovissimo WordPress 7.1.2, comparissero in rete le prime richieste mirate alla falla appena corretta. Da allora la situazione è peggiorata in fretta. Gli attaccanti non si limitano più a sondare i siti: stanno sfruttando attivamente la vulnerabilità CVE-2026-87902 per scrivere sul disco file PHP malevoli, che eseguono comandi di shell quando vengono richiamati da remoto. Considerata la diffusione di WordPress, chi amministra un sito non aggiornato sta correndo un rischio concreto, e deve intervenire subito.
nota: questa vulnerabilità è distinta da quella denominata "Click2Shell" apparsa solo pochi giorni fa. Chi aveva già aggiornato a WordPress 7.1.1 per correggere quel problema deve ora aggiornare di nuovo a WordPress 7.1.2 per tutelarsi anche da questa nuova criticità.
CVE-2026-87902 è una vulnerabilità di tipo path traversal nel core di WordPress. Non richiede autenticazione e ha un punteggio di 9,2 su 10 sulla scala CVSS versione 4. L'aggressore non ha bisogno di un account e non serve alcuna interazione da parte di un utente loggato: l'attacco avviene via rete, con bassa complessità e senza privilegi.
Il difetto si trova in get_page_template(), la funzione che WordPress usa per scegliere il file del tema che deve visualizzare una pagina. Il nome del file cercato segue lo schema page-{valore}.php, e quel valore deriva in parte dall'URL. Il punto è che WordPress non lo faceva passare attraverso il proprio controllo contro le sequenze ../, lo stesso che il codice adiacente già utilizzava. Il risultato è che un attaccante può pilotare la ricerca e far includere un file PHP locale leggibile, situato fuori dalle directory del tema attivo.
La falla è stata scoperta dal ricercatore Robert Ressl, che l'ha segnalata privatamente a luglio 2026 tramite il programma HackerOne di WordPress. Contestualmente al rilascio della correzione, Ressl ha pubblicato un'analisi dettagliata, un proof of concept e un laboratorio di test autonomo.
La cronologia ricostruita da Patchstack non lascia margini di ottimismo. WordPress 7.1.2 esce il 22 settembre 2026 e le prime richieste malevole compaiono alle 17:44 UTC dello stesso giorno, provenienti da un piccolo gruppo di indirizzi IP. Nell'arco di una giornata il traffico si è moltiplicato per dieci, e gli aggressori sono passati dalla semplice ricognizione alla scrittura di file PHP malevoli nelle directory /tmp e /var/tmp. Quando vengono richiamati, questi file eseguono comandi di shell sul server.
Tra i nomi di file osservati figurano wp-pear-rce-flag.php, poc87902.php, luci_<casuale>.php e zeta_<casuale>.php. Gli attaccanti li creano sfruttando l'opzione config-create di pearcmd, che serve a scrivere su disco i tag PHP che eseguono i comandi.
La sola inclusione di un file locale non basta per ottenere l'esecuzione di codice da remoto. Servono alcune condizioni precise, e sono queste a determinare quanto un sito sia davvero esposto:
pearcmd.php, lo script da riga di comando di PEARregister_argc_argv deve essere attiva, perché la tecnica di esecuzione del codice nota dipende proprio da questaQuest'ultimo dettaglio è meno rassicurante di quanto sembri. register_argc_argv è disattivata per impostazione predefinita solo a partire da PHP 8.5, mentre nelle versioni precedenti è attiva. Il problema riguarda quindi anche l'immagine Docker ufficiale di PHP e le configurazioni predefinite di cPanel con PHP anteriore alla 8.5: una superficie d'attacco tutt'altro che marginale. Patchstack sottolinea comunque che queste condizioni non sono una soluzione. Indicano soltanto il grado di esposizione di un sito.
Sono vulnerabili tutte le versioni di WordPress dalla 4.7.0 alla 7.1.1, compresa la 7.1.1 rilasciata il 17 settembre per correggere un'altra falla ("Click2Shell"), estranea a questa.
Non esiste un'alternativa praticabile: l'unica difesa è l'aggiornamento. La correzione è stata riportata anche su 24 rami precedenti, dalla 7.0.6 fino alla 4.7.37. «Come cortesia, la correzione di sicurezza è stata riportata su tutti i rami idonei a ricevere aggiornamenti di sicurezza (attualmente fino alla 4.7). Ricordiamo che solo la versione più recente di WordPress è supportata attivamente», precisa WordPress. Le versioni anteriori alla 4.7 non ricevono la patch e vanno portate a una release supportata.
Se il tuo sito ha gli aggiornamenti automatici in background attivi, l'installazione avverrà da sola. Controlla comunque che sia andata a buon fine. In caso contrario, puoi aggiornare dalla Bacheca, alla voce Aggiornamenti, oppure scaricare il pacchetto da WordPress.org. Trattandosi di una piattaforma self-hosted, l'aggiornamento resta responsabilità di chi amministra il sito.
Aggiornare, però, non cancella un'eventuale compromissione già avvenuta. Conviene quindi controllare i log del server alla ricerca di sequenze di traversal con doppia codifica nel parametro pagename, accompagnate da un page_id valido. È utile anche verificare la presenza dei file sospetti citati sopra in /tmp e /var/tmp e bloccare gli indirizzi da cui è partito l'attacco:
169.58.48.193169.58.48.1952001:df1:e8c0::106bBloccare questi indirizzi è una misura utile ma di breve durata: gli IP cambiano, la falla resta. Con un proof of concept pubblico e un traffico decuplicato in ventiquattro ore, ogni sito ancora fermo alla 7.1.1 o precedente è un bersaglio in attesa del proprio turno.
Fonti: bleepingcomputer.com, daily.dev, hendryadrian.com, radar.offseq.com
