Il 22 settembre 2026, vigilia della festività della Giornata Nazionale, WordPress ha rilasciato l'aggiornamento di sicurezza 7.1.2 per chiudere la CVE-2026-87902. La falla non è in un plugin o in un tema. È nel core di WordPress e interessa tutte le versioni dalla 4.7.0 alla 7.1.1. Lo stesso giorno, alle 11:49 UTC (le 2:49 del pomeriggio ora di Riad), la società di sicurezza Patchstack ha visto il primo tentativo di sfruttarla e, meno di quattro ore dopo, il primo tentativo di scrivere un file sul server di un sito.

Come si è diffuso l'attacco in cinque giorni

Poi si è diffuso. Secondo il rapporto di CrowdSec pubblicato oggi, 28 settembre, la sua rete ha registrato 322.680 segnali di attacco corrispondenti alla falla da 30.813 indirizzi IP distinti tra il 23 e il 27 settembre, con un picco il 27 settembre di 124.154 segnali. L'Autorità Nazionale per la Cybersicurezza (NCA) dell'Arabia Saudita ha emesso un avviso Critico, n. 2026-7873, il 23 settembre, e l'agenzia statunitense CISA ha aggiunto la falla al suo catalogo delle vulnerabilità sfruttate note il 25 settembre.

Cosa fa la falla, in parole semplici

Quando un visitatore richiede una pagina, WordPress decide quale file di template del tema usare per mostrarla. Il bug è in quel passaggio: un attaccante non autenticato può indirizzarlo verso un file PHP che si trova sul server fuori dalla cartella del tema, e WordPress lo eseguirà. WordPress valuta la falla 9.2 su 10; CISA la valuta 8.1.

Diventa controllo del sito quando si allineano le condizioni indicate nell'avviso di WordPress e nei rapporti dei ricercatori:

  • Il tema: il tema attivo contiene una cartella il cui nome inizia con page-. L'avviso elenca Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney tra i temi che ce l'hanno.
  • Un'impostazione di PHP: register_argc_argv è attivo, il che secondo CrowdSec è l'impostazione predefinita nelle immagini Docker ufficiali di PHP e sui server cPanel con PHP precedente alla 8.5.
  • Un file di supporto: il pearcmd.php di PEAR è presente sul server. Gli attaccanti lo usano per scrivere nuovi file PHP, in altre parole una backdoor che sopravvive all'aggiornamento.

Quindi la falla non colpisce tutti i siti allo stesso modo, ma Security Affairs la riassume così: l'esecuzione di codice richiede che la configurazione del server sia quella giusta, e molti server lo sono. Il titolare di un'azienda di solito non sa quale tema è attivo né come è configurato il server, quindi l'ipotesi prudente è che il sito sia esposto fino a prova contraria.

Perché l'attacco è arrivato in ore e non in settimane

Un aggiornamento di sicurezza rivela per sua natura dove si trova il bug, perché la modifica al codice è pubblica. Patchstack afferma che i primi payload corrispondevano esattamente allo schema chiuso dalla correzione, il che significa che chi li ha scritti è partito dalla correzione stessa e non da una scoperta indipendente. I primi tentativi richiedevano normali file del core di WordPress, come wp-login.php e wp-cron.php, per vedere come rispondevano i siti, e poi sono passati alla scrittura di file.

Il traffico porta anche le impronte di scanner automatici e di codice proof-of-concept pubblicato. Per il titolare di un'azienda, questo significa che nessuno sta scegliendo il tuo sito in particolare. Gli strumenti passano al setaccio ogni sito WordPress che riescono a raggiungere, e la differenza tra un sito compromesso e uno pulito è se l'aggiornamento è arrivato prima di loro.

Il tuo sito si aggiorna da solo?

Probabilmente sì, ma non darlo per scontato. WordPress ha gli aggiornamenti automatici in background dalla versione 3.7 e, dalla 5.6, le nuove installazioni aggiornano automaticamente sia le release minori sia quelle maggiori. L'annuncio della 7.1.2 dice che i siti che supportano gli aggiornamenti automatici in background inizieranno ad aggiornarsi automaticamente.

