Patchato l'XSS del login di WordPress dopo una catena verso l'esecuzione di codice PHP

Una falla XSS nel login di WordPress che non richiede account, password o privilegi per essere attivata è stata corretta in WordPress 7.0.3, dopo che i ricercatori di pwn.ai hanno dimostrato che il bug può essere concatenato fino all'esecuzione di codice PHP sul server. La vulnerabilità è tracciata come CVE-2026-64638 e ha un punteggio CVSS di 8.9, che la colloca nella fascia di gravità alta. La patch è stata rilasciata il 6 agosto ed è stata retroportata fino al ramo 4.7 del sistema di gestione dei contenuti, quindi la correzione raggiunge anche siti che eseguono versioni così vecchie. Le versioni precedenti alla 4.7 restano vulnerabili ma sono fuori dall'attuale intervallo di retroporting del progetto.

Il cross-site scripting, di solito abbreviato in XSS, consiste nel far eseguire il JavaScript di un attaccante nel browser di qualcun altro mentre quella persona sta visitando un sito web. Si parla di reflected quando l'input malevolo viene inviato in una richiesta e poi rimandato nella pagina che la vittima carica. Qui la falla si trova nella schermata di login di WordPress e, secondo pwn.ai, che l'ha scoperta e ha condiviso i dettagli tecnici con The Hacker News, non è richiesta alcuna autenticazione. Un nome utente appositamente costruito inviato alla pagina di login finisce nella pagina di errore del login fallito, e il JavaScript risultante viene eseguito nel browser del visitatore. Quella pagina non richiede ulteriori interazioni da parte della vittima: basta visitarla.

Trasformare quell'iniezione di script in codice in esecuzione sul server è una strada molto più lunga. Richiede una vittima già autenticata come Amministratore e che interagisca con una pagina controllata dall'attaccante. Nella dimostrazione di pwn.ai quell'interazione era un normale clic, esattamente il tipo di passo che l'ingegneria sociale è progettata per ottenere. I ricercatori hanno detto a The Hacker News che l'attacco funziona contro installazioni WordPress predefinite e non richiede configurazioni di hosting o di deployment particolari, e che hanno diversi percorsi dall'XSS all'esecuzione di codice, incluse varianti che installano un plugin o caricano un archivio ZIP arbitrario.

L'avviso ufficiale di WordPress adotta una visione più prudente sulla sfruttabilità. Osserva che l'escalation fino all'esecuzione di codice remoto, cioè la capacità di eseguire comandi sul server, coinvolge condizioni fuori dal controllo dell'attaccante e richiede una riuscita ingegneria sociale più un'interazione esplicita della vittima. Le due posizioni non sono contraddittorie. L'iniezione di script in sé non pretende nulla dall'obiettivo, mentre il salto all'esecuzione di codice dipende da un amministratore autenticato indotto a fare clic.

pwn.ai riconduce la falla al modo in cui WordPress gestisce il nome utente di un tentativo di login fallito. Il valore passa attraverso sanitize_user() e wp_strip_all_tags(), il secondo dei quali si basa sulla funzione strip_tags() di PHP. Una stringa simile a un tag contenente uno spazio dopo la parentesi angolare di apertura può sopravvivere a quel parser ed essere trattata come testo normale. Più tardi, WordPress passa lo stesso valore attraverso wp_kses_post(), una funzione che filtra il contenuto in base a un elenco di HTML consentito, e questo secondo parser legge l'identico input come HTML permesso. I due parser non concordano sugli stessi caratteri, e il risultato sono elementi DOM attivi controllati dall'attaccante sulla pagina di login fallito. Gli elementi DOM sono i pezzi che un browser assembla in una pagina, quindi l'attaccante ha di fatto inserito i propri pezzi nella pagina che WordPress sta mostrando.

