Una falla in WordPress: il modulo di accesso consegna il server
Una vulnerabilità di WordPress soprannominata XSS2Shell trasforma un tentativo di accesso fallito in codice PHP eseguito sul server. Registrata come CVE-2026-64638, ottiene 8,9 sulla scala CVSS. Parte da un nome utente digitato nel modulo di accesso pubblico e finisce, nelle condizioni giuste, con un plugin fornito dall'attaccante scompattato nella vostra installazione. WordPress ha rilasciato la correzione nella versione 7.0.3 il 6 agosto 2026, con backport fino al ramo 4.7. Il codice di exploit pubblico è comparso nel giro di pochi giorni.
Come funziona la catena XSS2Shell
Il punto di ingresso è il messaggio di errore del login. Inviate un nome utente inesistente e WordPress ve lo restituisce stampato nella pagina. Quel riflesso dovrebbe essere innocuo, e sulla strada ci sono due sanitizzatori distinti. Il bypass trovato dal team di pwn.ai sfrutta una discordanza tra i due: strip_tags() non considera un tag una costruzione preceduta da uno spazio, quindi un payload nella forma < area id=ajaxurl> passa intatto, mentre wp_kses_post() legge poi la stessa stringa come HTML valido e la rende come elemento reale della pagina.
La parte ingegnosa è ciò che fa quell'elemento. Non è uno script. È un nodo del DOM con un nome che collide con una variabile JavaScript che WordPress lascia indefinita su quella schermata, una tecnica chiamata DOM clobbering. Uno script amministrativo del core cerca ajaxurl, trova l'elemento dell'attaccante invece del nulla e indirizza una richiesta dove l'attaccante ha puntato. Da lì la catena passa attraverso il codice fidato del sito stesso: un endpoint REST con supporto JSONP esegue il JavaScript dell'attaccante nell'origine del sito, un trucco di esecuzione di metodi tra finestre raggiunge la sessione di un amministratore connesso e vi approva un Application Password, e quella credenziale concede accesso REST autenticato.
L'ultimo passo non richiede alcun bug esotico. L'Application Password rubata porta con sé privilegi di amministratore, quindi l'attaccante usa semplicemente le API per caricare un plugin: un archivio ZIP con del PHP dentro. Su un'installazione a sito singolo l'amministratore ha inoltre per impostazione predefinita il diritto all'HTML non filtrato, ed è questo a rendere possibile il passaggio intermedio di pubblicare una pagina piena di JavaScript. A quel punto il codice non è più nel browser. Gira con i privilegi del worker PHP, accanto alle credenziali del database.
Che cosa serve davvero a un attaccante
Qui titolo e realtà si separano. La metà cross-site scripting non richiede davvero né account né password, ed è ciò che rende il bug pre-autenticazione. La metà con l'esecuzione di codice da remoto invece non scatta da sola. Un amministratore deve essere autenticato sul sito bersaglio e deve aprire un link controllato dall'attaccante. Non compare alcuna richiesta, non viene chiesta alcuna conferma e la vittima non vede nulla di strano, ma la visita deve avvenire.
In pratica l'asticella è bassa. Gli amministratori di siti cliccano tutto il giorno link in ticket di assistenza, moduli di contatto, notifiche di commenti ed email di fornitori, spesso nella stessa sessione del browser in cui è aperta la bacheca. Leggere "richiede interazione dell'utente" come una rassicurazione è esattamente il modo in cui una catena simile resta senza patch per un mese.
Quali versioni sono interessate
Sono vulnerabili tutte le release di WordPress dalla 4.7 fino alla 7.0.2 inclusa. Quel ramo è uscito nel dicembre 2016, ed è per questo che l'intervallo interessato copre praticamente ogni installazione che riceva ancora aggiornamenti. WordPress ha pubblicato lo stesso giorno correzioni per l'intero albero supportato, dalla 7.0.3 passando per 6.9.6 e 6.8.7 fino alla 4.7.34. Tutto ciò che gira su 4.6 o versioni precedenti non riceve alcun aggiornamento di sicurezza e va considerato esposto in modo permanente.
XSS2Shell era uno dei dodici problemi chiusi in quella release. Tra gli altri figurano cross-site scripting memorizzato nei blocchi Post Date e Post Content, nelle impostazioni delle emoji e nella modifica rapida, una divulgazione di informazioni che esponeva i commenti di articoli protetti da password, un aggiramento della conferma dell'indirizzo email, un'iniezione CSS attraverso il filtro degli attributi sicuri, un'elevazione di privilegi nelle reti multisito con registrazione aperta, una server-side request forgery nella validazione degli URL che raggiungeva gli intervalli link-local e un'enumerazione degli slug degli articoli. Anche senza la catena principale, quell'elenco è un motivo per aggiornare oggi.
Che cosa fare adesso
- Aggiornare subito: passare alla 7.0.3 o alla release corretta del proprio ramo. Gli aggiornamenti automatici in background installano per impostazione predefinita le release minori di sicurezza, ma conviene verificare il numero di versione invece di darlo per scontato.
- Controllare gli Application Passwords: aprire il profilo di ogni amministratore e revocare qualunque credenziale non riconosciuta. È l'artefatto che la catena lascia dietro di sé, e sopravvive a un cambio di password.
- Rivedere utenti, plugin e file: cercare account amministratore che non avete creato e plugin comparsi senza una voce corrispondente nella vostra cronologia delle modifiche.
- Non aprire la bacheca ovunque: tenere la sessione di amministrazione in un profilo del browser diverso da quello usato per email e ticket toglie all'attacco proprio la condizione da cui dipende.
- Limitare la schermata di accesso: il riflesso vive in wp-login.php. Restringerne l'accesso, con una lista di IP consentiti, autenticazione HTTP o una regola del firewall, riduce la superficie per il prossimo bug nello stesso file.
Perché riguarda anche chi non gestisce siti
Un'installazione WordPress compromessa raramente è l'obiettivo dell'attaccante. È un mezzo di consegna, e il traffico che serve gode di fiducia proprio perché il dominio è legittimo. Lo stesso schema si è visto quando uno script pubblicitario ha iniziato a riscrivere indirizzi di portafogli crypto su migliaia di siti comuni, e la stessa idea sta dietro agli attacchi a livello di browser che cavalcano una sessione autenticata già aperta dalla vittima. Per un lettore, e non per un amministratore, la difesa pratica sta a livello di rete: filtraggio DNS e blocklist impediscono al payload di seconda fase di caricarsi anche quando il sito che lo consegna è uno che frequentate da anni. È un argomento diretto a favore degli strumenti di privacy che bloccano già in fase di risoluzione, ed è onesto dire che nessuno di essi applica patch al vostro server. Quello lo fa solo l'aggiornamento.
