CVE-2026-64638

XSS riflesso sulla schermata di login che porta all'esecuzione di codice PHP — WordPress Core

Software: WordPress Core ≤ 7.0.2 (tutte le versioni precedenti alla 7.0.3)

CVSS: 8.9 (Alto)

CWE: CWE-79 — Neutralizzazione impropria dell'input durante la generazione di pagine web

Autenticazione richiesta: Nessuna (Pre-Auth)

Interazione utente: Attiva (l'admin deve cliccare 1 link)

Impatto: XSS → Compromissione account → Esecuzione remota di codice

---

1. Cos'è questa vulnerabilità?

WordPress è il sistema di gestione dei contenuti più popolare al mondo, utilizzato da oltre il 40% di tutti i siti web su internet. Ogni sito WordPress ha una pagina di login all'indirizzo /wp-login.php — si tratta di un endpoint pubblico che chiunque può raggiungere senza autenticazione.

Quando un utente inserisce un nome utente errato, WordPress mostra un messaggio di errore contenente l'esatto nome utente appena digitato: «Il nome utente X non è registrato su questo sito.» Il problema sta nel fatto che il valore del nome utente viene inserito direttamente nella risposta HTML senza passare attraverso alcuna funzione di escape — un attaccante deve semplicemente inserire HTML/JavaScript al posto di un vero nome utente e il codice verrà eseguito nel browser.

Si tratta di una vulnerabilità XSS riflesso — il payload è contenuto nella richiesta e viene riflesso in modo identico dal server nell'HTML. Ciò che la rende pericolosa è che la vulnerabilità risiede nella pagina di login — un luogo visitato di frequente dagli admin, dove i cookie di sessione dell'admin possono essere rubati.

Il team di ricerca ha inoltre scoperto che questo XSS può essere concatenato con una vulnerabilità di DOM clobbering nell'emoji-loader di WordPress, consentendo di caricare JavaScript da un server esterno. Da lì, un attaccante può creare un nuovo account admin → installare un plugin contenente una webshell → eseguire codice PHP sul server. Questa catena di exploit è denominata XSS2Shell.

Attributo	Valore
ID CVE	CVE-2026-64638
Punteggio CVSS	8.9 (Alto)
Software	WordPress Core ≤ 7.0.2
Autenticazione	Non richiesta (Pre-Auth)
Interazione utente	Richiede 1 clic (l'admin clicca il link)
Complessità di attacco	Alta
Corretto in	WordPress 7.0.3 (08/06/2026)
Segnalato da	team pwn.ai tramite HackerOne
Report HackerOne	#3877102

2. Spiegazione della terminologia

DOM Clobbering ed emoji-loader

WordPress carica il supporto alle emoji su ogni pagina (inclusa la pagina di login) tramite il file emoji-loader.js. Questo script legge la configurazione da un elemento con id="wp-emoji-settings":

// Before patch (vulnerable)
const settings = JSON.parse(
    document.getElementById('wp-emoji-settings').textContent
);

document.getElementById() restituisce il primo elemento nel DOM con un id corrispondente. Se un attaccante inietta un <div id="wp-emoji-settings"> prima del tag script originale, getElementById leggerà il contenuto dell'attaccante invece della configurazione reale. Questa tecnica è chiamata DOM clobbering — sovrascrivere il comportamento di JavaScript iniettando elementi HTML.

La configurazione delle emoji contiene un URL per caricare un file JavaScript (concatemoji). L'attaccante controlla questo URL → carica un file JS da un server esterno → esegue codice arbitrario nel contesto del browser.

Da XSS a RCE su WordPress

Una volta ottenuta l'esecuzione di JavaScript nel contesto admin, l'attaccante ha pieni privilegi di amministrazione su WordPress:

1. Creare un nuovo account admin — chiamare /wp-admin/user-new.php con la sessione admin
2. Installare un plugin contenente codice PHP — caricare un plugin tramite /wp-admin/plugin-install.php
3. Modificare un file del tema — inserire una backdoor PHP tramite l'Editor dei temi

Ciascuno dei 3 metodi sopra consente l'esecuzione di codice PHP sul server — cioè RCE.

3. Analisi del codice sorgente — Causa principale

Passo 1: Individuare il sink — Dove il nome utente viene inserito nell'HTML

Dal commit di correzione 0d6d42e su wordpress-develop, ho identificato 3 punti nel file wp-includes/user.php in cui il nome utente/email viene inserito direttamente nel messaggio di errore:

# View diff between vulnerable and patched versions
git diff 7.0.2..7.0.3 -- src/wp-includes/user.php

Posizione 1 — Riga 189 (il nome utente non esiste):

Prima :

// BEFORE (vulnerable):
sprintf(
    __( 'The username <strong>%s</strong> is not registered...' ),
    $username      // ← no escaping
)

Dopo :

// fixed:
sprintf(
    __( 'The username <strong>%s</strong> is not registered...' ),
    esc_html( $username )    // ← escaped
)

Posizione 2 — Riga 216 (password errata):

Prima :

// BEFORE:
'<strong>' . $username . '</strong>'    // ← no escaping

Dopo :

// AFTER:
'<strong>' . esc_html( $username ) . '</strong>'

Posizione 3 — Riga 299 (password errata per l'email):

Prima :

// BEFORE:
'<strong>' . $email . '</strong>'    // ← no escaping

Dopo :

// AFTER:
'<strong>' . esc_html( $email ) . '</strong>'

Passo 2: Tracciare la sorgente — Da dove provengono i dati?

Flusso dei dati dalla richiesta POST al messaggio di errore:

$_POST['log']                           ← user input from login form
    ↓
wp_signon() [user.php:51]
    $credentials['user_login'] = wp_unslash($_POST['log'])     ← only removes backslashes
    ↓
wp_authenticate($username, $password) [pluggable.php:689]
    $username = sanitize_user($username)     ← strips HTML tags, but has a bypass
    ↓
wp_authenticate_username_password() [user.php:153]
    get_user_by('login', $username)          ← user not found
    ↓
    sprintf('The username <strong>%s</strong>...', $username)   ← XSS!
    ↓
WP_Error → login_header() → wp_admin_notice()
    wp_kses_post(...)     ← filters HTML but allows <div>, <a>,  through
    ↓
HTML response → browser render → JavaScript execute

Passo 3: Due livelli di difesa, punti deboli e conferma tramite debugging

WordPress ha 2 livelli di filtraggio prima che il nome utente raggiunga l'HTML:

Livello 1: sanitize_user() — Chiama strip_tags() per rimuovere i tag HTML. Tuttavia, strip_tags() di PHP ha limitazioni note: la formattazione non standard dei tag può aggirare il filtro.

Livello 2: wp_kses_post() — Consente il passaggio di un sottoinsieme sicuro di HTML, inclusi <div>, <a>, `` con determinati attributi (ma rimuove i gestori di eventi come onerror, onload). In modo cruciale: wp_kses_post consente <div id="wp-emoji-settings"> — esattamente l'elemento necessario per il DOM clobbering.

Il team pwn.ai ha trovato un modo per aggirare entrambi i livelli e iniettare un payload utilizzabile. I dettagli tecnici specifici non sono stati resi pubblici.

Debugging con Xdebug — Conferma del flusso di dati

Per confermare visivamente che il nome utente finisce direttamente nell'HTML senza escape, ho usato Xdebug + VS Code per posizionare breakpoint nei punti chiave della catena di esecuzione.

Passo 1 — Inserire il payload XSS nel modulo di login:

Accedi a http://localhost:8282/wp-login.php, inserisci come nome utente `` e clicca su Accedi. Appare un popup di alert — l'XSS funziona.