Le prime richieste mirate a CVE-2026-87902 sono comparse alle 17:44 UTC del 22 settembre 2026, meno di cinque ore dopo il rilascio di WordPress 7.1.2. La vulnerabilità riguarda il core del sistema di gestione dei siti e consente a un visitatore senza credenziali di far caricare un file PHP locale. I primi tentativi erano sonde; le segnalazioni successive descrivono richieste volte a scrivere file sul server.
In breve
- WordPress 7.1.2 corregge CVE-2026-87902; la correzione è disponibile anche per rami precedenti, fino alla 4.7.37.
- Sono coinvolte le versioni del core dalla 4.7.0 alla 7.1.1, compresa la 7.1.1.
- Le prime richieste osservate cercavano di riconoscere i siti esposti; quelle successive miravano a scrivere file PHP in /tmp e /var/tmp.
- L’esecuzione di codice remoto dipende da caratteristiche del tema attivo e da un file PHP utilizzabile sul server.
- L’aggiornamento chiude la falla; l’esame dei log e dei file serve ad accertare eventuali tentativi precedenti.
Sommario
Tentativi di attacco poche ore dopo la patch
La sequenza osservata da Patchstack comincia con richieste di ricognizione: gli indirizzi coinvolti provavano a far includere file ordinari del core di WordPress. Quel traffico mostrava un interesse preciso per la falla appena corretta, senza dimostrare che gli aggressori avessero già eseguito codice sui siti raggiunti. La rapidità delle sonde ha comunque ridotto il tempo disponibile per installare l’aggiornamento di sicurezza prima dei primi controlli ostili.
Nelle ore successive, le segnalazioni hanno descritto richieste dirette a componenti PHP capaci, in determinate configurazioni, di scrivere file nelle directory temporanee /tmp e /var/tmp. Il passaggio dalla ricerca di installazioni esposte ai tentativi di creare file cambia ciò che occorre cercare nei registri del server. Una richiesta sospetta documenta un tentativo; per stabilire se sia riuscito servono riscontri sul file system e sull’attività successiva del processo PHP. La distinzione conta anche quando più richieste arrivano allo stesso sito: il loro numero, da solo, non misura l’esito dell’attacco.
Come funziona la falla e quando può portare all’esecuzione di codice
Nel core vulnerabile, una richiesta costruita appositamente può alterare la scelta del template di pagina, il file che WordPress usa per mostrare una pagina. Il percorso così ottenuto può uscire dalle cartelle del tema e portare all’inclusione di un file PHP locale leggibile dal server. Per provocare questo comportamento non occorrono un account WordPress, una sessione amministrativa o un plugin difettoso. Il ricercatore Robert Ressl ha individuato la vulnerabilità.
Il caricamento del file e l’esecuzione di codice scelto dall’aggressore restano passaggi distinti. La catena dimostrata richiede che il tema attivo abbia una cartella di primo livello il cui nome inizi con page-. Richiede inoltre un file PHP presente sul server, leggibile e adatto allo scopo: un esempio è pearcmd.php, componente di PEAR. Per la tecnica basata su quel componente deve essere attiva anche l’impostazione PHP register_argc_argv. Queste condizioni spiegano perché due siti con la stessa versione del core possano avere un’esposizione diversa all’esecuzione di codice remoto. Anche dove la catena completa non funziona, resta da correggere il difetto che consente di scegliere il file locale da caricare.
Versioni coinvolte e limiti delle evidenze sugli attacchi
WordPress indica come vulnerabili le versioni dalla 4.7.0 alla 7.1.1 e ha pubblicato la correzione nella 7.1.2. Il progetto ha distribuito aggiornamenti anche per i rami precedenti idonei alle patch di sicurezza, fino alla 4.7.37. Questo permette di controllare la release installata su ciascun sito, anche quando l’installazione segue un ramo precedente. Per i siti fermi a versioni anteriori alla 4.7 occorre invece passare a una release che riceva la correzione.
Il quadro degli attacchi va letto con la stessa precisione. Al 23 settembre, SOC Prime riferiva che non risultava pubblicamente confermata un’esecuzione di codice riuscita su siti di produzione. Le sonde iniziali e le successive richieste di scrittura mostrano attività diretta contro la vulnerabilità, ma non identificano da sole siti compromessi. Anche trovare un percorso sospetto nei log richiede un controllo ulteriore: bisogna collegare la richiesta a eventuali file creati e al loro uso. Una versione vulnerabile indica che il difetto è presente; stabilire che cosa sia accaduto su un’installazione richiede tracce relative a quella installazione.
Aggiornamento e verifiche per chi gestisce un sito
Il primo controllo è verificare nella bacheca che sia installata WordPress 7.1.2 oppure la release corretta del ramo utilizzato; se manca, si applica l’aggiornamento di sicurezza. Il secondo è esaminare i log del server per richieste anomale legate alla scelta del template e controllare l’eventuale comparsa di file PHP inattesi, comprese le directory temporanee citate nelle segnalazioni.
Nei prossimi riscontri conteranno eventuali nuove conferme di esecuzione riuscita su siti di produzione e gli aggiornamenti delle analisi degli attacchi. La verifica della versione installata e quella delle tracce precedenti restano due operazioni separate, da completare per ogni sito gestito.
