WordPress 7.1.2 corregge CVE-2026-87902: path traversal pre-auth fino alla RCE

🛡️ Executive Summary

• WordPress corregge CVE-2026-87902, path traversal pre-authentication nel Core con punteggio CVSS 9,2.
• La falla può includere file PHP locali esterni al tema e, con specifiche precondizioni, evolvere in remote code execution.
• WordPress 7.1.2 e i backport fino alla serie 4.7 correggono il problema: anche chi aveva installato 7.1.1 deve aggiornare.

WordPress 7.1.2 arriva appena cinque giorni dopo la release di sicurezza 7.1.1 e corregge una vulnerabilità completamente distinta, molto più delicata per le installazioni che soddisfano determinate condizioni lato server. CVE-2026-87902, valutata CVSS 9,2, consente a un attaccante remoto privo di autenticazione di manipolare la risoluzione dei page template e fare includere a WordPress un file PHP locale leggibile, anche se collocato fuori dalle directory del tema attivo. L’inclusione non produce automaticamente esecuzione di codice in ogni installazione, ma può trasformarsi in RCE senza login né interazione dell’amministratore quando coincidono specifiche caratteristiche del tema e della configurazione PHP.

CVE-2026-87902 rompe il confine delle directory del tema

La vulnerabilità risiede nel meccanismo utilizzato da WordPress per individuare i template delle pagine. Secondo il security advisory ufficiale GHSA-7hp8-65ch-5whp, un utente non autenticato può influenzare get_page_template() fino a fare includere un file .php locale scelto dall’attaccante e leggibile dal processo web, anche quando quel file si trova all’esterno delle directory consentite del tema padre o child. Il problema è classificato come CWE-98, improper control del filename utilizzato da include o require. La distinzione rispetto alle normali vulnerabilità di file inclusion è importante. WordPress non consente di caricare direttamente un payload remoto attraverso CVE-2026-87902: l’attaccante deve individuare sul server un file PHP già presente e sfruttabile come bersaglio. La possibilità di arrivare alla code execution dipende quindi dall’ambiente. È una superficie diversa da Click2Shell, corretto pochi giorni prima nel Core, dove l’attacco richiedeva invece l’interazione di un amministratore autenticato e la concatenazione con una seconda vulnerabilità.

Leggi anche: WordPress Click2Shell installa temi senza consenso e può arrivare alla RCE

Tema e configurazione PHP decidono se la falla diventa RCE

L’advisory WordPress individua due prerequisiti principali. Il tema attivo, parent o child, deve innanzitutto contenere nella propria root una directory il cui nome inizi con page-, come page-templates. La condizione riguarda anche vecchi temi ufficiali come Twenty Twelve e Twenty Fourteen e, secondo la disclosure, temi di terze parti diffusi come Neve, Hestia e Sydney. In secondo luogo deve esistere sul server un file PHP leggibile che possa essere trasformato in una primitiva di esecuzione. Il caso descritto più esplicitamente riguarda pearcmd.php. Se il componente PEAR è disponibile e register_argc_argv è impostato su On, il file può diventare parte di una catena che converte la local file inclusion in RCE. WordPress segnala che la configurazione interessa, tra gli altri scenari, l’immagine PHP ufficiale utilizzata nei container Docker e le configurazioni predefinite di cPanel con PHP precedente alla versione 8.5. Non significa che qualsiasi container WordPress o server cPanel sia automaticamente compromettibile: significa che la combinazione di tema compatibile, file utilizzabile e configurazione PHP vulnerabile elimina le barriere che separano l’inclusione locale dall’esecuzione di codice. Il precedente WP2Shell analizzato a luglio aveva già mostrato perché le vulnerabilità nel Core debbano essere valutate in base alle catene realmente costruibili, non soltanto alla singola primitiva tecnica.

Anche WordPress 7.1.1 resta vulnerabile e deve essere aggiornato

WordPress ha pubblicato il 22 settembre la release di sicurezza 7.1.2 e raccomanda l’aggiornamento immediato. Sono interessate tutte le release supportate comprese tra WordPress 4.7.0 e 7.1.1. Le versioni corrette comprendono 7.1.2, 7.0.6, 6.9.9, 6.8.10 e relativi backport fino alla 4.7.37. Il dato operativo più rilevante è proprio la presenza di 7.1.1 tra le versioni vulnerabili. Chi aveva aggiornato il sito dopo il security release del 17 settembre non è quindi protetto contro CVE-2026-87902. Quella release aveva corretto undici problemi differenti; la nuova vulnerabilità è stata affrontata con un aggiornamento separato. WordPress mantiene inoltre la politica di backport delle correzioni sui rami ancora eleggibili agli update di sicurezza, ma ricorda che soltanto la release più recente viene considerata pienamente supportata. La frequenza degli interventi sul Core è diventata significativa: WordPress 7.0.3 aveva già corretto XSS2Shell e altre vulnerabilità, mentre la successiva 7.0.4 aveva chiuso una RCE autenticata legata all’interazione tra upload, Imagick e Ghostscript.

Continua con:

WordPress sotto pressione: cinque falle critiche aprono a takeover e RCE

WordPress blocca gli update plugin ad alto rischio con nuovi controlli sulla supply chain

La remediation deve partire dal Core, non dal tentativo di filtrare il payload

Per gli amministratori la misura corretta è aggiornare WordPress alla release corretta del proprio ramo, preferibilmente alla 7.1.2 quando l’ambiente lo consente. Tentare di mitigare il problema intervenendo soltanto sul tema o disabilitando register_argc_argv può ridurre specifiche catene note, ma non sostituisce la correzione del difetto di path resolution nel Core. Nei siti Internet-facing rimasti sulle versioni vulnerabili è utile verificare inoltre file PHP inattesi, modifiche al filesystem, processi generati dal web server e richieste anomale dirette alle pagine che utilizzano template personalizzati. Al momento della disclosure ufficiale WordPress non indica exploitation attiva in the wild, quindi CVE-2026-87902 non deve essere presentata come una falla già sfruttata. Il rischio resta però elevato perché non richiede autenticazione, il dettaglio tecnico è pubblico e la vulnerabilità interessa un arco di versioni che risale fino a WordPress 4.7. La disponibilità immediata della patch rende quindi il rinvio dell’aggiornamento il fattore di esposizione più facilmente eliminabile.