wp2shell WordPress: mitigazione e analisi dei log

La vulnerabilità wp2shell interessa il core di WordPress e, nelle versioni più esposte, può consentire a un attaccante non autenticato di arrivare all'esecuzione di codice da remoto. Non dipende da un plugin vulnerabile: la catena può coinvolgere anche un'installazione standard, pubblicata su Internet e senza estensioni aggiuntive.

La priorità è semplice: verificare la versione realmente installata e applicare subito l'aggiornamento di sicurezza. Un WAF o una regola sul reverse proxy possono ridurre temporaneamente l'esposizione, ma non sostituiscono la patch. Se il sito è rimasto online con una versione vulnerabile, bisogna inoltre controllare i log e cercare eventuali indicatori di compromissione.

Intervento immediato: aggiornare WordPress almeno alla versione corretta per il ramo in uso: 6.8.6, 6.9.5 oppure 7.0.2. Non è sufficiente presumere che l'aggiornamento automatico sia andato a buon fine.

Che cos'è wp2shell

Con il nome wp2shell viene indicata una catena composta da due problemi nel core di WordPress:

• CVE-2026-60137, una SQL injection nel parametro author__not_in di WP_Query;
• CVE-2026-63030, una confusione nella gestione delle route batch della REST API che, combinata con la SQL injection, può portare a Remote Code Execution.

Il punto di ingresso è la REST API batch, raggiungibile attraverso percorsi come:

/wp-json/batch/v1
/?rest_route=/batch/v1

La gravità deriva dall'assenza di autenticazione e di interazione da parte dell'utente. La catena RCE interessa WordPress 6.9 e 7.0 nelle versioni non corrette; WordPress 6.8 è coinvolto dalla SQL injection ma non dalla catena RCE completa descritta nell'advisory.

Le fonti da seguire sono la release di sicurezza pubblicata da WordPress e gli advisory ufficiali relativi a CVE-2026-63030 e CVE-2026-60137.

Versioni WordPress vulnerabili e versioni corrette

WordPress ha attivato aggiornamenti forzati tramite il proprio sistema automatico per le versioni interessate. È comunque necessario verificare ogni istanza: cron non funzionante, permessi errati, spazio esaurito, filesystem in sola lettura o aggiornamenti disabilitati possono impedire l'installazione della patch.

1. Verificare e aggiornare WordPress

Prima dell'intervento è opportuno creare un backup consistente di file e database. Il backup non deve però ritardare inutilmente la correzione di un sito pubblico vulnerabile.

Con WP-CLI:

wp core version
wp core check-update
wp db export pre-wp2shell-update.sql
wp core update
wp core version

Se l'ambiente usa un ramo specifico, verificare che il risultato finale sia almeno 6.8.6, 6.9.5 oppure 7.0.2. Dopo l'aggiornamento è utile controllare i checksum del core:

wp core verify-checksums --include-root

Il comando segnala file del core modificati, mancanti o inattesi. Un risultato anomalo non dimostra da solo un attacco, perché alcune installazioni contengono personalizzazioni legittime, ma richiede una verifica puntuale.

Aggiornerei inoltre temi e plugin, separando però le attività: la patch del core resta l'intervento che corregge wp2shell.

wp plugin update --all
wp theme update --all

2. Bloccare temporaneamente l'endpoint batch

Quando non è possibile aggiornare immediatamente, si può impedire l'accesso anonimo all'endpoint batch della REST API. È una mitigazione di emergenza: può interferire con integrazioni legittime e deve essere rimossa o rivalutata dopo la patch.

È necessario coprire entrambe le forme della route:

• /wp-json/batch/v1;
• il parametro rest_route=/batch/v1.

Esempio per Nginx

La configurazione seguente mostra il principio da applicare nel virtual host, adattandolo alla configurazione esistente:

location ~* ^/wp-json/batch/v1/?$ {
    return 403;
}

if ($arg_rest_route = "/batch/v1") {
    return 403;
}

Prima del reload:

nginx -t
systemctl reload nginx

Esempio per Apache

Con mod_rewrite è possibile applicare una regola temporanea nel VirtualHost o, se consentito, nel file .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/batch/v1/?$ [NC,OR]
RewriteCond %{QUERY_STRING} (^|&)rest_route=(%2F|/)batch(%2F|/)v1(&|$) [NC]
RewriteRule ^ - [F,L]

Dopo la modifica:

apachectl configtest
systemctl reload apache2

Su sistemi RHEL, AlmaLinux o Rocky Linux il servizio può chiamarsi httpd.

WAF e CDN

La stessa logica può essere applicata su Cloudflare o su un altro WAF, bloccando sia il percorso REST sia la variante in query string. Il vantaggio è fermare le richieste prima che raggiungano PHP e WordPress.

La regola va verificata su staging o monitorata in modalità log, quando possibile, perché alcune applicazioni possono usare legittimamente le API REST. Bloccare tutta la REST API è una misura più invasiva e può interrompere editor, applicazioni headless e integrazioni esterne.

3. Cercare tentativi di exploit nei log

