Tra luglio e agosto 2026 chi come me, gestisce siti WordPress,  ha avuto più di un motivo per prestare particolare attenzione alla sicurezza.

In poche settimane sono state corrette vulnerabilità importanti direttamente nel core di WordPress, sono stati documentati tentativi di sfruttamento reali e sono emersi problemi critici in plugin utilizzati da centinaia di migliaia di siti.

Non significa che improvvisamente WordPress sia diventato un CMS insicuro. Significa piuttosto che la sua enorme diffusione continua a renderlo uno degli obiettivi più interessanti per chi cerca installazioni vulnerabili da compromettere automaticamente.

La vera questione, quindi, non è chiedersi se WordPress sia sicuro oppure no.

La domanda corretta è un’altra: quanto è sicuro il tuo WordPress in questo momento?

Perché tra un’installazione aggiornata, controllata e correttamente configurata e un sito abbandonato a se stesso possono esserci differenze enormi.

Vediamo cosa è successo nell’estate 2026 e, soprattutto, cosa possiamo imparare da questi episodi.

Attacchi a WordPress nell’estate 2026: cosa sapere e come proteggersi

Luglio 2026: il problema arriva direttamente dal core di WordPress

Uno degli eventi più importanti si è verificato il 17 luglio, quando è stata pubblicata WordPress 7.0.2.

Non si trattava di un normale aggiornamento di manutenzione. La release correggeva un problema critico e uno classificato ad alta severità. La situazione è stata considerata sufficientemente seria da portare WordPress.org ad abilitare gli aggiornamenti automatici forzati sulle versioni interessate.

La vulnerabilità più preoccupante riguardava una SQL Injection non autenticata raggiungibile attraverso la REST API.

Il problema diventava particolarmente grave perché, combinando le vulnerabilità corrette, era possibile arrivare alla compromissione completa del sito e all’esecuzione di codice da remoto.

La vulnerabilità non è rimasta semplicemente un esercizio teorico per ricercatori di sicurezza. Sono stati osservati tentativi di sfruttamento reali contro installazioni vulnerabili.

Per chi gestisce WordPress questo episodio è particolarmente interessante perché rompe una convinzione piuttosto diffusa: che sia sufficiente mantenere aggiornati plugin e temi per essere relativamente tranquilli.

Normalmente è vero che buona parte delle vulnerabilità dell’ecosistema WordPress proviene dai componenti aggiuntivi. Nel caso di luglio 2026, però, il problema interessava direttamente il core.

Il caso “wp2shell”

Le vulnerabilità di luglio sono diventate note anche con il nome wp2shell.

Il CERT-AGID italiano ha pubblicato un avviso specifico il 19 luglio, richiamando l’attenzione sulle vulnerabilità CVE-2026-60137 e CVE-2026-63030 e sulla possibilità di combinarle per compromettere installazioni WordPress vulnerabili.

Nei giorni successivi sono stati osservati attacchi finalizzati, tra le altre cose, all’installazione di webshell e plugin malevoli.

Una webshell è particolarmente pericolosa perché può consentire all’attaccante di mantenere un accesso al server anche dopo che la vulnerabilità originale è stata corretta.

Ed è qui che emerge un punto fondamentale.

Aggiornare WordPress dopo una compromissione potrebbe non essere sufficiente.

Se qualcuno è già riuscito a entrare nel sito, bisogna verificare che non abbia lasciato backdoor, file PHP nascosti, nuovi amministratori, plugin modificati o altre forme di persistenza.

Un sito compromesso non dovrebbe quindi essere semplicemente aggiornato e considerato automaticamente risolto.

Agosto 2026: arriva WordPress 7.0.3

La situazione è proseguita ad agosto.

Il 6 agosto è stata pubblicata WordPress 7.0.3, un’altra release di sicurezza contenente 12 correzioni.

Tra i problemi affrontati figuravano vulnerabilità XSS, escalation di privilegi, information disclosure, bypass della verifica email e SSRF.

Una delle vulnerabilità più rilevanti era una reflected XSS raggiungibile senza autenticazione dalla schermata di login e potenzialmente utilizzabile per arrivare all’esecuzione di codice PHP.

Ancora una volta, quindi, non stiamo parlando soltanto di piccoli bug che interessano situazioni molto particolari.

Il Canadian Centre for Cyber Security ha successivamente segnalato che, secondo le informazioni disponibili, CVE-2026-64638 risultava sfruttata attivamente.

Per chi gestisce un sito aziendale questo dovrebbe far riflettere soprattutto sulla velocità con cui oggi è necessario reagire alla pubblicazione di una vulnerabilità.

Non è più realistico pensare:

“Aggiornerò WordPress quando avrò tempo.”

Tra la divulgazione di una falla e i tentativi automatizzati di sfruttarla può trascorrere pochissimo tempo.

