# L'allarme wp2shell e quanto è sicuro, davvero, il tuo sito > Una vulnerabilità critica in WordPress (wp2shell) ha messo in allerta i proprietari di siti. Cosa significa, cosa fare e perché nessun sito è immune. Source: https://cittago.com/it/blog/wp2shell-securitate-site-2026/ Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011 Published: 2026-07-22 Language: it --- 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. **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)](https://www.dnsc.ro/citeste/alert-vulnerabilit-i-critice-wp2shell-care-afecteaz-wordpress-core) 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: ## 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. ## 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à. *Più un sito fa cose e più è facile da gestire, più ha "porte" — quindi più superficie di attacco. wp2shell è stato sfruttato proprio attraverso una porta di questo tipo, nata per 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"](https://cittago.com/it/blog/wordpress-ai-connectors-2026/): 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". *WordPress ha pubblicato la patch (6.9.5 / 7.0.2 / 6.8.6) e forzato l'aggiornamento automatico già dal 17 luglio — prima che comparissero l'allarme pubblico e i primi attacchi. Ecco come si presenta una reazione matura.* ## 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](https://cittago.com/it/services/cloudflare/), 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. *Tutto l'aggiornamento a 7.0.2, dal download all'"aggiornato correttamente" — pochi secondi.* 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. *Il risultato: WordPress 7.0.2 — una versione di "manutenzione e sicurezza". Schermata ordinaria, posta in gioco tutt'altro che ordinaria.* 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](https://cittago.com/it/services/cloudflare/), configuriamo l'[hosting](https://cittago.com/it/services/hosting/) come si deve e facciamo backup che testiamo davvero. E quando un progetto ha davvero bisogno di un'altra base tecnica, la [costruiamo](https://cittago.com/it/services/web-app-development/). 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. Fonti[Allarme DNSC — l'agenzia rumena per la cybersicurezza](https://www.dnsc.ro/citeste/alert-vulnerabilit-i-critice-wp2shell-care-afecteaz-wordpress-core) · [Advisory ufficiale WordPress — CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) · [Advisory ufficiale WordPress — CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf) · [Annuncio ufficiale WordPress 7.0.2](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) ## Questions and answers **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. --- Cittago · https://cittago.com · digital marketing, SEO, AI search, Google Ads and web development for small and medium companies in Romania, Italy and the EU.