L'allarme wp2shell e quanto è sicuro, davvero, il tuo sito
Il 19 luglio, l'agenzia rumena per la cybersicurezza (DNSC) ha lanciato l'allarme: una falla critica in WordPress, battezzata wp2shell, con cui un attaccante può prendere il controllo di un sito senza alcuna password. È una notizia seria. Ma oltre al «aggiorna subito», è anche un buon momento per parlare di una verità che in pochi ti dicono: nessun sito è immune — e va bene così, se sai come si gestisce.
Partiamo dalla parte urgente, così puoi tirare il fiato: se il tuo sito è su WordPress, controlla la versione. Se è 6.9.5, 7.0.2 o più recente, sei già al riparo da questo attacco — WordPress ha distribuito l'aggiornamento in automatico. Se no, fai prima un backup, poi aggiorna — e dopo verifica che tutto funzioni come deve. Il resto dell'articolo parla di ciò che si nasconde dietro questo allarme.
wp2shell è la combinazione di due falle nel cuore di WordPress che, insieme, permettono a un attaccante non autenticato di eseguire codice sul server — cioè di prendere il controllo del sito. Riguarda le versioni 6.9.x e 7.0.x ed è corretta in 6.9.5 e 7.0.2 (bollettini di sicurezza WordPress, 2026). Ci sono già attacchi reali, quindi aggiorna subito. E al di là di questo caso specifico: la sicurezza non è un prodotto che compri una volta sola, ma una disciplina proporzionata a ciò che hai in gioco.
wp2shell: due bug che, insieme, aprono la porta
Prese singolarmente, le due vulnerabilità sembrano gestibili. Combinate, diventano ciò che si chiama pre-authentication RCE — in parole semplici, qualcuno da internet può eseguire codice sul tuo server senza avere alcuna password. La prima falla (CVE-2026-63030) aggira le regole di accesso dell'API REST — la porta di servizio con cui le applicazioni si parlano tra loro — grazie a un errore nel modo in cui il server interpreta le richieste. La seconda (CVE-2026-60137) è una SQL injection.
Per capire perché conta: il database è il quaderno in cui il sito tiene proprio tutto — utenti, articoli, password. Di norma, il sito gli pone domande già stabilite, educate. Una SQL injection avviene quando l'attaccante infila un comando nascosto in qualcosa che sembra una richiesta normale — un po' come se, oltre alla tua ordinazione al ristorante, sussurrassi al cameriere un ordine in più, e la cucina lo eseguisse senza battere ciglio. Tecnicamente: succede quando ciò che scrive l'utente non viene «ripulito» e finisce per essere letto come comando, non come semplice testo.
E c'è un'altra sfumatura importante: prese da sole, nessuna delle due è una catastrofe. La SQL injection, da sola, richiederebbe di solito un account valido. Ma la prima falla la rende accessibile a chiunque, senza password — ed è solo mettendole insieme che danno controllo completo. Per questo si parla di una catena: ogni anello sembra piccolo, ma insieme aprono la porta.
CVE (Common Vulnerabilities and Exposures) è una specie di targa internazionale per i problemi di sicurezza: ogni vulnerabilità scoperta riceve un codice unico — come CVE-2026-63030 — così che tutti nel mondo, dai ricercatori ai produttori alle autorità, parlino esattamente dello stesso problema, senza confusione. RCE (Remote Code Execution) è il tipo di falla più grave: l'attaccante esegue i propri comandi sul server, da ovunque, come se avesse le mani sulla tastiera. E pre-authentication significa che lo fa senza account e senza password.
L'agenzia rumena per la cybersicurezza (DNSC) ricorda che oltre 500 milioni di siti nel mondo usano WordPress (DNSC, luglio 2026) — e le agenzie nazionali di tutta Europa, incluso il CSIRT italiano, rilanciano regolarmente allarmi come questo. Non tutti girano esattamente sulle versioni vulnerabili, ma abbastanza perché l'allarme conti. Ecco cosa è colpito e cosa ti mette al sicuro:
| Versione WordPress | Stato | Cosa fare |
|---|---|---|
| 6.9.0 – 6.9.4 | Vulnerabile | Aggiorna a 6.9.5 |
| 7.0.0 – 7.0.1 | Vulnerabile | Aggiorna a 7.0.2 |
| 6.8.0 – 6.8.5 | Solo la SQL injection | Aggiorna a 6.8.6 |
| 6.9.5 / 7.0.2 e più recenti | Al sicuro | Niente — sei coperto |
Sono colpito? Come controllare in dieci secondi
Entri nel pannello di amministrazione, in Bacheca → Aggiornamenti, e leggi la versione. Se è 6.9.5, 7.0.2 o più recente, sei a posto — WordPress ha attivato l'aggiornamento automatico forzato per le versioni colpite, proprio per la gravità del caso. Se vedi una versione più vecchia, non aspettare il normale ciclo di manutenzione.
Storia
Lo stesso venerdì, due siti
Immagina due pasticcerie, a due strade di distanza. Siti quasi identici, stessa piattaforma, costruiti nello stesso mese. Venerdì 17 luglio, entrambe giravano esattamente sulla versione di WordPress che wp2shell colpisce.
Nella prima, gli aggiornamenti erano attivi e qualcuno — una persona, non un plugin — ci dava un'occhiata ogni tanto. Sabato mattina, la patch era già entrata da sola. Nessuno ha sentito nulla. Una non-storia.
Nella seconda, un conflitto tra due plugin aveva spento in silenzio gli aggiornamenti automatici, mesi prima. Nessuno se n'era accorto, perché tutto «funzionava». Fino a lunedì, quando i clienti hanno iniziato a essere reindirizzati verso un sito sospetto di pillole, e Google ha avvolto il risultato di ricerca in un avviso rosso.
Lo stesso codice. Lo stesso giorno. La stessa falla. L'unica differenza è stata chi guardava.
Perché nessun sito è davvero immune
Ecco la parte che in pochi ti dicono chiaramente: non esiste un sito sicuro al 100%. Qualsiasi sistema che fa cose utili — e soprattutto uno che ti dà un pannello amichevole per gestire da solo i contenuti, senza un programmatore — significa più codice, più funzioni, più porte. Ogni porta in più è una porta che, in teoria, può essere forzata. Gli esperti la chiamano superficie di attacco. E la superficie di attacco cresce esattamente insieme alla comodità.
wp2shell ne è l'illustrazione perfetta. La falla è stata sfruttata attraverso l'API REST — una funzione pensata per rendere WordPress più flessibile e più facile da integrare con altre applicazioni. Non è un difetto dovuto a negligenza, è il prezzo della complessità. Qualsiasi piattaforma abbastanza potente — WordPress, ma anche le sue alternative — ha, da qualche parte, una porta di questo tipo che ancora nessuno ha notato.
Un esempio proprio recente: la versione 7.0 — esattamente la linea colpita — è quella che porta in WordPress le «fondamenta AI»: una nuova schermata, Connectors, con cui colleghi il tuo fornitore AI preferito e altri servizi esterni direttamente nel sito. Funzioni potenti e utili. E, allo stesso tempo, superficie nuova. Siamo onesti: non sono le fondamenta AI ad aver aperto la falla — wp2shell colpisce alcuni componenti vecchi. Ma la direzione resta la stessa: più una piattaforma fa cose, più ha da difendere. La comodità di oggi è la superficie di domani.
E c'è un'altra cosa importante, per mettere l'allarme nel giusto contesto: la reazione è stata matura. La falla è stata segnalata in modo responsabile, corretta in fretta e distribuita automaticamente su milioni di siti in pochi giorni. Non è il segno di un sistema rotto, ma di uno sano, con persone serie dietro. La differenza tra un sito sicuro e uno vulnerabile non sta in «quale tecnologia usi», ma in «chi la guarda e quanto in fretta reagisce».
Quanta sicurezza mi serve, davvero?
Esattamente quanta ne richiede la posta in gioco. Un sito vetrina di cinque pagine e un negozio online con migliaia di clienti e pagamenti non giocano nella stessa categoria e non vanno protetti allo stesso modo. L'idea è calibrare le misure su ciò che hai da perdere — né iperproteggere una brochure, né lasciare scoperto un intero business.
Se hai un sito semplice, vetrina, l'essenziale è onestamente poco: aggiornamenti al giorno, un hosting decente e un backup. Se hai un e-commerce serio, il discorso cambia radicalmente. Lì la sicurezza non è più opzionale: ti serve un server robusto tecnicamente e sul fronte sicurezza, un firewall davanti, backup automatici e testati, e qualcuno di tecnico che ci guarda davvero con regolarità, non solo quando suona l'allarme. I dati dei clienti e i soldi non perdonano l'improvvisazione.
Sicurezza «by design»: gli strati che fanno la differenza
L'idea di security by design è semplice: pensi alla sicurezza fin dall'inizio, quando costruisci, non la rattoppi dopo che è successo qualcosa. In pratica, per un titolare che non è tecnico, si traduce in qualche strato. Nessuno spettacolare. Tutti importanti.
L'aggiornamento dura meno di 30 secondi. La cura dura di più.
La parte visibile di un aggiornamento è sorprendentemente breve. Su un sito tipico, premi un bottone e in qualche decina di secondi WordPress fa tutto da solo: scarica il pacchetto, lo estrae, entra per qualche istante in manutenzione, copia i file, aggiorna il database ed esce. «WordPress è stato aggiornato correttamente.» Quanto dura esattamente dipende dall'hosting e dalle dimensioni del sito — il punto è che la parte tecnica è sorprendentemente rapida.
Solo che l'update in sé è la parte facile. Il lavoro vero — quello che fa la differenza tra «ho premuto un bottone» e «l'ho fatto per bene» — è tutto intorno: un backup completo prima, un test serio dopo (le pagine importanti, i moduli, il carrello e il pagamento, tutto ciò che conta) e ancora un backup solo dopo aver confermato che tutto funziona. Questo richiede tempo, attenzione e un po' di esperienza. Il bottone è gratis; l'attenzione no.
E, per essere onesti fino in fondo: né l'update puntuale, né i backup, né i test ti garantiscono che non succederà mai niente. Niente in sicurezza è al «100%», e chi ti promette questo più che proteggerti ti sta tranquillizzando. Ciò che questi strati fanno insieme è un'altra cosa, più onesta e più preziosa: ti danno il miglior rapporto tra rischio e serenità e trasformano un eventuale incidente da disastro in un fastidio gestibile.
Domande frequenti
Sono colpito da wp2shell se ho WordPress?
Solo se giri sulle versioni 6.9.0–6.9.4 o 7.0.0–7.0.1 (e, per una delle due falle, anche 6.8.0–6.8.5). Se sei su 6.9.5, 7.0.2 o più recente, sei già coperto. Controlla in Bacheca → Aggiornamenti; se non sei sicuro, chiedi a chi ti gestisce il sito.
Ho fatto l'update. Sono al sicuro adesso?
Per questa falla, sì. L'aggiornamento a 6.9.5 o 7.0.2 chiude la catena di attacco wp2shell. Ma la sicurezza non finisce a un update — se il sito è rimasto vulnerabile qualche giorno, conviene confermare anche che nessuno abbia fatto in tempo a lasciare qualcosa dietro di sé.
Devo scappare da WordPress dopo questo allarme?
No. WordPress è una piattaforma solida, usata da centinaia di milioni di siti, e qui ha reagito in modo esemplare. Qualsiasi piattaforma, prima o poi, ha una falla. Ciò che conta è che sia mantenuta correttamente. Si migra quando lo chiede il progetto — velocità, struttura, tipo di sito — non per paura.
Come capisco se il sito è già stato violato?
Segnali tipici: file o utenti che non hai creato tu, reindirizzamenti strani, un rallentamento improvviso, avvisi da Google o dalla società di hosting. Se sei rimasto su una versione vulnerabile, conviene una verifica attenta anche se sembra che tutto sia a posto — un webshell ben nascosto non annuncia la sua presenza.
Dove entra Cittago
Noi costruiamo e manteniamo siti — anche su WordPress — ed è proprio per questo che vediamo questi allarmi in un altro modo: non come un dramma, ma come manutenzione. Teniamo le versioni aggiornate, mettiamo un firewall e un CDN davanti, configuriamo l'hosting come si deve e facciamo backup che testiamo davvero. E quando un progetto ha davvero bisogno di un'altra base tecnica, la costruiamo. Scegliamo lo strumento in base alla necessità, non alla moda.
Un sito non è sicuro o insicuro per sempre. È sicuro finché qualcuno lo guarda. Il resto è solo una questione di quando, non di se.
FontiAllarme DNSC — l'agenzia rumena per la cybersicurezza · Advisory ufficiale WordPress — CVE-2026-63030 · Advisory ufficiale WordPress — CVE-2026-60137 · Annuncio ufficiale WordPress 7.0.2
