Indice dell'articolo
Rischio e azione: WordPress ha corretto una vulnerabilità critica nel core, CVE-2026-87902, che può permettere a un attaccante non autenticato di includere un file PHP locale leggibile fuori dalle directory del tema. In presenza delle condizioni tecniche richieste, l’inclusione può diventare esecuzione di codice da remoto. CISA ha confermato lo sfruttamento attivo inserendo la falla nel catalogo KEV: inventariate i siti, preservate gli elementi utili all’analisi e installate subito la release corretta.
Quali versioni sono coinvolte
L’avviso ufficiale copre WordPress dalla serie 4.7 fino alla 7.1.1. La correzione principale è in 7.1.2; WordPress ha pubblicato backport per i rami ancora ammessi agli aggiornamenti di sicurezza, tra cui 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9 e release dedicate fino a 4.7.37. Le versioni 4.6 e precedenti non ricevono la correzione: devono essere migrate, non semplicemente “monitorate”.
La pagina di rilascio precisa che soltanto la versione più recente è attivamente supportata. Un backport riduce il rischio immediato della CVE, ma non trasforma un ramo obsoleto in una piattaforma sostenibile. Per ogni installazione registrate versione, stato degli aggiornamenti automatici, tema attivo, PHP, esposizione Internet e proprietario applicativo.
Prerequisiti e limiti tecnici
La vulnerabilità riguarda la risoluzione dei page template. L’advisory indica due condizioni rilevanti per arrivare allo scenario peggiore: il tema padre o figlio contiene una directory di primo livello il cui nome inizia con page-; sul server esiste un file PHP locale leggibile che può essere usato come bersaglio. Una transizione nota verso RCE usa pearcmd.php quando register_argc_argv è attivo.
Questi controlli servono a definire priorità e indagine, non sono una compensazione equivalente alla patch. Un tema che oggi non espone la condizione potrebbe cambiare; un file utile all’attaccante potrebbe comparire dopo una modifica del server. La misura corretta resta aggiornare il core a una versione corretta e verificare che l’operazione sia realmente terminata su ogni sito.
Patching e incident response non sono la stessa attività
Applicare l’aggiornamento chiude il percorso noto per gli attacchi successivi, ma non dimostra che il sito fosse integro prima della correzione. Poiché CISA classifica la vulnerabilità come sfruttata e richiede triage forense, i siti esposti e rimasti vulnerabili devono essere trattati anche come possibile incidente.
Prima di cancellare file temporanei, ripristinare backup o ruotare alla cieca, preservate log web e PHP, cron, utenti amministrativi, plugin e temi modificati, file PHP recenti dentro e fuori il webroot e configurazione del runtime. Cercate variazioni inattese in wp-config.php, mu-plugin, drop-in, directory upload, account e meccanismi di persistenza. Se emergono indicatori, isolate secondo il runbook, stabilite la finestra temporale e ripristinate da uno stato affidabile.
Checklist operativa
- Elencare tutte le installazioni WordPress, comprese staging, sottodomini e siti non più gestiti.
- Registrare versione del core, tema padre/figlio, versione PHP, hosting e raggiungibilità pubblica.
- Salvare backup verificato di file e database e preservare i log prima dell’intervento.
- Controllare directory di tema che iniziano con
page-e la configurazioneregister_argc_argv, senza usarle come motivo per rinviare la patch. - Aggiornare alla release corretta per il ramo; migrare i rami che non ricevono aggiornamenti.
- Verificare da filesystem e dashboard la versione effettiva, non soltanto l’avvio dell’auto-update.
- Confrontare file core con le checksum ufficiali e riesaminare file PHP, account e cron anomali.
- Testare login, pagine, moduli, e-commerce, cache, cron e monitoraggio dopo l’aggiornamento.
- Aprire incident response quando gli indicatori convergono; la reinstallazione del core da sola non elimina una persistenza esterna.
Cosa documentare
Per chiudere l’attività registrate sito, versione iniziale e finale, orario, operatore, backup, esito checksum, log preservati, controlli effettuati, anomalie e test applicativi. Un esito negativo dei controlli non è una garanzia assoluta: dipende dalla conservazione dei log e dalla visibilità sull’hosting.
Devi inventariare e correggere più siti WordPress senza interrompere i servizi? Richiedi una valutazione tecnica a MSP In Cloud.