WordPress 7.1.2 corregge una vulnerabilità critica di path traversal
WordPress 7.1.2, rilasciato il 22 settembre 2026, corregge una vulnerabilità critica di path traversal non autenticato nel core di WordPress, identificata come CVE-2026-87902. La falla, con un punteggio CVSS v4.0 di 9.2 (Critico), può consentire a un aggressore senza account WordPress di forzare un sito a includere un file PHP leggibile al di fuori della directory del tema attivo. Sui siti il cui tema e server soddisfano determinate condizioni, ciò può portare all'esecuzione di codice remoto e al controllo completo del sito. Il team di sicurezza di WordPress ha inoltre rilasciato backport di sicurezza per ogni ramo fino a WordPress 4.7. Una tabella riassuntiva di Wordfence Intelligence ha classificato la falla come CVSS 8.1 (Alto) secondo una convenzione di punteggio, mentre l'avviso principale e la nota sulla patch utilizzano CVSS v4.0 9.2 (Critico).
Una vulnerabilità di path traversal è un modo per ingannare il software affinché legga un file al di fuori della cartella in cui dovrebbe operare, spesso utilizzando '..' in un percorso file. In questo caso, il core di WordPress non verificava correttamente che un nome di template risolvesse in un file all'interno della directory del tema attivo. Un aggressore che invia una richiesta appositamente creata a un sito vulnerabile può far includere a WordPress un file PHP locale scelto dall'aggressore. Questo è noto come inclusione di file locale. Se il file incluso è qualcosa come pearcmd.php, uno strumento a riga di comando incluso in alcune installazioni PHP, e il server ha register_argc_argv abilitato, l'inclusione può diventare esecuzione di codice remoto, il che significa che l'aggressore può eseguire i propri comandi sul server. L'avviso di WordPress nota che l'immagine Docker ufficiale di PHP e le configurazioni predefinite di cPanel su PHP precedente alla 8.5 possono esporre esattamente questa combinazione.
Lo sfruttamento non è automatico su ogni sito non aggiornato. L'avviso di WordPress identifica due condizioni principali. Innanzitutto, il tema padre o figlio attivo deve contenere una directory di primo livello il cui nome inizia con page-, ad esempio la cartella page-templates presente nei temi legacy Twenty Twelve e Twenty Fourteen, così come nei temi Neve, Hestia e Sydney. In secondo luogo, il server deve avere un file PHP leggibile che produca un comportamento utile quando incluso, come pearcmd.php con register_argc_argv abilitato. I siti che non soddisfano entrambe le condizioni potrebbero non essere immediatamente sfruttabili per l'esecuzione di codice remoto, ma il path traversal sottostante rimane presente nel core di WordPress fino all'applicazione dell'aggiornamento. I soli nomi dei temi non sono sufficienti per valutare l'esposizione perché l'avviso non elenca gli intervalli di versioni dei temi interessati; gli amministratori dovrebbero controllare direttamente la struttura delle directory del tema installato e i file del server.
La causa tecnica risiede nel modo in cui WordPress risolve i template di pagina. Nelle versioni vulnerabili, la funzione get_page_template() legge la variabile di query pubblica pagename e le applica un ulteriore urldecode() prima di costruire un candidato template denominato page-{$pagename}.php. Poiché WordPress decodifica già una volta i parametri della richiesta, un aggressore può codificare doppiamente i caratteri di traversal come '..' in modo che vengano decodificati solo più tardi durante la risoluzione del template. Il candidato risultante viene quindi passato a locate_template(), che unisce il candidato al percorso del tema attivo e controlla se il file esiste, ma non verifica che il percorso finale rimanga all'interno di una directory del tema approvata. Questa combinazione consentiva a una richiesta di pagina appositamente creata di uscire da una directory page-* compatibile e indirizzare WordPress verso un file PHP altrove sul server. Wordfence ha attribuito a Robert Ressl la scoperta e la divulgazione responsabile della falla, e ha riprodotto il comportamento su WordPress 7.1.
La correzione aggiunge due livelli di protezione. get_page_template() ora convalida il nome pagina decodificato con la funzione validate_file() di WordPress prima di creare un candidato template, rifiutando la sintassi di traversal utilizzata nell'attacco. Inoltre, locate_template() ora passa i candidati esistenti attraverso un nuovo controllo chiamato _wp_is_template_path_allowed(). Quando un percorso contiene componenti di traversal, WordPress risolve la sua posizione canonica e conferma che rimanga all'interno di una directory di tema approvata o di compatibilità del tema prima di caricarlo. Il primo controllo chiude il percorso di richiesta specifico, mentre il secondo fornisce una difesa in profondità per altre funzioni e filtri del core che possono fornire nomi di template.
Poiché il rilascio di sicurezza del 22 settembre copre molti rami precedenti, gli intervalli di versioni interessati sono specifici per ramo. Un'affermazione generica come WordPress 7.1.1 e precedenti sarebbe errata, perché esistono backport per rami precedenti anche se i loro numeri di versione sono inferiori a 7.1.1. Le versioni corrette sono: 7.1.2 per la serie 7.1, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 e 4.7.37. WordPress.org afferma che solo la versione più recente della serie 7.1 è attivamente mantenuta; le correzioni precedenti sono backport di sicurezza di cortesia. I siti su un ramo precedente dovrebbero applicare immediatamente l'aggiornamento disponibile e pianificare un aggiornamento a una versione attualmente mantenuta.
I clienti Wordfence Premium, Wordfence Care e Wordfence Response hanno ricevuto la protezione firewall contro CVE-2026-87902 il 22 settembre 2026, lo stesso giorno in cui sono state rilasciate la vulnerabilità e gli aggiornamenti. Gli utenti Wordfence Free riceveranno la stessa regola il 22 ottobre 2026, dopo il consueto ritardo di 30 giorni. La regola firewall rileva la sintassi di traversal nell'input pagename, inclusa la forma codificata che rimane dopo il primo passaggio di decodifica del firewall. La protezione firewall riduce l'esposizione ma non sostituisce l'aggiornamento del core di WordPress.
I proprietari dei siti dovrebbero controllare la versione di WordPress su ogni sito che gestiscono, aggiornare alla 7.1.2 o alla versione corretta per il proprio ramo, e quindi confermare che l'aggiornamento sia effettivamente completato. Gli aggiornamenti automatici in background non sempre riescono. Se l'aggiornamento immediato è impossibile, confermare che una regola firewall adeguata sia attiva e pianificare l'aggiornamento del core il prima possibile. Esaminare i log del server web e del firewall per richieste sospette con valori simili a traversal nel parametro pagename. Se una qualsiasi richiesta ha raggiunto il percorso template vulnerabile, trattare il sito come potenzialmente compromesso e avviare una risposta completa agli incidenti: esaminare gli account amministratore, i plugin installati o modificati di recente, le attività pianificate e i file PHP inattesi. Le fonti primarie includono l'avviso di sicurezza del core di WordPress GHSA-7hp8-65ch-5whp, il changeset 63792 del core di WordPress e l'archivio delle versioni di WordPress. Per i proprietari di siti che preferiscono avere aggiornamenti tempestivi del core di WordPress, configurazione del server rafforzata e backup automatici gestiti da un fornitore, l'hosting WordPress gestito come AEU Hosting (albhosting.eu) è un modo per ridurre la finestra tra un rilascio di sicurezza e un sito aggiornato, ma la responsabilità di verificare l'aggiornamento spetta comunque al proprietario del sito.