Ma gli aggiornamenti automatici si possono disattivare con una sola riga in wp-config.php. Alcuni sviluppatori li disattivano di proposito perché un aggiornamento non rompa un tema personalizzato, e alcuni hosting gestiscono gli aggiornamenti per conto loro. Un sito costruito anni fa da un freelance, il cui contratto è ormai scaduto, può restare su una versione vecchia senza che nessuno se ne accorga. Per verificare:

  • Accedi all'area di amministrazione del sito, apri la pagina Aggiornamenti nel menu Bacheca e lì vedrai la versione attuale.
  • La versione sicura è la 7.1.2 o successiva. Se il tuo sito è su un ramo più vecchio, la correzione ha raggiunto tutti i rami fino alla 4.7, tra cui la 7.0.6, la 6.9.9, la 6.8.10 e la 4.7.37; l'elenco completo è nell'avviso di WordPress citato tra le fonti.
  • Tieni presente che WordPress dichiara che solo la versione più recente è supportata attivamente. Un sito lasciato su un ramo vecchio ha ricevuto questa correzione, ma vive in tempo preso in prestito. Abbiamo spiegato cosa porta la nuova versione a un sito aziendale in WordPress 7.1: le principali novità.

Anche Elementor: basta un link

Nella stessa settimana Elementor, il popolare page builder per WordPress, ha corretto una falla presente solo nelle versioni 4.3.0 e 4.3.1. Se un amministratore del sito apre un link manipolato mentre è connesso, un attaccante può creare un account amministratore sotto il proprio controllo, e il link può arrivare via email, chat o commento. Secondo BleepingComputer, quelle versioni girano su un massimo di 2 milioni di siti. La correzione è uscita nella 4.3.2 il 24 settembre, e al momento della pubblicazione il sito non segnalava sfruttamenti attivi.

Assicurati che Elementor sia alla 4.3.2 o successiva e fanne una regola del team: non aprire link da messaggi o commenti mentre si è connessi all'area di amministrazione del sito.

Se il tuo sito non è stato aggiornato dal 22 settembre

  • Aggiornalo subito: se lo sviluppatore teme che l'aggiornamento rompa qualcosa, Patchstack afferma che la via può essere chiusa temporaneamente bloccando i tentativi di directory traversal nel parametro pagename, oppure disattivando register_argc_argv. È un lavoro per l'hosting o lo sviluppatore, e non sostituisce l'aggiornamento.
  • Considera che il tuo sito sia stato sondato: chiedi allo sviluppatore o all'hosting di cercare file PHP che nessuno ha aggiunto, soprattutto in /tmp e /var/tmp, dove Patchstack indica file come poc87902.php e wp-pear-rce-flag.php come segni di un'esecuzione di codice riuscita.
  • Se salta fuori qualcosa: trattalo come un incidente, non come un aggiornamento. Cambia le password degli account amministratore, del database e dell'hosting, ripristina il sito da un backup pulito e poi aggiornalo.
  • Se il sito contiene dati dei clienti: se memorizza ordini, moduli di contatto o account, la guida dell'Autorità Saudita per i Dati e l'Intelligenza Artificiale (SDAIA) sugli incidenti di violazione dei dati personali impone al titolare del trattamento di notificare l'autorità competente entro 72 ore dal momento in cui viene a conoscenza di una violazione che potrebbe danneggiare i dati o le persone a cui appartengono.

Il punto di vista di Origami

Molti siti aziendali sono costruiti su WordPress e poi trattati come una brochure stampata: lo sviluppatore lo consegna, il titolare paga e nessuno chiede chi lo terrà aggiornato. Questa falla ricorda che un sito web è un sistema vivo su un server esposto a internet, e che l'intervallo tra la pubblicazione di una correzione e l'arrivo di un attaccante oggi si misura in ore. La vera domanda non è se WordPress sia sicuro, dato che ha corretto il bug e ha distribuito la correzione su tutti i rami fino alla 4.7. È chi, nella tua azienda, è responsabile di installarla.

Per questo riteniamo che un contratto di manutenzione del sito debba fissare un tempo massimo per installare gli aggiornamenti di sicurezza critici, richiedere una copia di staging in cui gli aggiornamenti vengano testati prima del sito in produzione, e prevedere backup regolari conservati fuori dal server stesso. E se gli aggiornamenti continuano a essere rimandati perché il tema è personalizzato in un modo che si rompe a ogni aggiornamento, quello è un problema di come è stato costruito il sito, non di WordPress, e merita di essere risolto prima della prossima falla.

In sintesi: tre passi

  • Oggi: apri l'area di amministrazione e verifica che la versione sia la 7.1.2 o la release corretta del tuo ramo, e che Elementor sia alla 4.3.2 o successiva.
  • Questa settimana: chiedi allo sviluppatore o all'hosting di scansionare il server alla ricerca di file PHP sconosciuti e di confermare per iscritto che gli aggiornamenti automatici sono attivi.
  • Questo mese: aggiungi al contratto di manutenzione un tempo massimo per installare gli aggiornamenti di sicurezza e indica la persona responsabile.

Fonti