WordPress 7.1.2 corregge la falla critica già attaccata

WordPress ha pubblicato il 22 settembre 2026 la versione 7.1.2 come aggiornamento di sicurezza per una falla critica nella scelta dei template di pagina. In determinate condizioni, una richiesta senza autenticazione può indurre il sito a includere un file PHP locale leggibile fuori dalle directory del tema attivo. Per chi amministra un’installazione, la prima verifica è la versione del core effettivamente in uso: la correzione è disponibile anche per i rami precedenti.

Nel resoconto di Patchstack sugli attacchi osservati, il primo tentativo bloccato risale alle 11:49 UTC del 22 settembre 2026; alle 15:34 compare un tentativo di scrivere un file tramite PEAR. Il 23 settembre il traffico rilevato comprendeva strumenti di scansione pubblici e più richieste rivolte a quella tecnica. Si tratta di attività osservata contro i siti, non della prova che ogni installazione raggiunta sia stata compromessa: versione, tema, configurazione e tracce locali determinano il rischio concreto.

Quale versione installare sul proprio ramo

L’avviso di sicurezza di WordPress identifica la falla come CVE-2026-87902 ed elenca tra le versioni corrette 7.1.2, 7.0.6, 6.9.9 e 6.8.10, con retroporti fino a 4.7.37. La verifica va fatta all’interno del ramo installato: una versione precedente alla sua specifica release corretta resta esposta. Il numero 7.1.2 è quindi il riferimento per il ramo 7.1, ma non è l’unica patch disponibile.

Nella bacheca di WordPress, la sezione Aggiornamenti mostra la versione corrente e consente di avviare l’installazione. Dopo l’update, occorre rileggere quel numero sul sito in produzione e confrontarlo con la release corretta del proprio ramo; avere gli aggiornamenti automatici attivi non dimostra che l’operazione sia già terminata. In un’installazione multisito, il core si aggiorna dall’amministrazione della rete, non dalla bacheca del singolo sito.

Il confronto riguarda il core e non la versione del tema o di un plugin. Se l’hosting gestisce gli aggiornamenti, il dato utile è comunque la release che l’installazione sta eseguendo, non quella promessa dal servizio. Conservare l’ora dell’aggiornamento aiuta inoltre a delimitare il periodo dei log da esaminare: le richieste precedenti alla patch restano rilevanti anche quando la versione corrente è corretta.

Perché tema e server cambiano l’esito dell’attacco

La catena descritta pubblicamente passa dalla risoluzione di un template per una pagina valida. Nel tema figlio attivo, o nel suo tema genitore, deve esistere nella directory principale una cartella il cui nome inizi con page-; page-templates è un esempio. L’avviso cita tra i temi che presentano questa struttura Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney. Il controllo riguarda i file realmente installati: la presenza della cartella è una condizione della tecnica, non un indizio di manomissione del tema.

La richiesta deve inoltre far arrivare alla selezione del template il percorso di un file PHP locale esistente e leggibile dal processo web. È così che l’inclusione può uscire dalle directory del tema. Il file preso di mira e i permessi del server contano quanto la struttura del tema: una pagina che non raggiunge quel percorso, oppure un file non leggibile, interrompono la sequenza specifica.

Inclusione di un file ed esecuzione di codice remoto non sono lo stesso esito. La tecnica documentata con pearcmd.php richiede che PEAR sia presente e leggibile, che register_argc_argv sia attivo nel PHP che serve il sito e, per creare un file, che la destinazione sia scrivibile. La configurazione PHP della riga di comando può differire da quella del servizio web. Disattivare una di queste condizioni può fermare la tecnica PEAR descritta, mentre l’aggiornamento del core corregge il percorso vulnerabile.

Le richieste da cercare nei log HTTP

Il segnale più specifico è una richiesta che combina page_id e pagename, con un valore di pagename contenente sequenze codificate di attraversamento delle directory, come %2e%2e o %252e%252e. Negli attacchi osservati compaiono anche valori che iniziano con templates%2f e riferimenti a pearcmd, config-show o config-create. Una ricerca limitata a una sola grafia può perdere varianti con codifica doppia o lettere esadecimali maiuscole.

La ricerca deve comprendere richieste GET e POST, dirette sia alla radice del sito sia a index.php. I comuni access log possono registrare la richiesta POST senza conservarne il corpo: in quel caso il parametro sospetto potrebbe comparire nei log del firewall applicativo, del proxy o dell’hosting. Un accesso con quei parametri segnala un tentativo da esaminare, ma non ne stabilisce da solo il risultato.

Una risposta da una normale pagina che restituisce contenuti inattesi di un file del core, come dati OPML o RSS, fornisce un’indicazione più forte che l’inclusione sia avvenuta. Va confrontata con la richiesta completa e con lo stato del sito in quel momento. Anche un tentativo rivolto a un file apparentemente innocuo merita attenzione: può servire a verificare se il percorso vulnerabile è raggiungibile prima di tentare la scrittura di codice.

Il controllo dei file dopo la patch

Nel filesystem, le prime posizioni da esaminare sono /tmp e /var/tmp, destinazioni viste nei tentativi con PEAR. La verifica può estendersi alle directory scrivibili degli upload, delle cache, dei temi e dei plugin. File PHP inattesi o creati durante la finestra di esposizione vanno valutati per contenuto, proprietario e orario di modifica; un nome di file già noto non è una condizione necessaria, perché può essere scelto dall’attaccante.

Se emerge un file PHP scritto attraverso la richiesta o eseguito dal server, il problema supera la semplice presenza di una versione vulnerabile. Occorre allora esaminare gli account amministrativi, i file applicativi modificati e gli eventuali meccanismi che potrebbero mantenere l’accesso dopo l’aggiornamento. La patch chiude il percorso di inclusione nel core, ma un file introdotto durante la finestra di esposizione richiede una risposta all’incidente sul server interessato.