CVE-2026-87902: Difetto critico nel core di WordPress consente l’RCE non autenticato in determinate condizioni

WordPress ha rilasciato un aggiornamento di sicurezza d’emergenza che risolve una vulnerabilità critica nel suo software Core che può consentire a un attaccante non autenticato di caricare file PHP locali arbitrari e, in condizioni specifiche di server e tema, ottenere l’esecuzione di codice remoto. Seguita come CVE-2026-87902, la vulnerabilità riguarda le versioni di WordPress dalla 4.7.0 alla 7.1.1 e possiede un punteggio CVSS 4.0 di 9.2.

Il difetto risiede nella risoluzione dei modelli di pagina di WordPress. Un attaccante può manipolare il valore utilizzato da WordPress quando seleziona un modello di pagina e causare a get_page_template() di includere un file PHP leggibile al di fuori delle directory del tema attivo. Non è richiesto alcun account WordPress, cookie di autenticazione, interazione da parte dell’amministratore o plugin vulnerabile per l’attacco di inclusione di file sottostante.

L’esecuzione di codice remoto è condizionale piuttosto che universale. Il tema attivo deve contenere una struttura di directory compatibile, e il server deve esporre un file PHP leggibile adeguato che può essere utilizzato in modo improprio quando incluso. L’attacco dimostrato pubblicamente utilizzava pearcmd.php di PEAR in un ambiente in cui l’impostazione register_argc_argv di PHP era abilitata.

WordPress ha rilasciato la versione 7.1.2 il 22 settembre 2026, specificamente per affrontare la vulnerabilità e ha riportato le correzioni ai rami di sicurezza mantenuti fino a WordPress 4.7. Gli amministratori del sito sono fortemente consigliati di aggiornare immediatamente.

Contatta il reparto vendite

Analisi CVE-2026-87902

La vulnerabilità ha origine nel modo in cui WordPress Core risolve i modelli per le pagine. Quando un visitatore richiede una pagina, WordPress costruisce un elenco di potenziali nomi di file di modelli e cerca per un file corrispondente nel tema attivo.

Nelle versioni vulnerabili, i dati controllati dall’attaccante utilizzati durante questo processo non sono sufficientemente vincolati prima di essere incorporati nel percorso del modello di pagina. Una richiesta costruita ad arte può quindi introdurre sequenze di attraversamento delle directory e causare a WordPress di risolvere un file PHP che risiede al di fuori delle directory del tema attivo previste.

La chiave dettagli per CVE-2026-87902 sono che il primitivo principale è l’inclusione di file locali, non l’esecuzione arbitraria di codice incondizionata. WordPress descrive ufficialmente il problema come consentire a un attaccante non autenticato di fare includere nella risoluzione dei modelli di pagina un file .php locale leggibile scelto al di fuori delle directory del tema. L’RCE diventa possibile solo quando sono soddisfatti ulteriori prerequisiti ambientali.

Un tema vulnerabile deve contenere una directory di primo livello il cui nome inizia con page-, come:

page-templates

L’avviso di WordPress identifica i temi legacy Twenty Twelve e Twenty Fourteen tra quelli che soddisfano questo requisito strutturale. Temi di terze parti popolari come Neve, Hestia e Sydney possono anche contenere layout di directory compatibili.

Una seconda condizione è che l’attaccante debba identificare un file PHP locale leggibile dall’account del server web che produca un comportamento utile quando incluso.

Il ricercatore di sicurezza Robert Ressl ha dimostrato il percorso RCE utilizzando un componente PEAR chiamato pearcmd.php. Perché quella tecnica funzioni, l’opzione register_argc_argv di PHP deve anche essere abilitata. L’immagine ufficiale di PHP Docker può soddisfare le condizioni rilevanti, mentre le configurazioni tradizionali di cPanel utilizzando versioni di PHP precedenti all’8.5 possono anche esporre l’ambiente richiesto.

Questa distinzione è importante perché non tutte le installazioni vulnerabili di WordPress sono immediatamente sfruttabili per l’esecuzione arbitraria di codice. Un sito può contenere il codice Core vulnerabile mentre mancano la struttura del tema o l’ambiente PHP richiesti dalla catena di exploit dimostrata.

Tuttavia, il primitivo di inclusione di file locale attraversa di per sé un importante confine di sicurezza e non richiede autenticazione né interazione dell’utente.

CVE-2026-87902 interessa WordPress Core dalla versione 4.7.0 alla 7.1.1. L’avviso ufficiale elenca i rami vulnerabili singolarmente, incluse:

• WordPress 7.1.0–7.1.1
• WordPress 7.0.0–7.0.5
• WordPress 6.9.0–6.9.8
• WordPress 6.8.0–6.8.9
• WordPress 6.7.0–6.7.8
• WordPress 6.6.0–6.6.8
• Tutti i rami corrispondenti retroattivi fino a WordPress 4.7.36

