In questo articolo Indice dei contenuti 3 sezioni
Da poche ore gli attacchi contro WordPress hanno cambiato marcia, passando dalla semplice ricognizione allo sfruttamento vero e proprio di una falla critica che permette di scrivere file sul server e, in determinate condizioni, di eseguire comandi shell. Il bug è tracciato come CVE-2026-87902 e riguarda un path traversal non autenticato che può sfociare in esecuzione di codice remoto. La patch è arrivata con la versione 7.1.2, ma il tempo di reazione degli aggressori è stato impressionante: meno di cinque ore dal rilascio dell’aggiornamento e già si vedevano le prime richieste sospette in giro per il web. I primi tentativi malevoli sono stati osservati alle 17:44 UTC del 22 settembre, partiti da un gruppo ristretto di indirizzi IP e diretti contro più siti contemporaneamente. All’inizio si trattava solo di sondaggi, richieste costruite per includere normali file del core di WordPress, evidentemente con l’obiettivo di capire quali installazioni fossero vulnerabili. Poi il traffico legato alla vulnerabilità si è moltiplicato per dieci e ha iniziato a includere una fase di scrittura su disco.
Come funziona la falla e quali configurazioni sono a rischio
La vulnerabilità, individuata dal ricercatore Robert Ressl, ha ricevuto una valutazione di gravità critica con punteggio 9.2 su 10. Il problema sta nella risoluzione dei template di pagina: un attaccante non autenticato può far sì che la funzione getpagetemplate includa un file .php locale leggibile che si trova fuori dalle directory del tema attivo. Detto in modo più diretto, il server viene convinto a caricare qualcosa che non dovrebbe caricare. Perché si arrivi all’esecuzione di codice remoto servono però alcune condizioni precise. Il tema attivo, che sia parent o child, deve avere una directory di primo livello con un nome che inizia per page-, tipo page-templates. Poi serve un file .php locale che esista davvero e sia leggibile dall’account del web server. L’avviso ufficiale porta come esempio pearcmd.php, utile quando l’impostazione registerargcargv di PHP è attiva.
Due scenari molto diffusi rientrano nel quadro: l’immagine ufficiale di PHP per Docker risulta interessata, e lo stesso vale per la configurazione di default di cPanel quando si usa una versione di PHP precedente alla 8.5. Non si tratta quindi di casi di nicchia.
Payload, file sospetti e IP da bloccare
La terza fase degli attacchi sostituisce config-show con config-create, e a quel punto pearcmd scrive un file dove gli viene indicato, con contenuto scelto dall’attaccante. Alcuni payload si limitano a lasciare una stringa che marca l’host come sfruttabile tramite CVE-2026-87902, una specie di segnalibro per tornarci dopo. Altri però scrivono un tag breve che esegue un comando shell nel momento in cui il file viene aperto, e lì l’intento malevolo è fuori discussione.
I file finiscono in /tmp e /var/tmp con nomi come wp-pear-rce-flag.php, poc87902.php, luci.php e zeta.php. Le sonde osservate usano sequenze di traversal con doppia codifica nel parametro pagename, accompagnate da un page_id valido. Gli indirizzi da inserire in blocklist sono 169.58.48.193, 169.58.48.195 e 2001:df1:e8c0::106b.
Cosa devono fare gli amministratori adesso
L’aggiornamento a WordPress 7.1.2 resta la mossa prioritaria. Vista la gravità, le correzioni sono state portate indietro su tutti i rami fino alla 4.7, mentre le release precedenti alla 4.6 non riceveranno alcuna patch per questa falla. Chi gestisce siti fermi su versioni così datate si trova quindi scoperto senza alternative dirette. Oltre all’aggiornamento, conviene passare al setaccio i log alla ricerca di attività sospette, controllando in particolare le richieste con parametri pagename anomali e la presenza dei file citati nelle directory temporanee. Lo sfruttamento attivo è in corso e la finestra utile per intervenire si è già ristretta parecchio.
Fonte: TecnoAndroid
