Una vulnerabilità critica nel nucleo di WordPress, la CVE-2026-87902, è già nel mirino degli attaccanti. La società di sicurezza Patchstack ha visto le prime richieste malevole il 22 settembre 2026, lo stesso giorno in cui il progetto ha distribuito la correzione con WordPress 7.1.2. Chi gestisce un sito e non ha ancora installato l'aggiornamento, o il backport per il proprio ramo, dovrebbe farlo adesso.
La questione riguarda da vicino anche l'Italia, dove WordPress è la piattaforma di riferimento per siti aziendali, e-commerce di piccole dimensioni, blog, associazioni e anche portali di enti locali affidati a fornitori esterni. Secondo W3Techs, a livello mondiale WordPress alimenta il 40,2% di tutti i siti web. Ecco cosa si sa e quali controlli fare.
Che cos'è la CVE-2026-87902?
Il difetto si trova nella parte di WordPress che sceglie quale modello di pagina (page template) del tema usare per mostrare un contenuto. Un controllo insufficiente sui percorsi dei file consente a un visitatore qualsiasi, senza account e senza alcuna azione da parte dell'amministratore, di far caricare a WordPress un file PHP presente sul server ma esterno alle cartelle del tema attivo.
Da solo si tratta di un'inclusione di file locali. Può però trasformarsi in esecuzione di codice da remoto se si verificano due condizioni: il tema attivo deve contenere, al primo livello, una cartella il cui nome inizia con page-, e PHP deve avere attiva l'impostazione register_argc_argv. Tra i temi con questa struttura le fonti citano i vecchi Twenty Twelve e Twenty Fourteen e temi di terze parti molto diffusi come Neve, Hestia e Sydney. L'avviso ufficiale assegna 9,2 punti su 10 nella scala CVSS 4.0; la segnalazione è arrivata dal ricercatore Robert Ressl. Per scelta non riportiamo dettagli utili a riprodurre l'attacco.
Quanto sono stati rapidi gli attacchi?
Patchstack osserva il traffico verso i siti dei propri clienti e ha ricostruito una sequenza in tre fasi: prima gli attaccanti verificano se un sito risponde in modo vulnerabile usando file innocui del nucleo; poi controllano se sul server è raggiungibile lo strumento PHP pearcmd; infine provano a scrivere file PHP propri nelle cartelle temporanee per eseguire comandi.

Il 23 settembre sono comparsi modelli pubblici per lo scanner automatico Nuclei e, secondo Patchstack, il volume di richieste ha superato di oltre dieci volte quello della prima sera. SecurityWeek riferisce che dai tentativi si è passati a compromissioni effettive già il 23 settembre. In altre parole, tra la patch e le scansioni di massa sono trascorse poche ore.
Quali versioni sono sicure?
| Installazione | Stato |
|---|---|
| WordPress da 4.7.0 a 7.1.1 | vulnerabile |
| WordPress 7.1.2 | corretta |
| Backport per i rami precedenti (fino al 4.7) | corretti |
| Versioni precedenti alla 4.7 | fuori dal perimetro indicato, ma senza aggiornamenti di sicurezza da anni |
Un dettaglio da non trascurare: la mattina del 22 settembre era uscita anche la 7.1.1, con altre correzioni. Chi si è fermato alla 7.1.1 non è protetto da questa falla.
Cosa fare subito
- Controllare la versione: nella bacheca, alla voce Aggiornamenti, deve comparire 7.1.2 o la versione corretta del proprio ramo.
- Verificare gli aggiornamenti automatici: se gli aggiornamenti in background per le release di sicurezza sono attivi (impostazione predefinita), WordPress li ha probabilmente già installati. Un controllo manuale resta consigliato.
- Sentire l'hosting o l'agenzia: con i piani WordPress gestiti l'aggiornamento spetta spesso al fornitore. Meglio farsi confermare per iscritto che è stato applicato.
- Misure temporanee: chi non può aggiornare subito può disattivare
register_argc_argvnella configurazione PHP, come suggerisce Patchstack. Interrompe la catena d'attacco nota ma non sostituisce la patch. - Cercare tracce: gli amministratori dovrebbero controllare
/tmpe/var/tmpalla ricerca di file.phpinattesi ed esaminare i log di accesso dal 22 settembre in poi, in particolare le richieste che contengonopearcmd.
Cosa significa per i siti italiani?
Per le aziende italiane un sito compromesso non è solo un problema tecnico. Se l'attaccante accede a dati personali, per esempio i clienti di un negozio online o i contatti raccolti con i moduli, scatta l'obbligo previsto dal GDPR di valutare la violazione e, nei casi previsti, di notificarla al Garante per la protezione dei dati personali entro 72 ore.
Alla mattina del 26 settembre, nell'elenco degli alert pubblicati dal CSIRT Italia dell'Agenzia per la cybersicurezza nazionale (ACN) non compariva ancora una segnalazione dedicata a questa falla. L'agenzia aveva invece diffuso a luglio l'alert AL01/260718/CSIRT-ITA su un'altra coppia di vulnerabilità del nucleo di WordPress (CVE-2026-60137 e CVE-2026-63030), un segnale di quanto la piattaforma sia considerata un bersaglio rilevante. Per chi amministra siti di pubbliche amministrazioni o di soggetti tenuti a rispettare la normativa NIS2, l'aggiornamento va trattato come prioritario.
Le falle nel nucleo di WordPress sono rare rispetto a quelle nei plugin, ed è proprio per questo che fanno notizia: colpiscono potenzialmente ogni installazione, a prescindere dalle estensioni usate. Negli ultimi giorni lo stesso schema, patch seguita da attacchi rapidi, si è visto con la webmail Roundcube e con i server di trasferimento file di Kiteworks.
Domande frequenti
Il mio sito WordPress è a rischio?
Sì, se usa una versione tra la 4.7.0 e la 7.1.1 e non ha ricevuto il backport. L'esecuzione di codice richiede condizioni aggiuntive (struttura del tema e configurazione PHP), ma la falla va corretta in ogni caso.
Basta aggiornare i plugin?
No. Il problema è nel nucleo di WordPress, quindi serve aggiornare WordPress stesso alla 7.1.2 o alla versione corretta del proprio ramo.
Ho un sito su hosting gestito: devo fare qualcosa?
Nella maggior parte dei casi l'aggiornamento è automatico o viene fatto dal fornitore. Conviene comunque controllare la versione nella bacheca e chiedere conferma all'hosting.
Come capisco se il sito è stato attaccato?
I segnali principali sono file .php sconosciuti nelle cartelle temporanee e richieste anomale nei log dal 22 settembre in poi. In caso di dubbio è meglio affidarsi a un professionista e, se sono coinvolti dati personali, valutare la notifica al Garante.











