WordPress 7.1.2 corregge un'inclusione di file non autenticata

WordPress 7.1.2 è arrivato il 22 settembre 2026 come release di sola sicurezza con una sola correzione. Il fornitore di sicurezza Patchstack la definisce la patch di WordPress più grave da tempo. La falla è un'inclusione di file locali (LFI) non autenticata nel modo in cui WordPress risolve i template di pagina. LFI è un tipo di vulnerabilità che consente a un attaccante di far aprire a un'applicazione web un file locale che non dovrebbe essere accessibile. Questa può arrivare all'esecuzione di codice in remoto (RCE), il che significa che un attaccante remoto potrebbe alla fine eseguire il proprio codice sul server web interessato. Patchstack afferma che i suoi clienti sono protetti da una regola RapidMitigate, ma consiglia comunque di aggiornare alla versione più recente di WordPress disponibile.

La vulnerabilità è stata segnalata da Robert Ressl e riguarda WordPress Core dalla versione 4.7.0 alla versione 7.1.1. Ha un punteggio CVSS 4.0 di 9.2, una valutazione di gravità molto alta nel Common Vulnerability Scoring System, ed è classificata come CWE-98, una categoria per il controllo improprio del nome file usato in un'istruzione include. Il vettore CVSS completo è AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. È stato assegnato CVE-2026-87902. Poiché ogni ramo supportato fino alla 4.7 è interessato, quasi dieci anni di release sono vulnerabili, e non serve alcun account utente per lanciare l'attacco.

La causa tecnica risiede nella funzione get_page_template() in wp-includes/template.php. Quando WordPress renderizza una pagina, costruisce una lista di nomi file di template candidati dalla variabile di query pagename, che arriva direttamente dalla richiesta del browser. Una variabile di query è un'informazione inviata nell'indirizzo web che WordPress usa per decidere cosa mostrare. Accanto al codice vulnerabile, un altro candidato era già passato attraverso validate_file(), il controllo di WordPress per il path traversal, una tecnica che cerca di usare .. in un nome file per uscire da una cartella prevista. Il ramo pagename non aveva quel controllo. Nello specifico, WordPress costruiva un nome file nella forma page-{pagename}.php, quindi il payload di un attaccante deve proseguire da una directory che inizia con "page-" e deve terminare con .php perché l'estensione viene aggiunta. La precondizione pratica è un tema attivo con una directory di primo livello chiamata come page-templates, che i vecchi temi predefiniti e molti temi di terze parti popolari hanno. Una chiamata urldecode extra è ciò che trasforma uno slug a forma di traversal in un vero percorso del filesystem. Patchstack non ha pubblicato una richiesta di exploit funzionante.

L'inclusione di file locali di per sé non garantisce l'esecuzione di codice. Includere un file .php locale esegue qualunque cosa faccia quel file, ma per ottenere il controllo un attaccante ha bisogno di un file .php leggibile sul server che si comporti in modo utile quando viene incluso. Il candidato ben noto è pearcmd.php di PEAR, e questo diventa utile solo quando PHP è in esecuzione con register_argc_argv abilitato, un'impostazione che mette gli argomenti della riga di comando nelle variabili PHP. Quell'impostazione è attiva per impostazione predefinita nelle immagini Docker ufficiali di PHP, che sono ambienti server precompilati, e negli ambienti cPanel, un popolare pannello di controllo per l'hosting, su versioni PHP inferiori alla 8.5. Questo rende la condizione comune anziché insolita. L'inquadramento onesto è una catena condizionale: l'inclusione di file non autenticata è sempre possibile nella giusta condizione del tema, e l'esecuzione di codice segue quando la configurazione del server si allinea. I proprietari dei siti dovrebbero trattarla come critica a meno che non abbiano verificato che il proprio stack non soddisfi quelle condizioni.

WordPress ha rilasciato due modifiche nella 7.1.2. Primo, applica lo stesso controllo validate_file() al pagename decodificato prima di costruire il nome file del template. Secondo, e più importante, introduce un controllo di contenimento in una nuova funzione _wp_is_template_path_allowed(). Ogni template risolto deve ora superare un test: un percorso di file che esiste e non contiene .. è consentito, altrimenti il percorso reale viene risolto e deve trovarsi all'interno della directory stylesheet, della directory template o di theme-compat. Questa seconda modifica va oltre il bug segnalato e suggerisce che il team di sicurezza di WordPress ha trattato la risoluzione dei percorsi dei template come una classe di problemi anziché come un singolo caso.

La tempistica del rilascio è stata compressa. Il 22 settembre 2026 WordPress ha pubblicato la 7.1.2 con correzioni backportate per ogni ramo supportato fino alla 4.7. Lo stesso giorno sono stati pubblicati l'advisory GHSA-7hp8-65ch-5whp e assegnato CVE-2026-87902. Patchstack ha aggiunto il problema al suo database delle vulnerabilità e ha distribuito una regola RapidMitigate ai siti protetti. I proprietari dei siti dovrebbero aggiornare da Dashboard > Updates o scaricare da WordPress.org. Gli aggiornamenti automatici in background dovrebbero averlo già applicato. Poiché le correzioni sono state backportate, i siti più vecchi possono ricevere la correzione senza un salto di versione principale. Solo la versione più recente di WordPress rimane attivamente supportata, ed è quella su cui bisogna essere.

Se non puoi aggiornare immediatamente, due controlli riducono l'incertezza: conferma se il tuo tema attivo ha una directory di primo livello il cui nome inizia con "page-", e conferma se il tuo PHP ha register_argc_argv abilitato. Nessuno dei due controlli è una correzione, ma ti dicono quanto sei vicino al caso peggiore. Per i lettori che usano un host WordPress gestito come AEU Hosting, confermare con il fornitore che questo aggiornamento di sicurezza è stato applicato è un passo sensato, perché le piattaforme gestite generalmente gestiscono gli aggiornamenti del core dietro le quinte.