Se ti occupi del sito della tua azienda, l’estate del 2026 ti avrà lasciato una sensazione strana. Ogni poche settimane arrivava la notifica di un nuovo aggiornamento di sicurezza. Non era un’impressione: tra il 17 luglio e il 22 settembre il team di WordPress ha pubblicato cinque release di sicurezza del core. L’ultima corregge una vulnerabilità classificata come critica. Per chi gestisce un sito senza un contratto di assistenza WordPress, questo ritmo è diventato difficile da seguire.
Il punto non è allarmarsi. Il punto è un altro: molte aziende aggiornano il proprio sito quando se ne ricordano. E oggi quel metodo non regge più il confronto con la velocità degli attacchi.
In questo articolo vediamo cosa è successo davvero in questi due mesi. Poi che cosa fa la falla corretta il 22 settembre, chi è realmente esposto e quali controlli ha senso fare adesso sul tuo sito.
Cosa è successo tra luglio e settembre 2026
Vale la pena mettere in fila le date. Viste una per una, queste release sembrano ordinaria amministrazione. Viste insieme raccontano un’altra storia.
- 17 luglio, WordPress 7.0.2: corregge una catena di esecuzione di codice remoto nelle REST API, con aggiornamento forzato su molte installazioni.
- 6 agosto, WordPress 7.0.3: dodici correzioni di sicurezza in un colpo solo. Tra queste la falla che il CERT-AGID ha segnalato come XSS2Shell (CVE-2026-64638).
- 12 agosto, WordPress 7.0.4: un problema nella gestione delle immagini che poteva portare, anche qui, all’esecuzione di codice.
- 17 settembre, WordPress 7.1.1: undici correzioni di sicurezza, insieme a diversi fix di manutenzione.
- 22 settembre, WordPress 7.1.2: una sola correzione, ma di gravità critica. È quella di cui parliamo tra poco.
Cinque release di sicurezza in sessantasette giorni. In mezzo, il 19 agosto, è arrivata anche la major release 7.1. Ha portato novità importanti sull’editor e sui media, ma ha anche spostato moltissimi siti su un ramo di codice nuovo.
La falla del 22 settembre spiegata in parole semplici
L’aggiornamento 7.1.2 corregge una sola vulnerabilità, identificata come CVE-2026-87902. La sigla CVE sta per Common Vulnerabilities and Exposures. È il catalogo pubblico internazionale in cui ogni falla nota riceve un codice univoco. Questa ha ricevuto un punteggio di gravità di 9,2 su 10.
Tecnicamente si tratta di un path traversal, cioè un attraversamento di percorso. Quando deve mostrare una pagina, WordPress cerca il file del tema da usare. La vulnerabilità permetteva di far puntare quella ricerca altrove: a un file PHP che si trova fuori dalle cartelle del tema. E il visitatore non aveva bisogno di alcun account sul sito per provarci.
Che cosa comporta? Se quel file contiene codice eseguibile, il sito lo esegue. In gergo si chiama RCE, cioè Remote Code Execution, esecuzione di codice da remoto. È il problema più serio che possa capitare a un server web. Da lì, infatti, un attaccante può installare una backdoor, modificare i contenuti o usare il tuo hosting per attaccare altri.
Da quanto tempo esisteva
Questo è l’aspetto che ha colpito di più chi segue il settore. La falla è presente in tutte le versioni di WordPress dalla 4.7 in poi, cioè da fine 2016. Sono quasi dieci anni di installazioni interessate. Per questo la correzione non riguarda solo la 7.1.2: è stata riportata all’indietro su ventiquattro rami diversi, fino alla 4.7.37.
Tradotto: anche se il tuo sito è fermo da anni su una versione vecchia, esiste un aggiornamento che lo riguarda. Il che è utile solo se qualcuno lo installa.
Chi è esposto davvero
Qui serve onestà, perché in rete si è letto un po’ di tutto. L’esecuzione di codice non è automatica. Perché un attaccante ci arrivi devono ricorrere alcune condizioni, legate alla configurazione del server e al tema attivo. Non tutti i siti vulnerabili sono quindi compromettibili allo stesso modo.
Tuttavia la lettura dei file, cioè il path traversal in sé, funziona a prescindere da quelle condizioni. Anche un sito che non rischia l’esecuzione di codice può quindi lasciar leggere file riservati. Non è una consolazione sufficiente per rimandare l’aggiornamento.
Gli attacchi sono partiti nel giro di poche ore
C’è un dettaglio che cambia il modo di ragionare sugli aggiornamenti. Le prime prove di sfruttamento sono state osservate nelle ore successive alla pubblicazione dell’avviso. Non nei giorni, non nelle settimane.
Il giorno dopo i ricercatori di Patchstack hanno documentato attacchi riusciti: gli aggressori scrivevano file PHP sul disco del server. Il traffico malevolo registrato era oltre dieci volte superiore a quello della prima sera. Nel frattempo circolavano già strumenti pubblici per individuare i siti vulnerabili.
La finestra tra “la falla diventa pubblica” e “qualcuno la sta provando sul tuo sito” si è ridotta a poche ore. Un sito aggiornato al primo controllo utile, magari il lunedì successivo, in quella finestra ci è rimasto dentro per intero.
Ma i problemi di WordPress non erano nei plugin?
Per anni la risposta standard è stata questa. E per anni è stata sostanzialmente vera: la maggior parte delle compromissioni passava da plugin e temi di terze parti, non dal core. È una frase che abbiamo detto anche noi ai clienti.
Il 2026 l’ha resa incompleta. I plugin restano la principale porta d’ingresso, su questo non è cambiato nulla. Il core, però, ha smesso di essere la parte del sistema di cui non preoccuparsi. Di conseguenza anche un sito “pulito”, con pochi plugin scelti bene, oggi ha bisogno di qualcuno che segua le release.
Va detta anche l’altra metà. Questo ritmo di correzioni non significa che WordPress sia diventato insicuro: significa il contrario. Le falle vengono trovate, documentate e chiuse in fretta, e la patch arriva perfino sui rami vecchi di dieci anni. Il problema non è il software. È la distanza tra il momento in cui la patch esce e quello in cui viene applicata.
Perché un contratto di assistenza WordPress cambia le cose
Un servizio di assistenza WordPress non serve a far comparire una notifica in bacheca: quella la vedi già. Serve a coprire quello che succede intorno all’aggiornamento. Ed è lì che le cose vanno storte.
In concreto significa tre cose. La prima è il presidio: qualcuno che sappia entro poche ore che è uscita una release di sicurezza, e che valuti quanto è urgente per il tuo sito. La seconda è il backup, fatto prima e verificato. Un aggiornamento che rompe il checkout di un e-commerce il venerdì sera è un danno concreto quanto un attacco. La terza è il controllo dopo: che il sito funzioni, che i moduli recapitino le mail, che nulla si sia disallineato.
Gli aggiornamenti automatici aiutano, ma non bastano
Sulla maggior parte delle installazioni WordPress applica da solo gli aggiornamenti minori di sicurezza. In questo caso molti siti sono stati protetti senza che nessuno facesse nulla. È un’ottima cosa e non va disattivata.
Quel meccanismo, però, si inceppa più spesso di quanto si pensi. Succede quando il sito è sotto controllo di versione, oppure quando l’hosting ha permessi sui file molto restrittivi. Succede anche quando qualcuno ha disattivato gli aggiornamenti automatici anni fa, per evitare un conflitto, e poi se ne è dimenticato. Oppure quando il sito gira su una versione così vecchia da non ricevere più nulla. In tutti questi casi il sito resta indietro in silenzio. Ed è esattamente il tipo di problema che un servizio di manutenzione WordPress intercetta con un controllo periodico della versione installata.
Cosa controllare sul tuo sito adesso
Vuoi farti un’idea della situazione senza aspettare nessuno? Ecco i passaggi, nell’ordine in cui ha senso farli.
- Entra nella bacheca e vai su Bacheca, poi Aggiornamenti. In alto trovi la versione installata: se non è l’ultima disponibile del tuo ramo, sei indietro.
- Prima di aggiornare, fai un backup completo di file e database. E assicurati di saperlo ripristinare: un backup mai testato è solo un file pesante.
- Applica l’aggiornamento del core, poi quelli di plugin e temi. Controlla il sito dopo ogni passaggio, non tutto insieme alla fine.
- Cerca le tracce di una possibile intrusione: amministratori che non riconosci, password applicative mai create da te, plugin comparsi dal nulla, file modificati di recente.
- Verifica che il sito sia raggiungibile in HTTPS. Controlla poi che i moduli di contatto recapitino davvero le mail e che le pagine principali si aprano.
- Se qualcosa non torna, fermati. Su un sito già compromesso aggiornare non basta: la backdoor sopravvive all’aggiornamento.
Conclusione: il sito non si aggiorna da solo
Cinque aggiornamenti di sicurezza in due mesi. Una falla rimasta aperta per dieci anni. Attacchi partiti nel giro di poche ore. Messi insieme, questi tre fatti dicono una cosa sola: il sito aziendale è un sistema in esercizio, non un depliant che una volta stampato resta lì.
Chi in questi mesi ha avuto qualcuno che se ne occupava non ha fatto nulla di eroico: ha semplicemente aggiornato in tempo, con un backup alle spalle. Ed è tutta qui la differenza tra un sito che ha ricevuto qualche richiesta sospetta e uno che si è ritrovato una web shell nella cartella dei caricamenti.
Vuoi capire in che stato è il tuo sito? Oppure preferisci non doverti più ricordare tu degli aggiornamenti? Dai un’occhiata ai nostri servizi di assistenza e manutenzione WordPress nella sezione dedicata del sito, oppure scrivici a info@maxmile.it. Guardiamo insieme la versione installata e ti diciamo con franchezza se c’è qualcosa da sistemare.
