Se gestisci uno o più siti WordPress, probabilmente nelle ultime settimane hai visto parecchi aggiornamenti di sicurezza comparire nella bacheca.
Non è una sensazione: tra luglio e agosto 2026 il team di WordPress ha dovuto intervenire più volte sul core del CMS per correggere diverse vulnerabilità, alcune delle quali piuttosto serie.
Tutto è iniziato il 17 luglio 2026 con WordPress 7.0.2, una security release che correggeva due problemi, tra cui una vulnerabilità SQL injection e una combinazione di problemi nella REST API e nel database che poteva arrivare fino all’esecuzione di codice da remoto.
Poi è arrivata la 7.0.3 il 6 agosto, con diverse altre correzioni di sicurezza.
E proprio ieri, 12 agosto 2026, WordPress ha pubblicato la versione 7.0.4, ancora una volta classificata come security release.
Insomma, è stato un periodo piuttosto movimentato.
E secondo me vale la pena capire cosa è successo e soprattutto perché questa storia ci ricorda una cosa fondamentale: aggiornare WordPress non è un optional.
Partiamo dall’inizio.
Il 17 luglio WordPress ha pubblicato la versione 7.0.2. Non si trattava di un normale aggiornamento di manutenzione, ma di una security release.
Il team di WordPress ha corretto due vulnerabilità, una classificata come critica e una come di alta gravità.
La prima riguardava una SQL injection, mentre la seconda era particolarmente interessante perché combinava un problema di gestione delle route batch della REST API con una SQL injection e poteva portare alla Remote Code Execution.
Tradotto in maniera molto semplice: in determinate condizioni un attaccante poteva riuscire a far eseguire codice sul server che ospita il sito.
E questa è una delle situazioni più serie che possano verificarsi quando parliamo della sicurezza di un sito web.
Quando si parla di vulnerabilità spesso si tende a pensare che “rubare dei dati” sia il peggiore scenario possibile.
Non è necessariamente così.
Una Remote Code Execution, abbreviata RCE, può essere molto più pericolosa perché può permettere all’attaccante di eseguire codice sul server remoto.
Le conseguenze dipendono ovviamente dall’ambiente in cui gira WordPress e dai permessi disponibili, ma possono includere:
Per questo una vulnerabilità che può arrivare all’esecuzione di codice sul server va presa molto sul serio.
La gravità della situazione si capisce anche da un altro dettaglio. Per le versioni interessate, il team di WordPress ha attivato gli aggiornamenti forzati attraverso il sistema di auto-update.
Normalmente gli aggiornamenti automatici di sicurezza sono già uno strumento molto importante, ma in questo caso WordPress ha cercato di accelerare ulteriormente la distribuzione della patch.
Le correzioni sono state inoltre portate sui rami supportati del CMS.
Per esempio, WordPress 6.9 ha ricevuto la versione 6.9.5, mentre WordPress 6.8 ha ricevuto la 6.8.6. Il ramo 6.8 era interessato soltanto dalla prima delle due vulnerabilità, mentre il 6.9 era interessato da entrambe.
Ed è qui che la storia diventa ancora più interessante. A distanza di poche settimane, WordPress ha dovuto pubblicare una nuova security release.
Il 6 agosto 2026 è arrivata WordPress 7.0.3. Questa volta le correzioni di sicurezza erano numerose.
Tra quelle segnalate dal team di WordPress c’era una vulnerabilità di Cross-Site Scripting riflesso pre-auth sulla schermata di login, con un potenziale impatto che poteva arrivare fino all’esecuzione di codice PHP.
Ma non era l’unico problema corretto.
La 7.0.3 ha infatti incluso anche correzioni per diverse vulnerabilità XSS memorizzate, un problema di escalation dei privilegi sui multisite, problemi di information disclosure, una vulnerabilità SSRF e altri problemi di sicurezza.
Insomma, ancora una volta non era il classico aggiornamento che porta soltanto qualche piccolo miglioramento.
Quando sembrava che la situazione si fosse finalmente calmata, il 12 agosto 2026 WordPress ha pubblicato un’altra security release: la 7.0.4.
Questa volta la vulnerabilità corretta è identificata come CVE-2026-65640 e riguarda una possibile Remote Code Execution autenticata attraverso il caricamento di un file malevolo.
Il problema interessa le installazioni che utilizzano Imagick e Ghostscript e può essere sfruttato da utenti autenticati con ruolo Author o superiore.
La cosa importante da sottolineare è che la vulnerabilità non riguarda soltanto WordPress 7.0, ma anche diversi rami precedenti del CMS. Per questo motivo WordPress ha distribuito le correzioni anche nelle versioni supportate delle serie precedenti.
È quindi importante verificare non soltanto di avere WordPress aggiornato, ma di utilizzare effettivamente una versione che abbia ricevuto la correzione.
In altre parole, 7.0.4 non è semplicemente un aggiornamento per chi utilizza WordPress 7.0: la correzione riguarda anche le versioni precedenti supportate.
Questo è un punto importante da ricordare quando si parla di sicurezza: non basta sapere che “è uscita una nuova versione”, bisogna capire quale versione corretta è disponibile per il ramo di WordPress che stiamo utilizzando.
La cronologia degli aggiornamenti
Se guardiamo gli eventi in ordine, il quadro è abbastanza chiaro:
In meno di un mese abbiamo quindi avuto tre security release consecutive.
E questo, più che un motivo per pensare che WordPress sia “insicuro”, dovrebbe farci riflettere su quanto sia importante mantenere aggiornato il software che utilizziamo.
Questa è probabilmente la domanda che viene spontanea. La mia risposta è: non necessariamente.
Ogni software sufficientemente complesso contiene bug. E alcuni di questi bug, prima o poi, possono trasformarsi in vulnerabilità di sicurezza.
WordPress ha un codice enorme, viene utilizzato su una quantità gigantesca di siti e viene continuamente sviluppato.
È quindi normale che vengano scoperte vulnerabilità. La vera differenza la fa il modo in cui queste vulnerabilità vengono gestite.
Nel caso di queste settimane, il team di sicurezza di WordPress ha pubblicato rapidamente le correzioni e ha utilizzato anche gli aggiornamenti automatici per cercare di proteggere le installazioni interessate.
Dal mio punto di vista, questo è esattamente quello che dovrebbe fare un progetto open source di queste dimensioni.
Il problema nasce quando WordPress viene installato e poi lasciato lì. Un sito può funzionare perfettamente per mesi anche se il suo core non viene aggiornato. Il fatto che funzioni, però, non significa che sia sicuro. Questa distinzione è fondamentale.
Un sito può essere perfettamente funzionante dal punto di vista dell’utente e contemporaneamente avere una vulnerabilità critica che permette a un attaccante di comprometterlo.
Ed è proprio questo uno dei motivi per cui considero la manutenzione WordPress una parte integrante dello sviluppo di un sito.
Un altro errore abbastanza comune è pensare alla sicurezza di WordPress esclusivamente in termini di plugin.
È vero che i plugin rappresentano una superficie d’attacco molto importante.
Ma WordPress è composto da più livelli:
Una vulnerabilità nel core può essere altrettanto importante, se non ancora più importante, rispetto a quella presente in un singolo plugin.
La vicenda di luglio e agosto 2026 lo dimostra molto bene.
Qui bisogna fare un’altra distinzione.
Aggiornare WordPress è fondamentale, ma non significa automaticamente che un sito sia sicuro al 100%.
Se aggiorni WordPress 7.0.2 alla versione 7.0.4, risolvi le vulnerabilità corrette da quelle release.
Ma se hai un plugin vulnerabile, un tema non aggiornato, password compromesse oppure una configurazione del server non corretta, il problema può comunque esistere.
La sicurezza deve quindi essere vista come un insieme di attività e non come un singolo pulsante da premere.
Questo è forse l’aspetto più importante da capire.
Supponiamo che un sito fosse vulnerabile il 17 luglio e che qualcuno sia riuscito a sfruttare la vulnerabilità prima che WordPress venisse aggiornato.
Se il giorno dopo il sito viene aggiornato automaticamente, la vulnerabilità viene corretta.
Ma questo non significa che l’eventuale attaccante venga automaticamente espulso dal sito.
Se nel frattempo è stato inserito un file PHP malevolo, creato un account amministratore o installata una backdoor, quelle modifiche potrebbero rimanere.
Ed è qui che aggiornamento e bonifica diventano due cose completamente diverse.
In caso di sospetta compromissione, non mi limiterei quindi a controllare la versione di WordPress.
Controllerei almeno:
wp-content;E soprattutto cercherei di capire come è avvenuta la compromissione.
Perché cancellare il malware senza eliminare la causa che ha permesso all’attaccante di entrare significa rischiare di ritrovarsi nuovamente nella stessa situazione.
Secondo me sì.
In particolare per gli aggiornamenti di sicurezza.
La vicenda della 7.0.2 è un buon esempio: WordPress ha utilizzato il sistema di aggiornamento automatico per distribuire la correzione sulle installazioni interessate proprio a causa della gravità delle vulnerabilità.
Questo può evitare che migliaia di proprietari di siti rimangano esposti semplicemente perché non hanno aperto la bacheca di WordPress per qualche giorno.
Ma anche gli aggiornamenti automatici non devono diventare una scusa per dimenticarsi completamente del sito.
Bisogna comunque sapere quale versione è installata, verificare che gli aggiornamenti siano andati a buon fine e controllare che il sito continui a funzionare correttamente.
Questo periodo mi porta anche a una considerazione più generale.
Quando parliamo di manutenzione di un sito WordPress, spesso la riduciamo a: “Ogni tanto entro e faccio gli aggiornamenti.”
In realtà è qualcosa di molto più ampio. Una buona manutenzione dovrebbe comprendere almeno:
Non significa necessariamente fare tutto ogni giorno. Significa avere un processo.
Personalmente non credo che la conclusione da trarre da queste settimane sia: “WordPress è pieno di falle, quindi è meglio usare altro.”
La conclusione che ne traggo è un’altra: WordPress è un software e, come qualsiasi altro software, deve essere mantenuto.
La differenza tra un sito gestito professionalmente e uno lasciato a se stesso spesso non si vede quando tutto funziona. La differenza si vede quando succede qualcosa.
Quando viene scoperta una vulnerabilità critica, quando un plugin viene compromesso, quando il server ha un problema o quando un attacco riesce.
A quel punto avere backup, aggiornamenti, monitoraggio e una persona che sa cosa controllare può fare una differenza enorme.
Quello che mi ha colpito maggiormente di queste settimane non è tanto il numero di vulnerabilità. È la velocità con cui si è evoluta la situazione.
Prima la 7.0.2 con una vulnerabilità che poteva arrivare alla Remote Code Execution. Poi la 7.0.3 con diverse altre correzioni di sicurezza. E infine la 7.0.4, pubblicata il 12 agosto, con una nuova vulnerabilità RCE autenticata.
Questo significa che chi gestisce siti WordPress dovrebbe avere l’abitudine di prestare attenzione alle security release, soprattutto quando il team di WordPress raccomanda esplicitamente di aggiornare immediatamente.
Non bisogna aspettare che il sito smetta di funzionare per occuparsi della sicurezza. Quando compare una vulnerabilità critica, il momento giusto per intervenire è prima che qualcuno possa sfruttarla.
Se gestisci un sito WordPress, la cosa più semplice da fare è controllare la versione installata.
Se utilizzi il ramo 7.0, WordPress 7.0.4 è la versione da installare perché è la più recente security release del ramo. Il team WordPress raccomanda di aggiornare immediatamente i siti.
Ma non fermarti al numero della versione.
Controlla anche che:
Se invece hai avuto un sito compromesso durante questo periodo, la situazione è diversa: aggiornare WordPress potrebbe non essere sufficiente e sarebbe opportuno procedere con una vera analisi della compromissione.
Le ultime settimane sono state un ottimo promemoria per chi lavora con WordPress.
Dal 17 luglio al 12 agosto sono arrivate tre security release importanti: 7.0.2, 7.0.3 e 7.0.4.
La prima ha corretto, tra le altre cose, una vulnerabilità che poteva arrivare alla Remote Code Execution; la seconda ha risolto diverse vulnerabilità, comprese alcune XSS e un problema SSRF; la terza ha corretto una nuova RCE autenticata legata agli upload sui sistemi che utilizzano Imagick e Ghostscript.
È un periodo che può certamente fare paura a chi gestisce un sito. Ma secondo me la lezione più importante è un’altra: non esiste il sito WordPress che “una volta fatto” non ha più bisogno di essere seguito.
WordPress cambia, i plugin cambiano, PHP cambia e, purtroppo, vengono scoperte nuove vulnerabilità. La sicurezza quindi non è qualcosa che fai una volta e poi dimentichi.
È parte della manutenzione del sito. E quando arriva una security release importante come la 7.0.4, pubblicata proprio ieri, la cosa migliore da fare è molto semplice: aggiornare.
In linea generale, gli aggiornamenti tecnici di un sito web dovrebbero essere verificati almeno una volta al mese. I contenuti…
Continua a leggere ›Quando si parla di realizzare un sito WordPress, spesso l'attenzione si concentra sul costo iniziale del progetto. In realtà, una…
Continua a leggere ›Scrivere un buon articolo di blog non significa scrivere un testo tutto di seguito. Un buon articolo è organizzato in…
Continua a leggere ›
