WordPress corregge una XSS nel login che potrebbe consentire l'esecuzione di codice

WordPress ha corretto una vulnerabilità di cross-site scripting (XSS) riflessa pre-autenticazione nella sua schermata di login che interessa ogni versione del content management system (CMS), secondo i ricercatori di sicurezza di pwn.ai che hanno segnalato le loro scoperte a The Hacker News. La falla, tracciata come CVE-2026-64638 con un punteggio CVSS di 8.9, non richiede privilegi da parte dell'attaccante. Una volta che un nome utente appositamente creato raggiunge la pagina di errore di login fallito, il codice JavaScript risultante viene eseguito nel browser del visitatore senza ulteriori interazioni richieste su quella pagina.

La conseguenza più grave è che questa XSS può essere concatenata fino all'esecuzione di codice PHP sul server quando un amministratore connesso interagisce con una pagina controllata dall'attaccante. PHP è il linguaggio di programmazione lato server che WordPress utilizza per costruire e gestire i siti web, quindi eseguirlo dà a un attaccante il controllo del sito. Nella dimostrazione di pwn.ai, quell'interazione è un normale clic. I ricercatori hanno affermato che l'attacco funziona contro installazioni WordPress predefinite e non richiede configurazioni di hosting o distribuzione particolari. Hanno descritto molteplici percorsi dalla XSS all'esecuzione di codice, incluse varianti che installano un plugin o caricano un archivio ZIP arbitrario.

L'avviso di WordPress adotta una visione più cauta sulla sfruttabilità, osservando che l'escalation a esecuzione di codice remoto coinvolge condizioni al di fuori del controllo dell'attaccante e richiede un'ingegneria sociale riuscita più un'esplicita interazione della vittima. Il problema è stato corretto il 6 agosto in WordPress 7.0.3, con correzioni retroportate fino al ramo 4.7. WordPress raccomanda di aggiornare immediatamente, e i siti che supportano gli aggiornamenti automatici in background dovrebbero ricevere automaticamente la release di sicurezza. Le versioni precedenti alla 4.7 rimangono vulnerabili ma sono al di fuori dell'attuale intervallo di retroporting del progetto.

pwn.ai, che chiama la catena di attacco XSS2Shell, ha dichiarato che il suo sistema autonomo ha scoperto e riprodotto la catena di vulnerabilità dopo aver ricevuto come punto di partenza la ricerca del 2022 di Paulos Yibelo sulla Same Origin Method Execution (SOME). L'azienda ha affermato che il lavoro ha richiesto quasi quattro giorni utilizzando modelli open source e un flusso di lavoro multi-agente. La catena è stata riprodotta il 26 luglio e segnalata a WordPress il giorno successivo.

La falla ha origine nel modo in cui WordPress gestisce il nome utente da un login fallito. Secondo i ricercatori, il valore passa attraverso sanitize_user() e wp_strip_all_tags(), che si basa su strip_tags() di PHP. Una stringa simile a un tag contenente uno spazio dopo la parentesi angolare aperta < può sopravvivere a quel parser come testo. Successivamente, WordPress passa il valore attraverso wp_kses_post(), il cui parser separato interpreta lo stesso input come HTML consentito. Il risultato sono elementi DOM attivi controllati dall'attaccante sulla pagina di login fallito. Questi elementi interagiscono poi con user-profile.js di WordPress, uno script di gestione del profilo che viene caricato anche sulla pagina di login perché la pagina gestisce i reimpostamenti della password. Alcuni elementi del profilo che lo script si aspetta sono assenti lì: due input mancanti si risolvono entrambi in undefined, permettendo a un controllo di uguaglianza di passare, mentre la variabile ajaxurl altrimenti indefinita può essere sovrascritta con un elemento DOM iniettato. Questo indirizza il JavaScript di WordPress verso una richiesta REST same-origin scelta dall'attaccante. I ricercatori usano il supporto JSONP REST di WordPress per trasformare quella richiesta in JavaScript eseguito nell'origine del sito. Per le distribuzioni in cui le richieste REST anonime restituiscono HTTP 401, il parametro _envelope=1 può avvolgere il rifiuto in una risposta HTTP 200 esterna, permettendo a jQuery di continuare a elaborare la risposta come script. I ricercatori hanno anche scoperto nei loro test che una Content Security Policy basata su nonce che utilizza strict-dynamic non ha bloccato il percorso dimostrato.

Il percorso dalla XSS all'esecuzione di PHP si basa sulla precedente tecnica SOME di Yibelo, che utilizza una catena di proprietà JSONP consentita per invocare un metodo in un'altra finestra del browser. Un percorso dimostrato da pwn.ai utilizza la XSS nell'origine di WordPress per invocare il controllo nativo di approvazione della Application Password all'interno di una sessione di amministratore connesso. WordPress crea quindi una credenziale API e la reindirizza a un success_url HTTPS scelto dall'attaccante. Le Application Passwords sono credenziali revocabili destinate all'accesso API, quindi questo percorso non ha bisogno di rubare la password principale dell'amministratore. I ricercatori hanno usato la credenziale per un accesso REST autenticato per pubblicare una pagina WordPress contenente JavaScript same-origin. Quando la sessione amministratore conservata ha aperto quella pagina, il suo script ha ottenuto il nonce di caricamento plugin di WordPress e ha caricato un ZIP fornito dall'attaccante. PHP poteva quindi essere richiesto direttamente dal plugin estratto. Il plugin non doveva essere attivato.

L'evidenza di produzione fornita a The Hacker News si ferma alla XSS. I ricercatori hanno riprodotto separatamente la XSS della pagina di login senza cookie contro due distribuzioni WordPress 7.0.2 in profili Chrome puliti senza cookie o credenziali WordPress. Non hanno tentato la creazione di Application Password, il caricamento di file, la persistenza o l'esecuzione di PHP su quei sistemi. La catena completa di esecuzione PHP è stata dimostrata separatamente su un'installazione WordPress 7.0.2 locale pulita.

Un'esecuzione PHP riuscita esporrebbe le credenziali del database WordPress in wp-config.php, permetterebbe la creazione persistente di amministratori e modifiche ai contenuti, esporrebbe file e segreti leggibili dal worker PHP e consentirebbe comandi del sistema operativo con i privilegi di quel worker. I ricercatori hanno affermato che le note misure di hardening di WordPress non dovrebbero essere considerate una mitigazione completa per la XSS sottostante e che applicare l'aggiornamento di sicurezza è necessario.

WordPress ha attribuito al team di pwn.ai la scoperta e la divulgazione responsabile della vulnerabilità. Al 7 agosto, l'avviso del progetto non riporta sfruttamento in-the-wild. Per i proprietari di siti su hosting WordPress gestito, un servizio come AEU Hosting si concentra sul mantenere la piattaforma aggiornata e rafforzata, che è esattamente il tipo di difesa che conta per falle come questa.