// 2 CRITICAL · 6 ZERO-DAY · 8 CVE · 10 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
WordPress ha distribuito l'aggiornamento 7.1.2 il 22 settembre 2026 per chiudere CVE-2026-87902, una vulnerabilità critica nel core del CMS con punteggio CVSS 9.2

WordPress ha distribuito l'aggiornamento 7.1.2 il 22 settembre 2026 per chiudere CVE-2026-87902, una vulnerabilità critica nel core del CMS con punteggio CVSS 9.2. Il difetto consente a un attaccante non autenticato di deviare la risoluzione dei template di pagina verso file PHP arbitrari sul server tramite path traversal. L'esecuzione di codice remoto richiede condizioni specifiche: un tema con directory di primo livello che inizi con page- e PHP con register_argc_argv=On.

Punti chiave
  • Il difetto risiede in get_page_template(), che costruisce il nome file page-{value}.php da un componente URL senza sanificare le sequenze ../.
  • L'RCE richiede due condizioni cumulative: tema con directory page-* e PHP con register_argc_argv=On, impostazione predefinita su PHP <8.5 e nelle immagini Docker ufficiali.
  • Temi citati nell'advisory: Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney.
  • Non risultano exploit pubblici, attacchi confermati o entry CISA KEV al 22 settembre 2026.

Il meccanismo: traversal nella risoluzione template

Il codice vulnerabile si trova in get_page_template(), funzione centrale per la selezione del file PHP da caricare. L'advisory GHSA-7hp8-65ch-5whp documenta che la funzione interpola un valore derivato dal percorso URL nel pattern page-{value}.php senza sanitizzare le sequenze ../.

L'assenza di questo controllo permette a un attaccante di costruire richieste che puntino a file PHP al di fuori della gerarchia del tema attivo. La vulnerabilità è classificata come path traversal con possibile conseguenza di Local File Inclusion.

Secondo l'analisi di The Hacker News, la sanificazione su ../ esisteva in altri punti del flusso ma non era estesa al percorso di risoluzione del template di pagina. Questa inconsistenza è il cuore del problema.

Le condizioni per l'RCE: tema e ambiente PHP

WordPress ha comunicato che l'RCE richiede condizioni specifiche. L'advisory GitHub Security Lab le dettaglia con precisione.

La prima condizione riguarda il tema attivo: deve contenere una directory di primo livello il cui nome inizi con page-, come page-templates. L'advisory cita i temi legacy Twenty Twelve e Twenty Fourteen, oltre a temi di terze parti: Neve, Hestia e Sydney.

La seconda condizione riguarda l'ambiente PHP. L'inclusione di un file locale si traduce in RCE solo se il server dispone di un file PHP "utile" per l'attaccante. Il vettore documentato è la transizione PEAR→RCE tramite pearcmd.php, che richiede register_argc_argv=On.

Secondo l'advisory, questa impostazione è attiva di default su PHP precedenti alla versione 8.5 e nelle immagini Docker ufficiali di PHP. La stessa configurazione è predefinita su cPanel con PHP <8.5.

"An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to RCE." — GitHub Security Lab, advisory GHSA-7hp8-65ch-5whp

Versioni affette e distribuzione della patch

Ogni versione di WordPress dal 4.7.0 al 7.1.1 incluso è vulnerabile. La versione 7.1.1, distribuita il 17 settembre 2026, risulta anch'essa affetta.

Il rilascio 7.1.2 del 22 settembre 2026 include il fix completo. WordPress ha operato un backport a tutti i branch supportati, fino alla versione 4.7.37. L'assenza di workaround documentati rende l'aggiornamento l'unica azione disponibile.

Al 22 settembre 2026, non risultano exploit pubblici, dimostrazioni di concetto o segnalazioni di sfruttamento attivo. La vulnerabilità non compare nella directory Known Exploited Vulnerabilities di CISA.

Cosa fare adesso

  • Aggiornare immediatamente a WordPress 7.1.2 o alla versione più recente disponibile nel branch supportato; il backport è attivo dal ramo 4.7 in poi.
  • Verificare la versione installata: ogni release da 4.7.0 a 7.1.1 è vulnerabile.
  • Controllare se il tema attivo presenta una directory di primo livello che inizi con page-; in caso affermativo, l'urgenza dell'aggiornamento aumenta.
  • Verificare la configurazione PHP: register_argc_argv abilitato espone il server alla catena RCE completa.
  • Non esistono workaround o mitigazioni alternative all'aggiornamento.

Contesto e valutazione del rischio

La condizionalità dell'RCE ha una duplice lettura. Da un lato, limita tecnicamente la superficie di attacco: senza entrambe le condizioni, la vulnerabilità si riduce a path traversal con impatto contenuto. Dall'altro, le configurazioni documentate nell'advisory rappresentano scenari di deployment reali e diffusi.

PHP <8.5 con register_argc_argv=On è una combinazione presente su molti server in produzione. Le immagini Docker ufficiali di PHP mantengono questa impostazione per default, così come le configurazioni cPanel con versioni PHP precedenti alla 8.5. I temi con directory page-* includono non solo i legacy Twenty Twelve e Twenty Fourteen, ma anche temi commerciali popolari come Neve, Hestia e Sydney.

La sovrapposizione di queste due condizioni nell'installato WordPress non è quantificata nelle fonti disponibili. Tuttavia, la presenza di entrambe le condizioni su piattaforme diffuse suggerisce che la popolazione a rischio di RCE completa non sia trascurabile.

Il dato rassicurante è l'assenza di exploit noti e di entry KEV. Questo profilo di rischio, combinato con la disponibilità del backport, suggerisce una gestione ordinata dell'aggiornamento piuttosto che un'emergenza immediata. La finestra temporale tra scoperta e patch, unita all'assenza di sfruttamento osservato, offre margine operativo agli amministratori.

La vulnerabilità è stata scoperta e divulgata responsabilmente da Robert Ressl. L'advisory GitHub Security Lab conferma le condizioni tecniche senza smontare la valutazione del vendor: le precondizioni sono reali, misurabili e limitano l'exploitabilità in modo documentato.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. github.com
  3. hendryadrian.com
  4. infosectoday.io
  5. guardianmssp.com
  6. cybersecuritynews.com
  7. gbhackers.com
  8. bleepingcomputer.com