Il 12 agosto arriva un altro aggiornamento: WordPress 7.0.4

A distanza di appena sei giorni da WordPress 7.0.3 è arrivata un’altra release di sicurezza.

WordPress 7.0.4 è stata pubblicata il 12 agosto per correggere una vulnerabilità che poteva consentire a un utente con ruolo Author o superiore di arrivare all’esecuzione remota di codice attraverso un file appositamente preparato, nei sistemi che utilizzavano Imagick e Ghostscript.

Il dato interessante non è soltanto la singola vulnerabilità.

È la sequenza temporale:

17 luglio: WordPress 7.0.2.

6 agosto: WordPress 7.0.3.

12 agosto: WordPress 7.0.4.

Tre aggiornamenti di sicurezza importanti in meno di un mese.

Questo dimostra quanto sia sbagliato considerare la manutenzione WordPress come qualcosa da effettuare una volta ogni tanto.

Non solo WordPress: il problema dei plugin

Come accade frequentemente nell’ecosistema WordPress, durante agosto sono emerse vulnerabilità molto serie anche nei plugin.

Ed è probabilmente questo l’aspetto che dovrebbe interessare maggiormente il proprietario di un normale sito aziendale.

Un’installazione WordPress raramente è composta esclusivamente dal core. Ci sono page builder, moduli di contatto, sistemi multilingua, plugin SEO, strumenti per cookie e privacy, sistemi di caching, plugin di sicurezza e decine di altre estensioni.

Ognuno di questi componenti aumenta le funzionalità del sito, ma aumenta anche la superficie di attacco.

Elementor Pro: una vulnerabilità che poteva portare all’esecuzione di codice

Il 19 agosto è stata resa pubblica una vulnerabilità critica di Elementor Pro, identificata come CVE-2026-32475 e valutata da Patchstack con un punteggio CVSS di 9.0.

Il problema riguardava il modulo Forms e, in particolare, la gestione del caricamento dei file.

In determinate condizioni un attaccante non autenticato poteva sfruttare il meccanismo di upload per caricare file arbitrari e arrivare all’esecuzione di codice da remoto.

Il problema è stato corretto nella versione 4.2.2.

Questo episodio è particolarmente significativo perché Elementor Pro è un prodotto estremamente conosciuto. Non stiamo parlando del classico plugin abbandonato da anni e scaricato da poche decine di persone.

E dimostra ancora una volta una cosa importante: la notorietà di un plugin non elimina la necessità di mantenerlo aggiornato.

TranslatePress e il rischio di perdere l’account amministratore

Un altro caso importante è emerso ad agosto con TranslatePress.

Wordfence ha documentato una vulnerabilità di account takeover nelle versioni fino alla 3.3.1 del plugin, che conta più di 400.000 installazioni attive.

In una configurazione specifica, un attaccante non autenticato poteva ottenere il link per il reset della password di un amministratore, modificare la password e successivamente accedere al sito con privilegi amministrativi.

Il problema è stato corretto nella versione 3.3.2.

Una volta ottenuto un account amministratore, naturalmente, l’attaccante può fare molto più che modificare una pagina: può creare altri utenti, installare plugin contenenti backdoor, modificare file e compromettere completamente il sito.

Il caso miniOrange dimostra un altro problema

Ad agosto sono stati documentati anche tentativi di sfruttamento contro vulnerabilità critiche nel plugin miniOrange SAML 2.0 Single Sign On.

Le vulnerabilità potevano consentire un bypass dell’autenticazione e permettere a un attaccante di accedere come un altro utente, incluso un amministratore.

La vicenda è interessante anche per un’altra ragione: alcune edizioni commerciali del prodotto non rendevano immediatamente evidente la disponibilità dell’aggiornamento attraverso il normale meccanismo della dashboard WordPress.

Questo significa che il classico controllo:

“Non vedo aggiornamenti disponibili, quindi è tutto a posto”

non è sempre sufficiente.

La sicurezza WordPress richiede anche la conoscenza dei componenti effettivamente installati e delle relative versioni.

Aggiornare tutto basta?

No.

Gli aggiornamenti sono fondamentali, ma rappresentano soltanto una parte della sicurezza di un sito WordPress.

Il problema più delicato riguarda i siti che potrebbero essere stati compromessi prima dell’aggiornamento.

Immaginiamo che una vulnerabilità venga sfruttata lunedì e che il proprietario aggiorni il plugin venerdì.

La vulnerabilità viene corretta, ma ciò non significa necessariamente che ciò che è accaduto nei quattro giorni precedenti sia scomparso.

Un attaccante potrebbe avere già creato un amministratore nascosto, modificato un file PHP o installato una backdoor.

Per questo, quando esiste il sospetto di una compromissione, bisogna cambiare completamente approccio.

Non si tratta più semplicemente di manutenzione.

