XSS2Shell WordPress: CVE-2026-64638, patch e controlli

XSS2Shell, identificata come CVE-2026-64638, è una vulnerabilità reflected XSS pre-authentication nella pagina di login di WordPress. Colpisce il core, non dipende da un plugin o da un tema vulnerabile e interessa tutti i rami compresi tra WordPress 4.7 e 7.0 prima delle rispettive versioni corrette.

La XSS può essere innescata senza credenziali, ma è importante descrivere correttamente il rischio: la catena dimostrata fino all'esecuzione di codice PHP non è zero-click. Richiede che un amministratore già autenticato venga indotto ad aprire una pagina controllata dall'attaccante e interagisca con essa. La priorità resta comunque alta, perché i dettagli tecnici e i proof of concept sono pubblici.

Intervento immediato: aggiorna WordPress alla versione corretta per il ramo in uso, verifica che l'aggiornamento sia realmente riuscito e controlla Application Password, plugin, account amministrativi e file modificati. Un WAF non sostituisce la patch.

Che cos'è XSS2Shell

Il punto di ingresso si trova in wp-login.php. Quando viene inviato un nome utente inesistente, WordPress lo include nel messaggio di errore mostrato nella pagina di autenticazione.

La ricerca di pwn.ai ha evidenziato una diversa interpretazione dello stesso input da parte di più funzioni di sanitizzazione. In determinate condizioni, una stringa può essere considerata testo da un primo parser, ammessa come HTML da un controllo successivo e infine trasformata dal browser in elementi DOM attivi.

Questi elementi interagiscono con JavaScript già caricato dalla pagina di login. La catena descritta dai ricercatori sfrutta poi funzionalità legittime di WordPress per eseguire JavaScript nel contesto del dominio, far approvare una Application Password sfruttando la sessione di un amministratore e usare quelle credenziali per arrivare al caricamento di codice PHP.

Non pubblico il payload: per difendersi è sufficiente comprendere i passaggi e gli artefatti lasciati dall'attacco.

XSS2Shell non è la stessa vulnerabilità di wp2shell

Il nome può generare confusione, ma si tratta di due problemi distinti pubblicati a poche settimane di distanza.

Essere protetti da wp2shell non implica essere protetti da XSS2Shell. Un'installazione aggiornata a WordPress 7.0.2, ad esempio, contiene la correzione per wp2shell ma resta vulnerabile a XSS2Shell fino all'installazione della 7.0.3.

Per il precedente problema puoi consultare anche wp2shell WordPress: mitigazione e analisi dei log.

Condizioni necessarie per arrivare all'esecuzione di codice

La vulnerabilità iniziale è pre-authentication: l'attaccante non deve possedere un account WordPress per raggiungere la pagina di login e predisporre la XSS.

L'escalation a RCE documentata richiede però ulteriori condizioni:

1. un amministratore deve avere una sessione WordPress valida nel browser;
2. l'amministratore deve visitare una pagina predisposta dall'attaccante;
3. deve avvenire l'interazione necessaria alla catena di social engineering;
4. la sessione amministrativa deve poter autorizzare una Application Password;
5. l'account deve disporre dei privilegi necessari per installare o modificare codice.

L'advisory ufficiale assegna alla vulnerabilità severità High e punteggio CVSS 4.0 pari a 8.9. I parametri indicano privilegi iniziali non richiesti, complessità elevata e interazione attiva della vittima.

La distinzione è importante per il triage: non siamo davanti a una RCE automatica ottenibile con una singola richiesta HTTP, ma neppure a una semplice XSS senza impatto sul server.

Versioni WordPress vulnerabili e versioni corrette

L'advisory WordPress elenca come vulnerabili tutti i rami da 4.7 a 7.0 prima delle rispettive release di sicurezza.

La patch è stata distribuita anche sui rami precedenti con le versioni 6.3.9, 6.2.10, 6.1.11, 6.0.13, 5.9.14, 5.8.14, 5.7.16, 5.6.18, 5.5.19, 5.4.20, 5.3.22, 5.2.25, 5.1.23, 5.0.26, 4.9.30, 4.8.29 e 4.7.34.

Il backport riduce il rischio immediato, ma non rende consigliabile mantenere indefinitamente un ramo obsoleto. WordPress ricorda che soltanto la versione più recente riceve supporto attivo completo.

1. Verificare e aggiornare WordPress

Non dare per scontato che l'aggiornamento automatico sia riuscito. Permessi errati, spazio esaurito, filesystem in sola lettura, cron non funzionante o update disabilitati possono lasciare online una versione vulnerabile.

Prima dell'intervento crea un backup consistente di file e database, senza ritardare inutilmente la patch di un sito esposto:

wp core version
wp core check-update
wp db export pre-xss2shell-update.sql
wp core update
wp core version
wp core verify-checksums --include-root

wp core update porta normalmente all'ultima release disponibile. Se l'ambiente deve restare temporaneamente su un ramo specifico, indica esplicitamente la versione corretta dopo aver verificato la compatibilità:

