La 7.1.1 non basta
Il tuo WordPress è alla 7.1.1? Allora non sei al sicuro, anche se hai aggiornato da poco. CVE-2026-87902 ha un punteggio CVSS di 9,2 e riguarda il core, in tutte le versioni supportate dalla 4.7.0 alla 7.1.1. La correzione è arrivata il 22 settembre con la 7.1.2, cinque giorni dopo la release di sicurezza 7.1.1. Esistono patch anche per i rami più vecchi: 7.0.6, 6.9.9, 6.8.10, più backport fino alla 4.7.37.
Come funziona
Il problema sta nel modo in cui WordPress sceglie il template di una pagina. Chi attacca non ha bisogno di un account: può influenzare quel meccanismo e far includere un file PHP a sua scelta, anche fuori dalla cartella del tema. Includere significa che il server esegue quel file come codice. Il termine tecnico è local file inclusion. C'è però un limite: l'attaccante non può caricare un file da remoto. Serve un PHP già presente sul server e leggibile dal web server.
Quando diventa esecuzione di codice
Non tutti i siti sono esposti allo stesso modo. Per arrivare alla RCE, cioè all'esecuzione di comandi da remoto, secondo l'advisory servono due condizioni. La prima: il tema attivo (o il suo tema genitore) ha in radice una cartella il cui nome inizia con page-, per esempio page-templates. Tra i temi citati ci sono Twenty Twelve e Twenty Fourteen, oltre a Neve, Hestia e Sydney. La seconda: sul server c'è un file PHP sfruttabile. Il caso descritto è pearcmd.php, che funziona se PEAR è presente e register_argc_argv è attivo. È una configurazione che si trova, tra l'altro, nell'immagine Docker ufficiale di PHP e in molte installazioni cPanel predefinite con PHP precedente alla 8.5. Non ogni container o server cPanel è quindi vulnerabile. Senza queste condizioni la falla resta un'inclusione di file, non una presa di controllo garantita.
Sfruttamento e cosa fare
Al momento della divulgazione non risultano attacchi in corso. Ma il dettaglio tecnico è pubblico e non serve autenticazione: la finestra per aggiornare è breve. Installa la versione corretta per il tuo ramo, meglio la 7.1.2. Cambiare tema o disattivare register_argc_argv può interrompere le catene di attacco note, ma non sostituisce la patch. Se non puoi aggiornare subito, cerca file PHP inattesi, modifiche al filesystem, processi lanciati dal web server e richieste strane verso pagine con template personalizzati.
💬 Il mio commento
Prima una precisazione, perché in giro si legge già di exploit a poche ore dalla patch. Per quanto ho verificato non è così: la fonte parla di nessuno sfruttamento attivo segnalato. La fretta va bene, il panico meno. Detto questo, non è che mi tranquillizzi molto: dettaglio pubblico, nessun login richiesto, e scrivere un exploit da una descrizione così è questione di poco. Mi colpisce soprattutto la 7.1.1. Chi aveva aggiornato con puntualità alla release di sicurezza di cinque giorni prima si ritrova di nuovo indietro. Ed è il momento in cui si scopre chi ha gli aggiornamenti di sicurezza automatici e chi ha un sito che «lo aggiorna l'agenzia che l'ha fatto», magari non più raggiungibile.
Quello che secondo me rende questa falla interessante è che non dipende solo da WordPress. Che diventi esecuzione di codice lo decidono il tema, la configurazione di PHP, un file come pearcmd.php rimasto lì perché era nell'immagine di partenza e nessuno se lo ricordava. Sui siti che seguo controllo tre cose: la versione, se il tema ha una cartella page-, e come è configurato PHP. Ammetto un dubbio: non so dire quanti siti siano davvero sfruttabili. Le condizioni restringono parecchio il campo, ma le immagini predefinite sono così diffuse che non mi fiderei della statistica. Casi come questo hanno in comune una cosa: il difetto sta nel core, ma a trasformarlo in incidente è tutto quello che c'è intorno, e di solito è roba che nessuno guarda da anni.