La sola presenza di una richiesta verso l'endpoint batch non prova che il sito sia stato compromesso. Potrebbe essere un controllo interno, un vulnerability scanner o una scansione automatica. Occorre correlare metodo HTTP, risposta, indirizzo IP, user agent, orario e attività successive.

Per cercare entrambe le varianti nei log Nginx:

zgrep -Ehi 'wp-json/batch/v1|rest_route=.*batch(/|%2F)v1' /var/log/nginx/access.log*

Per Apache su Debian e Ubuntu:

zgrep -Ehi 'wp-json/batch/v1|rest_route=.*batch(/|%2F)v1' /var/log/apache2/access.log*

Per Apache su RHEL, AlmaLinux e Rocky Linux:

zgrep -Ehi 'wp-json/batch/v1|rest_route=.*batch(/|%2F)v1' /var/log/httpd/access_log*

Gli elementi da approfondire sono:

• richieste POST verso l'endpoint batch;
• payload o query string insolitamente lunghi;
• molte richieste provenienti dallo stesso indirizzo IP;
• risposte HTTP anomale o variazioni rispetto al traffico abituale;
• richieste successive verso file PHP mai osservati prima;
• accessi a wp-login.php con nuovi account amministrativi;
• traffico in uscita inatteso generato da PHP o dal web server.

Se i log sono conservati su CDN, reverse proxy, load balancer o piattaforma centralizzata, la ricerca deve includere tutte le sorgenti. Analizzare soltanto il log locale può lasciare fuori richieste bloccate a monte o perdere l'IP originario del client.

4. Controllare eventuali indicatori di compromissione

Se il sito è rimasto esposto, l'aggiornamento corregge la vulnerabilità ma non elimina un'eventuale backdoor già installata.

Un primo controllo con WP-CLI può includere:

wp user list --role=administrator
wp plugin list
wp theme list
wp cron event list
wp core verify-checksums --include-root

Nel filesystem:

find wp-content/uploads -type f -iname '*.php'
find . -type f -mtime -7 -print
find . -type f \( -name '*.php' -o -name '*.js' \) -mtime -7 -print

È necessario verificare in particolare:

• amministratori creati o modificati di recente;
• file PHP dentro wp-content/uploads;
• plugin, temi o must-use plugin non riconosciuti;
• modifiche a wp-config.php, .htaccess e file del tema attivo;
• cron WordPress sconosciuti;
• processi, connessioni in uscita e job di sistema insoliti;
• credenziali o token presenti nei file accessibili dall'applicazione.

Le date di modifica sono un indizio, non una prova: un attaccante può alterarle e un deploy legittimo può produrre molte variazioni. Il confronto con backup affidabili, checksum ufficiali e cronologia di deployment è più significativo.

5. Cosa fare se emergono anomalie

In presenza di indicatori concreti eviterei di limitarmi alla cancellazione del singolo file sospetto. La risposta dovrebbe includere:

1. isolamento o limitazione dell'istanza compromessa;
2. conservazione di log, snapshot e copie dei file prima della bonifica;
3. ricostruzione del core da pacchetti originali;
4. verifica o reinstallazione di plugin e temi da fonti attendibili;
5. rotazione delle password WordPress, database, hosting, SSH e pannello;
6. rigenerazione delle security keys e salt in wp-config.php;
7. controllo degli altri siti, container o account presenti sullo stesso server;
8. monitoraggio rafforzato dopo il ripristino.

Ripristinare un backup può essere utile solo se è precedente alla compromissione e se, prima di rimettere il sito online, vengono corrette la vulnerabilità e le credenziali coinvolte.

Checklist rapida per wp2shell

• Inventariare tutte le installazioni WordPress esposte.
• Verificare la versione effettivamente in esecuzione.
• Aggiornare a 6.8.6, 6.9.5, 7.0.2 o successiva.
• Controllare i checksum del core.
• Applicare un blocco WAF temporaneo solo se la patch non è immediata.
• Cercare nei log entrambe le varianti dell'endpoint batch.
• Verificare amministratori, plugin, cron e file modificati.
• Conservare le evidenze prima di una eventuale bonifica.
• Ruotare le credenziali se esiste un sospetto fondato di compromissione.

Supporto per mitigazione e analisi dei log WordPress

La parte più delicata non è soltanto installare l'aggiornamento, ma capire se la vulnerabilità sia stata raggiunta e se l'attaccante abbia lasciato persistenza.

Offro supporto tecnico per:

• inventario e verifica delle installazioni WordPress;
• applicazione della patch e delle mitigazioni su Nginx, Apache, CDN e WAF;
• analisi di access log, error log e log applicativi;
• ricerca di file, utenti, cron e comportamenti anomali;
• definizione della procedura di bonifica e messa in sicurezza;
• hardening, monitoraggio e prevenzione di incidenti successivi.

Se gestisci uno o più siti WordPress e vuoi verificare l'esposizione a wp2shell, puoi contattarmi dalla pagina dedicata. Indica, se possibile, versione di WordPress, stack web utilizzato e modalità di accesso ai log: aiuta a impostare subito un'analisi efficace.

Riferimenti

• WordPress 7.0.2 Security Release
• Advisory CVE-2026-63030
• Advisory CVE-2026-60137
• Ricerca originale di Searchlight Cyber