Quegli elementi interagiscono poi con user-profile.js di WordPress, uno script di gestione del profilo che viene caricato anche sulla pagina di login perché quella pagina gestisce il ripristino della password. Alcuni degli elementi del profilo che lo script si aspetta sono assenti lì. Due input mancanti si risolvono entrambi in undefined, il che permette a un controllo di uguaglianza di passare, e la variabile ajaxurl altrimenti indefinita, l'indirizzo che lo script usa per comunicare con il sito, può essere sovrascritta con un elemento DOM iniettato. L'effetto è indirizzare il JavaScript di WordPress verso una richiesta REST same-origin scelta dall'attaccante, dove same-origin significa che la richiesta sembra provenire dal sito stesso. I ricercatori usano il supporto JSONP di WordPress REST per convertire quella richiesta in JavaScript eseguito nell'origine del sito. Per i deployment in cui le richieste REST anonime restituiscono HTTP 401, il codice di risposta non autorizzata, il parametro _envelope=1 può avvolgere il rifiuto in una risposta HTTP 200 esterna, il che permette a jQuery, la libreria JavaScript coinvolta, di continuare a elaborarla come script. I ricercatori hanno anche scoperto nei loro test che una Content Security Policy basata su nonce con strict-dynamic non bloccava il percorso che hanno dimostrato. Una Content Security Policy è un elenco di regole che un sito invia al browser indicando quali script possono essere eseguiti, e un nonce è un codice monouso che contrassegna uno script come attendibile.

Un percorso dimostrato da pwn.ai usa l'XSS nell'origine di WordPress per invocare il controllo nativo di approvazione delle Application Password all'interno di una sessione di un Amministratore autenticato. Le Application Password sono credenziali revocabili pensate per l'accesso API, quindi questa via non richiede che venga rubata la password principale dell'amministratore. WordPress crea allora una credenziale API e la reindirizza a un success_url HTTPS scelto dall'attaccante. I ricercatori hanno usato quella credenziale per un accesso REST autenticato al fine di pubblicare una pagina WordPress contenente JavaScript same-origin. Quando la sessione amministratore conservata apriva quella pagina, il suo script otteneva il nonce di caricamento plugin di WordPress e caricava un archivio ZIP fornito dall'attaccante. Il PHP poteva poi essere richiesto direttamente dal plugin estratto, e il plugin non doveva essere attivato. Questa fase si basa sulla ricerca del 2022 di Paulos Yibelo sulla Same Origin Method Execution, una tecnica che usa una catena di proprietà JSONP consentita per invocare un metodo in un'altra finestra del browser.

I ricercatori chiamano la catena di attacco XSS2Shell. Dicono che il loro sistema autonomo ha scoperto e riprodotto la catena di vulnerabilità dopo che era stata fornita come punto di partenza la ricerca SOME del 2022 di Yibelo, che il lavoro ha richiesto quasi quattro giorni usando modelli open-source e un flusso di lavoro multi-agente, e che la catena è stata riprodotta il 26 luglio e segnalata a WordPress il giorno successivo. Conta dove è stato provato ciascun anello. Le prove di produzione fornite a The Hacker News si fermano all'XSS. I ricercatori hanno riprodotto separatamente l'XSS della pagina di login senza cookie contro due installazioni WordPress 7.0.2 in profili Chrome nuovi, 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. WordPress ha attribuito al team di pwn.ai la scoperta e la divulgazione responsabile della vulnerabilità, e al 7 agosto l'avviso del progetto non segnala sfruttamento in the wild.

Cosa significherebbe in pratica un'esecuzione PHP riuscita? Esporrebbe le credenziali del database WordPress memorizzate in wp-config.php, permetterebbe di creare account amministratore persistenti e di modificare i contenuti, esporrebbe file e segreti leggibili dal processo PHP, e consentirebbe comandi di sistema operativo con i privilegi di quel processo. I ricercatori dicono che le note misure di hardening di WordPress non dovrebbero essere considerate una mitigazione completa dell'XSS sottostante, e che applicare l'aggiornamento di sicurezza è necessario. WordPress raccomanda di aggiornare immediatamente, e i siti che supportano gli aggiornamenti automatici in background dovrebbero ricevere da soli la release di sicurezza. I proprietari di siti su versioni precedenti alla 4.7 devono passare a una release supportata invece di aspettare, perché per loro non è previsto alcun backport. Controllare il numero di versione nella dashboard di WordPress e applicare da lì qualsiasi aggiornamento disponibile è il primo passo pratico.

Per i lettori che preferiscono non seguire da soli le release di WordPress, AEU Hosting (albhosting.eu) è un servizio di hosting WordPress gestito, il che significa che gli aggiornamenti del core e la sicurezza del sito sono gestiti come parte della configurazione, e la pagina di ogni piano indica esattamente cosa è incluso.