WordPress corregge una falla critica sfruttabile senza login: quando può portare a RCE

WordPress ha distribuito un aggiornamento di sicurezza urgente per correggere una vulnerabilità nei componenti Core del CMS che può essere sfruttata da remoto senza autenticazione. Il problema riguarda il meccanismo con cui WordPress individua il template PHP da utilizzare per visualizzare una pagina: manipolando opportunamente una richiesta HTTP, un aggressore può indurre la piattaforma a cercare e includere un file PHP locale situato fuori dalle directory del tema attivo.

La vulnerabilità è identificata come CVE-2026-87902 e GHSA-7hp8-65ch-5whp: WordPress le assegna una severità critica, con un punteggio CVSS pari a 9,2 su 10. Non servono account, cookie, sessioni amministrative o interazione da parte dell’utente; servono però alcune condizioni specifiche perché la falla di sicurezza possa trasformarsi in una vera Remote Code Execution (RCE) ovvero si traduca nell’esecuzione di codice arbitrario sul server della vittima.

La correzione è arrivata il 22 settembre 2026 con WordPress 7.1.2. Vista l’estensione temporale del problema, però, il team di sicurezza ha compiuto una scelta non comune: il fix è stato già portato su tutti i rami supportati, all’indietro fino addirittura a WordPress 4.7, pubblicato originariamente nel 2016. Sono quindi vulnerabili le versioni comprese tra WordPress 4.7 e 7.1.1, con apposite release correttive distribuite per ciascuna release.

Un problema che nasce nella scelta del template WordPress

Per capire la vulnerabilità bisogna osservare come WordPress decide quale file PHP usare quando deve visualizzare una pagina.

La funzione coinvolta è get_page_template(): in condizioni normali WordPress costruisce una lista ordinata di possibili template. Può partire dal template personalizzato associato alla pagina, passare a file come page-nomepagina.php e page-ID.php, per terminare con il generico page.php.

Il nome della pagina deriva anche dal parametro interno pagename: ed è proprio durante la sua elaborazione che emerge il problema.

Il ricercatore Robert Ressl, autore della scoperta, ha ricostruito una catena in cui una richiesta anonima fornisce contemporaneamente valori per pagename e page_id. WordPress può usare il page_id valido per individuare una pagina realmente pubblicata, mentre il valore malevolo di pagename rimane disponibile durante la successiva fase di selezione del template.

Manipolando il contenuto di pagename, un aggressore può attivare il classico meccanismo di path traversal: invece di restare confinata all’interno del tema, la ricerca del template può raggiungere altri punti del filesystem.

Come avviene l’esecuzione remota di codice su WordPress

Per arrivare alla condizione RCE, il ricercatore ha usato una tecnica già nota nel mondo PHP che coinvolge pearcmd.php, il punto di ingresso a riga di comando di PEAR.

PEAR, acronimo di PHP Extension and Application Repository, è un vecchio sistema di distribuzione di librerie PHP: non fa parte di WordPress e non è presente necessariamente su ogni server.

In particolari configurazioni, però, un aggressore può sfruttare il comportamento di pearcmd.php per impartire operazioni PEAR attraverso una richiesta web: la dimostrazione utilizza due richieste anonime.

Con la prima, la vulnerabilità WordPress serve per includere pearcmd.php; attraverso le funzionalità di configurazione offerte da PEAR viene quindi creato in una directory scrivibile un nuovo file contenente PHP controllato dall’attaccante.

Con la seconda richiesta, lo stesso difetto di WordPress è sfruttato nuovamente per includere il file appena generato. A quel punto il codice PHP viene interpretato dal server e la falla di sicurezza locale descritta al paragrafo precedente si trasforma in una Remote Code Execution.

Non è corretto dire che ogni installazione di WordPress vulnerabile permette una RCE

Il punteggio CVSS di 9,2 potrebbe facilmente portare a una conclusione eccessiva: “tutti i siti WordPress dalla versione 4.7 alla 7.1.1 permettono l’esecuzione remota di codice“. Non è affatto così.

La vulnerabilità nel Core è reale e permette, nelle condizioni descritte, di oltrepassare il confine delle directory del tema e includere file PHP locali. La RCE, come abbiamo visto, è invece condizionata dalla configurazione dell’ambiente.

Ressl specifica di non avere misurato quanto siano diffuse su Internet le configurazioni che soddisfano l’intera catena.

Una RCE con i privilegi del Web server è comunque più che sufficiente per provocare danni seri: a seconda dei permessi disponibili, un aggressore può leggere wp-config.php, recuperare le credenziali del database, accedere ai contenuti del sito, alterare file scrivibili, inserire backdoor o interrompere il servizio.

Quali versioni WordPress installare

Per il ramo più recente, la versione che mette al riparo da qualunque vulnerabilità nota è WordPress 7.1.2. WordPress ha pubblicato contemporaneamente patch anche per tutti gli altri branch interessati: 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, fino alle release dedicate ai rami 5.x e alle versioni 4.9.33, 4.8.32 e 4.7.37.

WordPress 4.6 e versioni precedenti non ricevono invece il backport di sicurezza.

Il team WordPress raccomanda di aggiornare immediatamente. La versione può essere installata normalmente da Bacheca, Aggiornamenti, Aggiorna ora; sui siti che consentono gli aggiornamenti automatici in background, il processo dovrebbe avviarsi automaticamente.