Serve un’analisi.

Come capire se un sito WordPress potrebbe essere stato compromesso

Non sempre un sito hackerato mostra immediatamente una pagina con scritto “Hacked”.

Gli attacchi più insidiosi cercano esattamente di fare il contrario: rimanere invisibili.

Il proprietario potrebbe accorgersene perché Google comincia a indicizzare pagine che non ha mai creato, perché compaiono strani URL nei risultati di ricerca, perché vengono creati utenti amministratori sconosciuti oppure perché il sito inizia improvvisamente a effettuare redirect verso domini esterni.

In altri casi il sito continua apparentemente a funzionare normalmente.

Per questo un controllo serio deve riguardare file, database, account amministrativi, plugin, cron job, log e modifiche recenti.

Bisogna inoltre verificare se esistono file PHP in posizioni anomale e confrontare i file del core con quelli originali della distribuzione WordPress.

È un lavoro molto diverso dal semplice clic sul pulsante “Aggiorna”.

Perché vengono attaccati anche i piccoli siti?

Un’altra convinzione che incontro spesso è:

“Perché qualcuno dovrebbe hackerare proprio il mio sito? Non sono Amazon.”

Nella maggior parte dei casi nessuno ha scelto personalmente quel sito.

Gli attacchi moderni sono largamente automatizzati.

Bot e scanner cercano continuamente su Internet installazioni che utilizzano determinate versioni vulnerabili di WordPress, plugin o temi. Quando trovano una possibile vittima, tentano automaticamente lo sfruttamento.

Il valore del sito non è necessariamente nei suoi contenuti.

Un sito compromesso può essere utilizzato per distribuire spam, creare pagine SEO abusive, effettuare redirect, ospitare malware, inviare email indesiderate o diventare parte dell’infrastruttura utilizzata per ulteriori attacchi.

Un piccolo sito aziendale può quindi essere interessante esattamente quanto uno molto più conosciuto.

Il problema che vedo più spesso nei siti WordPress

Dopo anni di lavoro con WordPress, uno dei problemi più frequenti che incontro non è necessariamente la presenza di un plugin pericoloso.

È l’assenza di manutenzione.

Il sito viene realizzato, pubblicato e poi dimenticato.

Passano mesi.

WordPress viene aggiornato occasionalmente, alcuni plugin rimangono indietro, altri non vengono più utilizzati ma restano installati. Magari rimane anche un vecchio tema disattivato che nessuno ricorda più.

Poi arriva una vulnerabilità.

A quel punto l’attaccante non deve inventare nulla. Deve semplicemente trovare l’installazione che non è stata aggiornata.

Cosa ci insegna l’estate 2026

Gli episodi verificatisi tra luglio e agosto non dimostrano che bisogna smettere di utilizzare WordPress.

WordPress continua a essere uno strumento estremamente valido per realizzare siti web aziendali, portali, blog ed e-commerce.

Dimostrano però che un sito WordPress non può essere abbandonato dopo la pubblicazione.

È un software.

Come qualsiasi software collegato a Internet deve essere aggiornato, controllato e mantenuto.

La sicurezza non consiste nell’installare un plugin e dimenticarsene.

Consiste nel ridurre la superficie di attacco, aggiornare rapidamente i componenti vulnerabili, utilizzare soltanto ciò che serve, avere backup realmente utilizzabili e soprattutto sapere come intervenire quando qualcosa non torna.

Il tuo sito WordPress è stato attaccato? Posso aiutarti

Se sei arrivato a questo articolo perché il tuo sito sta mostrando comportamenti strani, Google ha iniziato a indicizzare pagine che non riconosci, sono comparsi redirect, utenti sconosciuti, file sospetti oppure il sito è stato segnalato come pericoloso, evita di procedere cancellando file a caso.

Potresti eliminare il malware visibile lasciando intatta la porta utilizzata dall’attaccante per rientrare.

Mi occupo professionalmente di realizzazione, gestione, manutenzione e risoluzione dei problemi dei siti WordPress.

Sono Pierfranco Gubitosa e posso intervenire direttamente sul sito per capire cosa è successo, individuare eventuali file compromessi, verificare plugin, temi e database, eliminare il codice malevolo e soprattutto cercare la causa che ha permesso l’accesso.

L’obiettivo non è semplicemente far tornare online il sito. È evitare di ritrovarsi qualche giorno dopo esattamente nella stessa situazione.

Se hai un sito WordPress compromesso, sospetti un attacco oppure vuoi sapere se la tua installazione presenta problemi di sicurezza, contattami spiegandomi cosa sta succedendo e indicando l’indirizzo del sito.

Posso effettuare una prima valutazione del problema e indicarti il tipo di intervento necessario.

Quando un WordPress è stato compromesso, aspettare raramente migliora la situazione. Intervenire rapidamente può invece fare una grande differenza.