> wp2shell, la vulnerabilità critica di WordPress: versioni colpite, danni tecnici e cosa fare subito

È venerdì 17 luglio 2026. WordPress pubblica tre aggiornamenti di sicurezza e, insieme alle nuove versioni, attiva gli aggiornamenti automatici forzati sui siti interessati.

Quando un progetto come WordPress decide di spingere una patch in questo modo, di solito non sta correggendo il colore sbagliato di un pulsante.

L’annuncio ufficiale parla di un problema critico e uno ad alta gravità. WordPress raccomanda l’aggiornamento immediato e conferma di aver attivato gli aggiornamenti forzati proprio a causa della severità.

Le vulnerabilità sono due: CVE-2026-60137, una SQL injection nel core, e CVE-2026-63030, un problema nella gestione delle richieste batch della REST API. Combinate sulle versioni più recenti, formano la catena chiamata wp2shell e possono portare all’esecuzione di codice da remoto senza autenticazione.

Tradotto: su un’installazione vulnerabile l’attaccante non deve prima indovinare una password, convincere un amministratore a cliccare un link o aspettare che sia installato un plugin specifico. Il problema è nel core di WordPress.

Questa volta l’aggiornamento non va messo nella lista delle cose da fare “quando c’è un attimo”.

Quali versioni di WordPress sono vulnerabili a wp2shell

Le due falle non interessano esattamente le stesse versioni. La distinzione è importante, perché WordPress 6.8 è esposto alla SQL injection, ma non alla catena completa che porta alla RCE.

La fonte ufficiale WordPress classifica la vulnerabilità della REST API come critica e conferma che la combinazione con la SQL injection può arrivare alla Remote Code Execution. Cloudflare aggiunge una precisazione utile: la RCE riguarda le installazioni dalla 6.9 in poi quando non è in uso una cache persistente degli oggetti, condizione comune in molte installazioni standard.

Essere su WordPress 6.7 o su una versione ancora più vecchia non significa avere un sito sicuro. Significa soltanto non essere esposti a queste due vulnerabilità specifiche. Una release datata può avere altri problemi già noti e corretti da tempo.

Come funziona la catena, senza trasformare il post in un manuale per attaccanti

La prima falla interessa WP_Query, la classe che WordPress usa per costruire e gestire molte interrogazioni al database. Un parametro non viene trattato in modo sufficientemente sicuro e può permettere di alterare la query prevista. Questo è il pezzo SQL injection.

La seconda falla riguarda l’endpoint batch della REST API. In breve, WordPress può confondere il percorso e i controlli applicati a una richiesta, consentendo a un utente anonimo di raggiungere una strada che avrebbe dovuto restare protetta.

Da sola, la SQL injection ha un perimetro più limitato. Quando la route confusion rimuove il blocco che la teneva lontana dagli utenti anonimi, i due problemi si sommano. Da qui si può arrivare alla lettura del database, alla compromissione di un account amministrativo e, nelle versioni interessate dalla catena completa, all’esecuzione di codice nel contesto del processo web.

Non vuol dire automaticamente accesso root al server. Vuol dire però che il sito e tutto ciò che il processo PHP può leggere o modificare devono essere considerati a rischio. Su hosting con isolamento debole, permessi troppo larghi o segreti condivisi, il danno può allargarsi. Non è garantito, ma è tecnicamente plausibile.

Il danno tecnico non finisce con la homepage modificata

Il defacement, cioè la sostituzione visibile dei contenuti del sito, è quasi la versione gentile del problema. Fa rumore e viene scoperto in fretta. Gli attacchi più fastidiosi cercano di restare.

1. Database letto o manipolato

Nel database possono esserci utenti, hash delle password, contenuti, configurazioni, dati raccolti dai moduli, ordini WooCommerce e informazioni memorizzate da plugin e integrazioni. Il contenuto preciso cambia da sito a sito, ma l’idea è semplice: il database non contiene soltanto gli articoli del blog.

2. Account amministrativi e sessioni compromesse

Un attaccante può cercare di ottenere o creare un accesso amministrativo, cambiare indirizzi email, modificare ruoli o mantenere una sessione valida. Aggiornare il core chiude la vulnerabilità, ma non elimina un amministratore malevolo creato prima della patch.

3. Backdoor nei file, nei plugin o nei task pianificati

Il codice malevolo può finire in un plugin apparentemente innocuo, in un tema, in un file PHP dentro una cartella inconsueta o in un evento pianificato. Può anche modificare file esistenti per rendere meno evidente la persistenza. Il sito torna normale dopo l’aggiornamento, ma la porta secondaria resta aperta.

4. Redirect, phishing, malware e spam SEO

Un sito compromesso può mostrare pagine diverse ai motori di ricerca, iniettare JavaScript, reindirizzare soltanto alcuni visitatori o ospitare contenuti truffaldini. Questo può sporcare l’indicizzazione, far comparire avvisi di sicurezza nel browser, danneggiare la reputazione del dominio e trasformare la pulizia in un lavoro molto più lungo della patch.

5. Token e integrazioni esposte