WordPress 7.1.1, rilasciata solo cinque giorni prima come aggiornamento di sicurezza, rimane vulnerabile a questo problema separato.

La vulnerabilità è stata scoperta dal ricercatore di sicurezza Robert Ressl e segnalata privatamente tramite il programma HackerOne di WordPress il 20 luglio 2026. WordPress ha riconosciuto il rapporto il 21 luglio e ha informato il ricercatore il 15 settembre che una correzione era stata pianificata. La patch e il consiglio pubblico sono stati rilasciati il 22 settembre.

WordPress classifica la vulnerabilità come Critica con un punteggio CVSS 4.0 di 9.2. Il suo vettore riflette un attacco accessibile in rete con bassa complessità, nessun privilegio richiesto, e nessuna interazione con l’utente, registrando allo stesso tempo che devono essere presenti ulteriori requisiti di attacco prima che sia possibile l’impatto massimo dimostrato.

Una pubblica PoC CVE-2026-87902 è stata rilasciata dal ricercatore al momento della divulgazione. Il proof of concept include un laboratorio locale riproducibile e dimostra il percorso dalla traversata di modelli non autenticata all’inclusione PHP locale e RCE condizionale. Il ricercatore ha testato l’exploit contro WordPress 7.0.2 in ambienti isolati e non l’ha testato su siti di produzione live.

L’esecuzione riuscita nell’ambiente dimostrato è avvenuta con i privilegi dell’account PHP/server web, identificato come www-data, piuttosto che fornire automaticamente privilegi root del sistema operativo. L’impatto pratico, quindi, dipende in parte dai permessi assegnati al processo del server web.

Un attaccante che ottiene l’esecuzione di codice PHP potrebbe potenzialmente distribuire una web shell, modificare i file del sito web, rubare dati di configurazione di WordPress e credenziali del database, creare persistenza, modificare il contenuto, reindirizzare i visitatori, o utilizzare il sito compromesso come punto di partenza iniziale per ulteriori attacchi. Queste sono conseguenze potenziali di post-exploit piuttosto che attività attualmente attribuite a una campagna reale CVE-2026-87902.

Al momento della divulgazione originale del 22 settembre, non era stato riportato alcun sfruttamento in natura e il record di arricchimento di CISA elencava lo sfruttamento come nessuno.

Tuttavia, il panorama delle minacce ha cominciato a cambiare entro poche ore dalla divulgazione. Patchstack ha riferito di aver rilevato tentativi di sondaggio intorno alle 17:44 UTC del 22 settembre, meno di cinque ore dopo che WordPress 7.1.2 era disponibile. Le richieste osservate corrispondevano alla codifica affrontata dalla patch, suggerendo un’analisi rapida del diff di sicurezza.

È importante notare che Patchstack ha caratterizzato il traffico osservato come sondaggio piuttosto che consegna di payload riuscita. Le richieste tentavano di includere file PHP ordinari di WordPress Core e non dimostravano l’esecuzione di codice controllato dall’attaccante. Al 23 settembre, le prove disponibili pubblicamente supportano quindi il riconoscimento attivo, ma non l’esistenza di uno sfruttamento riuscito confermato in ambienti di produzione.

Attualmente non ci sono IOC CVE-2026-87902 specifici per la campagna come domini malevoli, hash di file, famiglie di malware, o un set definitivo di infrastruttura di attacco. I difensori dovrebbero invece concentrarsi sui modelli di richiesta HTTP associati a un’attraversamento anomale del modello di pagina e all’attività successiva del filesystem o PHP.

I potenziali segnali di avvertimento includono:

• Richieste contenenti sequenze di attraversamento directory codificate o ripetute
• Richieste che tentano di manipolare la selezione del modello di pagina
• Modelli di accesso che coinvolgono nomi di file PHP locali inaspettati
• Nuovi file PHP che appaiono nelle directory WordPress scrivibili
• Processi figli inaspettati lanciati dall’account PHP o del server web
• Connessioni in uscita inspiegabili che hanno origine dai processi PHP
• Nuovi account amministratore o modifiche non autorizzate al contenuto di WordPress
• Modifiche ai temi, plugin, o file Core dopo richieste HTTP sospette

Poiché le informazioni pubbliche sugli exploit sono ora disponibili, le organizzazioni dovrebbero aspettarsi una scansione più ampia e lo sviluppo automatico di exploit anche se non è stata ancora confermata pubblicamente una compromissione riuscita del mondo reale.

Mitigazione CVE-2026-87902

La principale azione di rimedio è installare immediatamente una versione patchata di WordPress. WordPress afferma che il ramo più recente, WordPress 7.1.2, contiene la correzione di sicurezza, e sono state anche create versioni patchate per rami più vecchi.

Le versioni ufficiali corrette includono:

