WordPress 7.0.3 corregge XSS login: con ingegneria sociale può…

CVE-2026-64638 è un XSS reflected pre-autenticazione nella schermata di login di WordPress, scoperto da pwn.ai con sistemi AI assistiti. Richiede interazione di un

Dichiarazione limiti fonte: Questo articolo si basa principalmente su The Hacker News come fonte primaria strutturata. Non è disponibile un advisory vendor WordPress con URL diretto verificabile.

CVE-2026-64638 è una vulnerabilità XSS reflected pre-autenticazione nella schermata di login di WordPress, con punteggio CVSS 8.9 (high severity). La catena di attacco dimostrata richiede che un amministratore già autenticato interagisca con contenuto controllato dall'attaccante, attraverso ingegneria sociale, per consentire l'esecuzione di codice PHP sul server. La falla è stata scoperta dal team di pwn.ai utilizzando modelli open-source e un flusso di lavoro multi-agente con input umano, che ha riprodotto la catena di attacco completa in circa quattro giorni a partire dalla ricerca accademica di Paulos Yibelo del 2022. WordPress ha rilasciato la patch il 6 agosto 2026 con la versione 7.0.3, con backport estesi fino alla branch 4.7.

Punti chiave

CVE-2026-64638 è un XSS reflected pre-autenticazione nella schermata di login di WordPress, con CVSS 8.9 (high severity).
L'escalation a RCE richiede sempre ingegneria sociale e interazione esplicita di un amministratore già autenticato; non è un exploit diretto.
La catena dimostrata sfrutta l'inconsistenza tra due parser WordPress per iniettare JavaScript, poi manipola richieste REST per caricare un plugin ZIP contenente PHP.
pwn.ai ha scoperto e riprodotto la vulnerabilità in circa quattro giorni usando sistemi AI assistiti da input umano, segnalando il risultato a WordPress il 27 luglio 2026.
La patch 7.0.3 è disponibile dal 6 agosto 2026 con backport fino alla branch 4.7; le versioni precedenti non ricevono più aggiornamenti di sicurezza.

Il bypass che nasce da due parser che leggono diversamente la stessa stringa

Il meccanismo di iniezione si ancora a una discrepanza di parsing tra due funzioni di sanitizzazione di WordPress. Quando un utente inserisce credenziali errate, il valore del campo username attraversa dapprima wp_strip_all_tags(), che internamente chiama la funzione PHP strip_tags(). Questa interpreta una stringa contenente "<" seguito da whitespace come testo harmless, lasciandola passare. Successivamente WordPress applica wp_kses_post(), il cui parser separato legge la medesima stringa come HTML permesso, esponendo la pagina di errore a un'iniezione JavaScript.

Una volta iniettato, il payload interagisce con user-profile.js, script interno caricato sulla pagina di login. Il JavaScript di WordPress dipende dalla variabile ajaxurl, normalmente undefined in quel contesto. L'elemento DOM iniettato dall'attaccante sovrascrive questa variabile, deviando le richieste REST verso un endpoint controllato dall'attaccante ma eseguito same-origin. Per le configurazioni dove le richieste REST anonime restituiscono HTTP 401, i ricercatori hanno utilizzato il parametro _envelope=1, che incapsula il rifiuto in una risposta HTTP 200 esterna permettendo a jQuery di processarla come script.

Dal click dell'amministratore all'esecuzione PHP: la catena RCE dimostrata

La fase di escalation a esecuzione di codice remoto si appoggia sulla tecnica SOME (Same Origin Method Execution) sviluppata dal ricercatore Paulos Yibelo nel 2022. Attraverso il JavaScript iniettato, l'attaccante invoca il controllo nativo di approvazione Application Password di WordPress. Il sistema crea credenziali API valide, che vengono immediatamente utilizzate per accessi REST autenticati.

Con queste credenziali, l'attaccante pubblica una pagina WordPress contenente ulteriore JavaScript, ottiene la nonce per l'upload di plugin e carica un archivio ZIP. Il PHP contenuto nell'archivio può essere richiesto direttamente dai file estratti, senza necessità di attivare il plugin attraverso l'interfaccia amministrativa. Questo percorso è stato riprodotto con successo su un'installazione pulita di WordPress 7.0.2, non sui sistemi wordpress.com hosted, che i ricercatori hanno esplicitamente escluso dal campo di test.

Secondo The Hacker News, i ricercatori hanno menzionato varianti alternative di RCE non dettagliate pubblicamente. Secondo la stessa fonte, una valutazione più restrittiva considera l'escalation a RCE subordinata a condizioni fuori dal controllo dell'attaccante e richiedente ingegneria sociale con interazione esplicita della vittima.

Quattro giorni di ciclo scoperta-segnalazione: il ruolo dell'intelligenza artificiale

Il contributo distintivo di questo caso risiede nel metodo di scoperta. Il sistema di pwn.ai, assistito da AI con input umano, ha riprodotto l'intera catena di attacco in circa quattro giorni, impiegando modelli open-source e un flusso multi-agente. Il punto di partenza è stato il paper accademico di Yibelo del 2022 sulla tecnica SOME. La riproduzione è stata completata il 26 luglio 2026, con la segnalazione a WordPress il giorno successivo.

"The nastiest one is a login screen XSS, which via some social engineering could lead to Remote Code Execution." Oliver Sild, CEO di Patchstack (azienda di sicurezza WordPress), citato da Search Engine Journal

Analisi del redattore: La rapidità del ciclo scoperta-segnalazione, compresso in circa quattro giorni, evidenzia una tensione nel modello attuale di vulnerability disclosure: la fase di identificazione tecnica accelera, mentre la distribuzione di patch resta vincolata ai cicli di rilascio umani.

Cosa fare adesso

Aggiornare immediatamente a WordPress 7.0.3 tutte le installazioni gestite autonomamente, verificando che il backport sia applicabile alla versione in uso.
Identificare le installazioni con versione inferiore alla 4.7, che non ricevono più patch di sicurezza e richiedono migrazione o isolamento.
Valutare restrizioni sull'endpoint REST JSONP e sul parametro _envelope=1 come possibili contromisure non verificate, dato che la fonte non ne conferma l'efficacia.

Al 7 agosto 2026 non è segnalata exploitation in-the-wild. I ricercatori hanno deliberatamente ritenuto alcuni dettagli tecnici, quindi l'exploit completo non è pubblicamente disponibile.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Il bypass che nasce da due parser che leggono diversamente la stessa stringa

Dal click dell'amministratore all'esecuzione PHP: la catena RCE dimostrata

Quattro giorni di ciclo scoperta-segnalazione: il ruolo dell'intelligenza artificiale

Cosa fare adesso

Sul tema

Fonti