wp core update --version=6.9.6 --force
wp core version
wp core verify-checksums --include-root

Sostituisci 6.9.6 con la versione corretta per il ramo realmente utilizzato. In seguito pianifica l'aggiornamento al ramo WordPress più recente e supportato.

Il controllo dei checksum segnala file del core mancanti, modificati o inattesi. Un'anomalia non prova da sola una compromissione, perché alcune installazioni contengono personalizzazioni, ma deve essere verificata.

2. Controllare le Application Password

Nella catena pubblicata, l'Application Password è il passaggio che consente di trasformare l'esecuzione JavaScript nel browser dell'amministratore in accesso autenticato alle API WordPress.

Elenca prima gli amministratori:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Poi controlla le Application Password associate a ciascun account:

for user_id in $(wp user list --role=administrator --field=ID); do
  echo "=== User ID: ${user_id} ==="
  wp user application-password list "${user_id}" \
    --fields=uuid,name,created,last_used,last_ip
done

Verifica in particolare:

• nomi di applicazioni non riconosciuti;
• password create dopo richieste sospette alla pagina di login;
• valori last_ip estranei all'infrastruttura o agli utenti autorizzati;
• credenziali appena create e utilizzate immediatamente;
• integrazioni non documentate o non più necessarie.

Per revocare una singola credenziale sospetta:

wp user application-password delete <USER_ID> <UUID>

In caso di compromissione confermata è possibile revocarle tutte per uno specifico utente:

wp user application-password delete <USER_ID> --all

La revoca può interrompere applicazioni mobili, integrazioni, automazioni e servizi che usano legittimamente quelle credenziali. Prima di procedere, identifica le dipendenze e pianifica la rigenerazione sicura delle password necessarie.

3. Cercare segnali nei log

I normali access log di Nginx e Apache registrano il percorso della richiesta, ma generalmente non il body di una POST. Non trovare il nome utente malevolo nei log non dimostra quindi che il tentativo non sia avvenuto.

Un primo filtro può individuare la sequenza di endpoint compatibile con la catena:

zgrep -Ehi 'wp-login\.php|authorize-application\.php|wp-json/wp/v2/(users|plugins)' \
  /var/log/nginx/access.log*

Per Apache su Debian e Ubuntu:

zgrep -Ehi 'wp-login\.php|authorize-application\.php|wp-json/wp/v2/(users|plugins)' \
  /var/log/apache2/access.log*

Il risultato può contenere molto traffico legittimo. Per ogni evento sospetto correla almeno:

• timestamp, IP sorgente, metodo HTTP, status e user agent;
• richieste POST a wp-login.php e relativo volume;
• accessi a authorize-application.php non collegati a integrazioni note;
• chiamate REST successive con credenziali applicative;
• installazione, attivazione o modifica di plugin;
• accessi amministrativi e cambiamenti agli account nello stesso intervallo temporale;
• eventi registrati da CDN, WAF, reverse proxy e sistemi di audit.

Se il WAF conserva in modo sicuro alcuni campi del body, la telemetria può aiutare a riconoscere il tentativo iniziale. Evita però di abilitare indiscriminatamente il logging completo delle richieste di login: potrebbe memorizzare password e altri dati sensibili.

Il CERT-AGID ha indicato l'8 agosto 2026 di non avere evidenze pubbliche di sfruttamento attivo. Questo dato descriveva la situazione osservata in quel momento e non dimostra l'assenza di attacchi, soprattutto dopo la pubblicazione dei dettagli tecnici e dei PoC.

4. Verificare eventuali indicatori di compromissione

Oltre alle Application Password, controlla lo stato dell'installazione:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --fields=name,status,version,update,update_version
wp plugin list --status=must-use
wp theme list
wp cron event list
wp core verify-checksums --include-root
find wp-content/uploads -type f -iname '*.php' -print
find wp-content/plugins -type f -mtime -7 -print
find wp-content/themes -type f -mtime -7 -print

Approfondisci soprattutto:

• nuovi account amministrativi o modifiche inattese a quelli esistenti;
• Application Password sconosciute;
• plugin o temi installati fuori dal normale processo di deploy;
• file PHP nelle directory di upload;
• modifiche a wp-config.php, .htaccess, plugin, temi e must-use plugin;
• cron WordPress o job di sistema non riconosciuti;
• processi PHP e connessioni in uscita anomale;
• accessi al pannello provenienti da IP o user agent insoliti.

I timestamp e i comandi find producono indizi, non verdetti. Deploy legittimi, aggiornamenti e plugin che generano file dinamicamente possono creare risultati simili. Confronta gli elementi sospetti con backup affidabili, checksum ufficiali, log di deployment e file integrity monitoring.

5. Mitigazioni temporanee se non puoi aggiornare subito

La soluzione definitiva è installare la release corretta. Se esiste una finestra tecnica prima della patch, puoi ridurre temporaneamente l'esposizione:

