Vulnerabilità WordPress wp2shell: cosa rischiano davvero aziende ed e-commerce

Un sito aziendale compromesso non sempre va offline.

Può continuare a mostrare prodotti, raccogliere contatti e ricevere ordini mentre qualcuno legge il database, crea un accesso nascosto o prepara un reindirizzamento verso una pagina truffaldina. Il sito può essere compromesso ore o giorni prima che il danno diventi evidente.

Il 17 luglio 2026 WordPress ha pubblicato aggiornamenti urgenti per due vulnerabilità del core. Sulle versioni interessate, la loro combinazione prende il nome di wp2shell e può consentire a un attaccante non autenticato di arrivare all’esecuzione di codice da remoto.

Nell’annuncio ufficiale WordPress parla di un problema critico e uno ad alta gravità e raccomanda di aggiornare immediatamente i siti interessati.

Non è la solita falla di un plugin poco usato. È un problema nel cuore di WordPress, tanto grave da aver portato il progetto ad attivare aggiornamenti automatici forzati.

Cosa significa wp2shell per chi gestisce un’azienda

I riferimenti tecnici sono CVE-2026-60137, una SQL injection, e CVE-2026-63030, un errore nella gestione delle richieste batch della REST API di WordPress. Insieme, sulle versioni più recenti, possono permettere a un utente anonimo di superare controlli che avrebbero dovuto proteggerne l’accesso.

Un sito vulnerabile può quindi essere attaccato senza che l’aggressore abbia prima rubato la password dell’amministratore e senza che sia installato uno specifico plugin difettoso.

Le versioni interessate sono:

• WordPress 6.8.0 – 6.8.5: vulnerabili alla componente SQL injection, da aggiornare alla 6.8.6.
• WordPress 6.9.0 – 6.9.4: vulnerabili alla catena completa, da aggiornare alla 6.9.5.
• WordPress 7.0.0 – 7.0.1: vulnerabili alla catena completa, da aggiornare alla 7.0.2.
• WordPress 7.1 beta: usare almeno la beta2.

Le versioni precedenti alla 6.8 non sono interessate da queste due CVE. Questo non rende sicuro un WordPress vecchio e non supportato: indica soltanto che il problema specifico è un altro.

I danni possibili per un sito aziendale

La sicurezza viene spesso raccontata come un elenco di sigle. Per un’azienda, però, il rischio si misura in processi interrotti, dati da verificare, clienti da avvisare e giorni di lavoro persi.

Vendite e contatti possono fermarsi o finire nelle mani sbagliate

Un e-commerce compromesso può smettere di ricevere ordini, mostrare prezzi o coordinate di pagamento alterate, reindirizzare gli utenti o raccogliere dati in modo non autorizzato. Un sito di servizi può continuare a mostrare il modulo di contatto mentre le richieste vengono intercettate, cancellate o inviate altrove.

Non è necessario che il sito resti offline per produrre una perdita economica.

Il database può contenere più dati di quanto immagini

WordPress non conserva soltanto pagine e articoli. A seconda del progetto può contenere account, ordini, dati dei clienti, richieste inviate dai moduli, impostazioni di plugin e informazioni operative. Se esiste un sospetto concreto di accesso non autorizzato a dati personali, l’azienda deve valutare l’incidente anche sul piano privacy e legale con le figure competenti. Non ogni attacco diventa automaticamente un data breach notificabile, ma ignorare la verifica non è una strategia.

Reputazione, SEO e dominio possono subire conseguenze

Malware, pagine di phishing, spam SEO e redirect possono portare a segnalazioni dei browser, risultati di ricerca alterati e perdita di fiducia. Anche dopo la pulizia tecnica possono servire tempo e verifiche per rimuovere avvisi, recuperare l’indicizzazione e dimostrare ai clienti che il sito è tornato affidabile.

Le integrazioni aumentano il perimetro da controllare

Un sito aziendale spesso comunica con CRM, newsletter, automazioni, gestionali, sistemi di pagamento e strumenti pubblicitari. wp2shell non compromette automaticamente ogni servizio collegato. Se il sito poteva leggere token o credenziali, però, quei segreti potrebbero dover essere revocati e sostituiti.

Aggiornare è urgente, ma potrebbe non bastare

Le patch chiudono le vulnerabilità. Non cancellano ciò che un attaccante potrebbe aver fatto prima.

Lo sfruttamento nel mondo reale è stato osservato poco dopo la pubblicazione delle correzioni. Per questo la risposta corretta ha due parti:

1. aggiornare immediatamente a una versione corretta;
2. verificare se il sito mostra segnali di una compromissione precedente.

Affidarsi alla frase “tanto WordPress si aggiorna da solo” non è sufficiente. L’aggiornamento automatico può essere disabilitato, bloccato dai permessi del server, gestito da un plugin oppure annullato da una procedura di deploy. Serve confermare la versione realmente in esecuzione.

Le cinque domande che un’azienda dovrebbe fare oggi