Molti siti WordPress comunicano con CRM, sistemi email, gateway di pagamento, servizi di automazione e API esterne. Non significa che wp2shell comprometta automaticamente tutti questi sistemi. Significa che credenziali e token leggibili dal sito potrebbero dover essere revocati e rigenerati se l’installazione risulta compromessa.

La patch chiude la falla. Non torna indietro nel tempo.

Questo è il punto che rischia di perdersi nel classico “aggiornate subito”.

L’aggiornamento è obbligatorio perché impedisce nuovi tentativi basati su questa catena. Se il sito è rimasto esposto, però, serve anche chiedersi se qualcuno sia entrato prima della patch. L’attività di sfruttamento è stata osservata nel mondo reale poco dopo la divulgazione e VulnCheck, al 19 luglio, aveva già verificato più di due dozzine di proof of concept pubbliche.

Quindi: patch prima, verifica subito dopo.

Cosa fare adesso, in ordine

1. Verificare la versione effettivamente installata, senza dare per scontato che l’aggiornamento automatico sia riuscito.
2. Creare uno snapshot o un backup verificabile prima dell’intervento. Se ci sono già segnali sospetti, preservare anche log ed evidenze prima di ripulire.
3. Aggiornare al ramo corretto: 6.8.6, 6.9.5, 7.0.2 oppure una versione successiva che includa le correzioni.
4. Controllare che l’aggiornamento sia realmente applicato e verificare l’integrità dei file del core.
5. Eseguire un controllo post-aggiornamento su login, moduli, checkout, API, webhook, automazioni e funzioni personalizzate.
6. Cercare segnali di compromissione dalla finestra di esposizione fino al momento della patch.

Da WP-CLI, i controlli di base possono partire da:

wp core version
wp core update --minor
wp core version
wp core verify-checksums

Il comando di aggiornamento modifica il sito. Su produzione va eseguito con backup disponibile e con una verifica immediata delle funzioni critiche. In un’emergenza di sicurezza non userei però un ciclo di test infinito come scusa per lasciare online una versione vulnerabile.

Cosa controllare dopo l’aggiornamento

• Richieste anomale verso /wp-json/batch/v1 e ?rest_route=/batch/v1 nei log del web server, del CDN e del WAF.
• Nuovi utenti amministratori, cambi di ruolo, email modificate e sessioni che non riconosci.
• Plugin o temi installati di recente e non previsti.
• File modificati, PHP in directory insolite, differenze nei checksum del core e codice offuscato.
• Eventi WP-Cron inattesi, modifiche a wp_options, URL cambiati, redirect e configurazioni alterate.

Se emergono elementi sospetti, non partire cancellando file a caso. Isola il sito, conserva le evidenze, ricostruisci la sequenza degli eventi e valuta un ripristino da una sorgente pulita. Poi ruota password, sessioni, chiavi e token che il sito poteva leggere.

Un firewall applicativo può ridurre l’esposizione. Cloudflare ha distribuito regole dedicate anche sul piano gratuito per il traffico effettivamente proxato dal suo WAF. Searchlight Cyber indica inoltre il blocco temporaneo dell’accesso anonimo agli endpoint batch come mitigazione d’emergenza. Ma è, appunto, temporanea: può rompere funzioni legittime e non sostituisce la patch.

Domande frequenti su wp2shell

wp2shell sfrutta plugin o temi di terze parti?

No. La catena interessa il core di WordPress e può colpire un’installazione standard senza plugin. I plugin presenti possono però aumentare i possibili percorsi successivi una volta ottenuto l’accesso.

Sono vulnerabile se uso WordPress 6.8.x?

Le versioni dalla 6.8.0 alla 6.8.5 sono vulnerabili alla SQL injection CVE-2026-60137, ma non alla catena completa RCE wp2shell. La correzione per questo ramo è WordPress 6.8.6.

L’aggiornamento automatico forzato mi protegge?

Protegge soltanto se è andato a buon fine. Permessi del filesystem, configurazioni, plugin di gestione o procedure di deploy possono impedire o sovrascrivere l’aggiornamento. La versione effettiva va verificata.

Un WAF è sufficiente senza aggiornare?

No. Il WAF è una difesa aggiuntiva e una mitigazione temporanea. La correzione definitiva è l’aggiornamento del core a una versione sicura.

Se ho aggiornato devo comunque controllare il sito?

Sì, soprattutto se il sito è rimasto online su una versione vulnerabile dopo la divulgazione. La patch impedisce nuovi attacchi basati sulla falla, ma non rimuove account, file o backdoor creati prima.

Il problema business merita un discorso separato

Qui ho tenuto il focus sul funzionamento tecnico, sui danni possibili e sui controlli da fare. Su WebWakeUp abbiamo affrontato l’altro lato della faccenda: continuità operativa, dati, vendite, reputazione e responsabilità tra azienda, hosting e fornitore tecnico.

Fonti

• WordPress 7.0.2 Security Release
• GitHub Security Advisory per CVE-2026-60137
• GitHub Security Advisory per CVE-2026-63030
• CERT-AGID, wp2shell: vulnerabilità critiche nel core di WordPress
• Cloudflare, protezioni WAF per le vulnerabilità WordPress
• VulnCheck, analisi e stato delle proof of concept
• SecurityWeek, attività osservata nel mondo reale