• limita wp-login.php a VPN, indirizzi IP autorizzati o autenticazione aggiuntiva sul reverse proxy;
• impedisci agli amministratori di usare sessioni WordPress attive durante la finestra di rischio;
• valuta la disabilitazione temporanea delle Application Password se nessuna integrazione le utilizza;
• limita l'installazione di plugin e temi dal pannello negli ambienti gestiti con deployment immutabile;
• applica regole WAF specifiche, monitorandone falsi positivi e possibili differenze di normalizzazione.

Queste misure interrompono alcuni passaggi della catena pubblicata, ma non correggono la XSS. Una regola costruita su un singolo payload può inoltre essere aggirata da varianti equivalenti.

Disabilitare le Application Password è una misura compensativa e può rompere integrazioni legittime. Se viene adottata, deve essere documentata, testata e rimossa o rivalutata dopo la patch.

6. Cosa fare se trovi attività sospetta

Se emergono Application Password, plugin, account o file non riconosciuti, non limitarti a cancellare il singolo elemento.

1. Preserva le evidenze. Salva log, snapshot, timeline e copie dei file prima della bonifica.
2. Contieni il sito. Limita l'accesso e impedisci nuove modifiche senza distruggere gli artefatti utili all'analisi.
3. Applica la patch. Aggiorna WordPress alla release corretta per chiudere il punto di ingresso.
4. Revoca gli accessi. Elimina le Application Password sospette, termina le sessioni amministrative e reimposta le credenziali coinvolte.
5. Ruota i segreti. Password WordPress, hosting, database, pannello, SSH, token API e salt devono essere valutati in base alla portata dell'incidente.
6. Verifica la persistenza. Controlla plugin, must-use plugin, temi, cron, file PHP, processi e connessioni in uscita.
7. Ripristina da una base attendibile. Se la compromissione è confermata, preferisci rebuild e ripristino verificato alla sola rimozione della web shell.
8. Estendi l'analisi. Controlla gli altri siti, account o container che condividono credenziali, filesystem o runtime PHP.

Un backup è utile soltanto se precedente alla compromissione. Prima di riportarlo online devi applicare la patch, revocare gli accessi ottenuti dall'attaccante e correggere le condizioni che hanno consentito l'incidente.

Checklist rapida XSS2Shell

• Inventariare tutte le installazioni WordPress esposte, incluse staging e copie dimenticate.
• Verificare la versione realmente in esecuzione.
• Aggiornare alla release corretta per il ramo in uso.
• Controllare i checksum del core.
• Elencare le Application Password di tutti gli amministratori.
• Verificare account, plugin, temi, cron e file modificati.
• Correlare access log, WAF, audit WordPress e cronologia di deployment.
• Revocare credenziali e sessioni sospette conservando prima le evidenze.
• Pianificare la migrazione al ramo WordPress più recente se si usa un backport legacy.

Domande frequenti

XSS2Shell è una RCE senza autenticazione?

La vulnerabilità XSS iniziale è pre-authentication. La catena pubblicata fino all'esecuzione PHP richiede però un amministratore già autenticato, social engineering e un'interazione esplicita della vittima. Descriverla come RCE pre-auth zero-click sarebbe impreciso.

L'autenticazione a due fattori protegge dalla vulnerabilità?

La 2FA riduce il rischio legato al furto della password tradizionale, ma non corregge la XSS e non impedisce automaticamente l'abuso di una sessione amministrativa già attiva. Resta una misura di hardening utile, non una sostituzione della patch.

Se WordPress usa gli aggiornamenti automatici posso considerarlo sicuro?

No. Devi verificare la versione effettiva di ogni installazione e controllare l'esito dell'aggiornamento. Errori di permessi, spazio, rete o configurazione possono bloccare l'update automatico.

Il WAF sostituisce l'aggiornamento?

No. Può ridurre temporaneamente l'esposizione, ma una regola dipende dalla capacità di riconoscere tutte le varianti della richiesta. La patch corregge il comportamento vulnerabile nel core.

Supporto per verifica, analisi dei log e incident response

In un ambiente con più installazioni WordPress, la difficoltà non è soltanto applicare l'aggiornamento, ma dimostrare quali istanze siano state esposte e distinguere una scansione da una compromissione.

Posso supportarti con:

• inventario e verifica delle versioni WordPress;
• patching e mitigazioni temporanee su Nginx, Apache, CDN e WAF;
• analisi di access log, audit WordPress e timeline degli eventi;
• controllo di Application Password, account, plugin e integrità dei file;
• ricerca di persistenza e definizione del piano di bonifica;
• hardening e monitoraggio successivo all'incidente.

Contattami per una valutazione tecnica.

Fonti

• WordPress 7.0.3 Security Release
• WordPress Security Advisory: CVE-2026-64638
• pwn.ai: ricerca originale XSS2Shell
• CERT-AGID: XSS2Shell nel core di WordPress
• WP-CLI: elenco delle Application Password
• WP-CLI: revoca delle Application Password