1. Quale versione di WordPress è installata su ogni nostro sito? Non solo sul dominio principale, ma anche su blog, sottodomini, landing e vecchi progetti ancora raggiungibili.
2. Chi è responsabile dell’aggiornamento? Azienda, agenzia, freelance, hosting o nessuno in particolare?
3. L’aggiornamento è stato verificato? Una mail automatica non sostituisce il controllo della versione effettiva e delle funzioni critiche.
4. Abbiamo log e backup utili? Il backup deve essere integro e ripristinabile. I log devono coprire la finestra tra la divulgazione e l’aggiornamento.
5. Sapremmo cosa fare se trovassimo un account o un file sospetto? Cancellare tutto di fretta può distruggere le prove senza eliminare davvero l’accesso dell’attaccante.

Cosa controllare oltre alla versione

Il CERT-AGID raccomanda di verificare richieste anomale verso gli endpoint batch della REST API, nuovi account amministrativi, modifiche inattese ai file, plugin o temi sconosciuti, web shell, accessi anomali al database e cambiamenti alle configurazioni o alle credenziali.

Per il responsabile aziendale non significa aprire il terminale e improvvisarsi analista forense. Significa chiedere al fornitore tecnico un riscontro verificabile:

• versione prima e dopo l’intervento;
• esito del controllo di integrità;
• verifica degli utenti amministratori e dei componenti installati;
• controllo dei log e delle modifiche recenti;
• test di moduli, checkout, pagamenti, webhook e automazioni dopo l’aggiornamento.

Per la parte più tecnica, Edoardo ha preparato una guida completa a wp2shell con matrice delle versioni, danni tecnici e controlli post-patch.

Quando la manutenzione non ha un responsabile

Una vulnerabilità grave può comparire in qualsiasi software. Un processo di manutenzione riduce il tempo di esposizione e rende più ordinata la risposta:

• inventario aggiornato dei siti;
• responsabile chiaro per patch e verifiche;
• backup testati e separati dal sito;
• monitoraggio delle vulnerabilità e dei cambiamenti;
• procedura di risposta quando qualcosa non torna.

Fare clic su “aggiorna” è un’azione. La manutenzione di un sito web è sapere quando farlo, avere un rollback, controllare ciò che conta e non lasciare il cliente da solo se il sito presenta anomalie.

Piano minimo per le prossime ore

Subito

Verificare tutte le installazioni WordPress pubbliche e aggiornare i rami vulnerabili a 6.8.6, 6.9.5, 7.0.2 o versioni successive corrette.

Dopo la patch

Controllare log, account amministrativi, file, plugin, temi e funzioni aziendali critiche. Un WAF aggiornato aggiunge protezione, ma non sostituisce la patch.

Se emerge qualcosa di sospetto

Isolare il sito, conservare le evidenze, valutare quali dati e segreti potevano essere raggiunti, revocare le credenziali esposte e ripristinare da una sorgente pulita. Se sono coinvolti dati personali, coinvolgere anche le figure privacy e legali appropriate.

Per evitare la prossima emergenza

Definire chi gestisce gli aggiornamenti, in quali tempi, con quali controlli e con quale procedura di ripristino. Metterlo per iscritto negli accordi con hosting e fornitori evita il classico giro di telefonate in cui tutti pensavano se ne occupasse qualcun altro.

Domande frequenti per aziende ed e-commerce

La mia azienda usa WordPress: devo preoccuparmi?

Devi verificare, non andare nel panico. Se il sito usa una versione vulnerabile, la priorità è aggiornarla e controllare l’eventuale presenza di anomalie. Se è già su una versione corretta, va comunque confermato che l’aggiornamento sia riuscito.

Il mio hosting gestisce gli aggiornamenti: basta?

È un buon controllo, ma serve una conferma. Chiedi la versione effettiva, l’orario dell’aggiornamento e se sono state eseguite verifiche post-patch. Hosting, agenzia e azienda devono avere responsabilità chiare.

Un plugin di sicurezza risolve wp2shell?

No. Plugin e WAF possono bloccare alcuni tentativi e aggiungere monitoraggio. La soluzione definitiva resta l’aggiornamento del core WordPress.

Se il sito è stato attaccato devo avvisare tutti i clienti?

Non automaticamente. Prima va accertato che cosa è successo, quali dati potevano essere coinvolti e quali obblighi si applicano. Se ci sono dati personali o pagamenti, la valutazione deve coinvolgere rapidamente responsabili privacy, legali e tecnici.

Un sito vetrina può davvero creare un problema aziendale?

Sì. Può essere usato per phishing, spam, malware, furto di contatti o danni reputazionali. Il rischio di raggiungere altri sistemi dipende dalle integrazioni, dalle credenziali disponibili e dall’isolamento dell’hosting, quindi va valutato caso per caso.

Fonti

• WordPress 7.0.2 Security Release
• CERT-AGID, wp2shell: vulnerabilità critiche nel core di WordPress
• Cloudflare, protezioni WAF e versioni interessate
• SecurityWeek, sfruttamento osservato nel mondo reale

Se non sai chi sta verificando il tuo sito WordPress, questo è il momento di scoprirlo. Parla con WebWakeUp: possiamo controllare versione, aggiornamento e segnali principali senza trasformare una verifica tecnica in una presentazione piena di sigle.