• 7.1 → 7.1.2
• 7.0 → 7.0.6
• 6.9 → 6.9.9
• 6.8 → 6.8.10
• 6.7 → 6.7.9
• 6.6 → 6.6.9
• 6.5 → 6.5.12
• 6.4 → 6.4.12
• 6.3 → 6.3.12
• 6.2 → 6.2.13
• 6.1 → 6.1.14
• 6.0 → 6.0.16

I ponti di sicurezza continuano fino a WordPress 4.7.37. WordPress sottolinea, tuttavia, che solo l’ultima release di WordPress è attivamente supportata, quindi è preferibile l’aggiornamento al ramo corrente dove operativamente possibile.

I siti che supportano aggiornamenti automatici in background dovrebbero iniziare a ricevere automaticamente il rilascio di sicurezza. Gli amministratori possono verificare e installare manualmente l’aggiornamento tramite:

Dashboard di WordPress → Aggiornamenti → Aggiorna ora

WordPress non fornisce una soluzione completa che sostituisce l’installazione dell’aggiornamento di sicurezza.

La rilevazione di CVE-2026-87902 dovrebbe iniziare con l’identificazione di tutte le installazioni di WordPress che utilizzano versioni Core 7.1.1 o precedenti e poi determinare se il loro tema padre o figlio attivo contiene una directory di primo livello che inizia con page-.

Gli amministratori dovrebbero anche determinare se PHP è in esecuzione con:

register_argc_argv = On

e se i componenti PEAR leggibili come pearcmd.php o altri potenzialmente utili punti di ingresso PHP locali esistono sul server. Questi controlli aiutano a valutare l’esposizione a tecniche RCE conosciute ma non determinano se esiste il difetto sottostante di WordPress.

To Per rilevare il sondaggio o il tentativo di sfruttamento di CVE-2026-87902, i team di sicurezza dovrebbero esaminare la telemetria del server web, WAF, proxy inversi, PHP e WordPress per:

• Modelli di attraversamento codificati ../ o equivalenti nelle richieste frontend
• Richieste che tentano di manipolare la risoluzione dei modelli di pagina di WordPress
• Riferimenti insoliti a file .php fuori dalle directory dei temi attivi
• Richieste che tentano di raggiungere componenti PHP correlati a PEAR
• Raffiche di richieste di attraversamento simili da un’unica fonte
• Processi PHP che inaspettatamente lanciano comandi di shell o utility di sistema
• Nuovi file PHP o web shell che compaiono dopo richieste sospette
• Cambiamenti inaspettati a wp-config.php, temi, plugin o upload
• Nuovi account amministratore di WordPress creati
• Traffico in uscita sospetto che ha origine dal server web

Le scansioni osservate da Patchstack mostrano che i siti WordPress accessibili da Internet possono già ricevere sondaggi specifici per la vulnerabilità, rendendo la telemetria web e WAF particolarmente preziosa per l’indagine retrospettiva.

Gli amministratori che non possono correggere immediatamente possono ridurre l’esposizione alla catena di esecuzione dimostrata basata su PEAR disabilitando register_argc_argv per le richieste web quando non è richiesto e rimuovendo i componenti PEAR leggibili dal web non utilizzati. Robert Ressl sottolinea che queste sono solo misure di indurimento; non correggono la vulnerabilità sottostante di WordPress.

Le organizzazioni possono anche ridurre il potenziale impatto di post-exploit garantendo che l’account PHP/server web segua i principi del minimo privilegio. Non dovrebbe avere accesso in scrittura non necessario a directory di sistema o file applicativi sensibili.

I siti che erano accessibili da Internet prima della correzione dovrebbero essere esaminati per richieste sospette che iniziano intorno alla divulgazione pubblica del 22 settembre, in particolare perché il materiale pubblico PoC è diventato disponibile nello stesso momento e il sondaggio è seguito entro poche ore.

Se si identifica uno sfruttamento sospetto, gli amministratori dovrebbero conservare i log pertinenti ed eseguire una revisione completa dell’integrità di:

• File Core di WordPress
• Temi attivi e inattivi
• Plugin
• La directory degli upload
• wp-config.php
• Configurazione del server web
• Attività pianificate ed entrate cron
• Account amministratore di WordPress
• Processi PHP e file creati di recente

Le password del database potenzialmente esposte, chiavi API, segreti d’applicazione, o altre credenziali memorizzate in file leggibili dovrebbero essere cambiate se l’investigazione indica che un attaccante ha raggiunto l’inclusione di file locale o l’esecuzione di codice.

La priorità immediata rimane l’aggiornamento di WordPress stesso. Cambiare i temi, disabilitare PEAR o modificare le impostazioni PHP può ridurre percorsi specifici di exploit, ma non dovrebbero essere considerati sostituti per il rilascio ufficiale di sicurezza.