CVE-2026-1357 in WPvivid Backup: upload di file arbitrari e rischio RCE (ma solo se usi la chiave “send to site”)

Cosa sta succedendo: vulnerabilità critica in WPvivid Backup

Wordfence ha pubblicato un advisory su una vulnerabilità di tipo Unauthenticated Arbitrary File Upload nel plugin WordPress WPvivid Backup & Migration (slug: wpvivid-backuprestore), che conta oltre 800.000 installazioni attive. In pratica, in certe condizioni un attaccante non autenticato può caricare file a piacere sul sito e ottenere Remote Code Execution (RCE), cioè eseguire codice sul server: lo scenario classico che porta a webshell e compromissione completa del sito.

Riepilogo vulnerability (Wordfence Intelligence)

• Titolo: Migration, Backup, Staging <= 0.9.123 - Unauthenticated Arbitrary File Upload
• CVE: CVE-2026-1357
• Severità: CVSS 9.8 (Critical)
• Versioni impattate: <= 0.9.123
• Versione con fix: 0.9.124
• Parametro citato nell’exploit chain: wpvivid_action=send_to_site
• Ricercatore: Lucas Montes (NiRoX)
• Bounty: $2,145.00

Perché è pericolosa: upload arbitrario + directory traversal + PHP eseguibile

Nelle versioni vulnerabili, la catena descritta da Wordfence combina più fattori: gestione errata di un passaggio di decrittazione (RSA/AES) e assenza di sanitizzazione del path del file scritto su disco. Il risultato è che un attaccante può arrivare a caricare un file (anche PHP) in una directory pubblicamente raggiungibile e poi richiamarlo via HTTP per ottenere RCE.

Il punto d’ingresso si trova nella funzione send_to_site() della classe WPvivid_Send_to_site, che gestisce la ricezione di un backup da un altro sito quando è presente la chiave generata nelle impostazioni. Il flusso include class-wpvivid-crypt.php, inizializza logging e poi legge $_POST['wpvivid_content'] (base64) per decrittare un payload e procedere con la gestione del file.

Il cuore del problema: la chiave “false” che diventa prevedibile

Secondo l’analisi tecnica, il plugin usa la chiave generata nelle impostazioni per decrittare via RSA un valore $key. Se la decrittazione fallisce, $key diventa false. Qui entra il bug: l’esecuzione non viene interrotta e quel false viene passato all’inizializzazione del cifrario AES/Rijndael (tramite phpseclib). La libreria tratta quel false come una stringa di byte nulli, rendendo la “chiave” di cifratura di fatto prevedibile. Un attaccante può quindi costruire dati cifrati usando questa chiave a byte nulli.

A questo si somma un secondo aspetto: i nomi file contenuti nel payload decrittato vengono accettati senza sanitizzazione del percorso. Questo abilita directory traversal, cioè la possibilità di “uscire” dalla directory protetta dei backup e finire a scrivere file altrove (ad esempio in percorsi web-accessible). Non essendoci (nelle versioni vulnerabili) controlli su estensione/tipo file, diventa possibile caricare un file PHP malevolo e poi eseguirlo.

Dettagli tecnici: i punti chiave citati da Wordfence

• Funzione coinvolta nella ricezione: send_to_site() in WPvivid_Send_to_site.
• Contenuto ricevuto via POST: wpvivid_content (base64) che viene decrittato lato server.
• Decrittazione con RSA che può fallire: quando openssl_private_decrypt() (menzionato nel riepilogo) non riesce, il valore può diventare false e non viene gestito correttamente.
• Inizializzazione cifrario AES/Rijndael (phpseclib) con chiave false: interpretata come sequenza di byte nulli (chiave prevedibile).
• Assenza di path sanitization per i nomi file nel payload: possibilità di directory traversal e scrittura fuori dalla directory backup.
• Possibilità di caricare file PHP in directory pubbliche e arrivare a RCE.
• Parametro menzionato per l’azione: wpvivid_action=send_to_site.

La patch in WPvivid 0.9.124: cosa è stato corretto

Il team di WPvivid ha rilasciato una correzione nella versione 0.9.124. Dall’advisory emergono due interventi principali: (1) un controllo esplicito sul valore della chiave dopo la decrittazione RSA e (2) un controllo sulle estensioni dei file consentiti in upload nella logica di ricezione.

1) Check su $key in decrypt_message()

Il fix aggiunge un controllo: se la chiave risultante è false o vuota, la funzione termina restituendo false invece di proseguire e inizializzare il cifrario con una chiave prevedibile.

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);
    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);
    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    // Patch: interrompe se la chiave non è valida
    if ($key === false || empty($key))
    {
        return false;
    }

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);
    return $rij->decrypt($data);
}

public function decrypt_message($message)
{
    $len = substr($message, 0, 3);
    $len = hexdec($len);
    $key = substr($message, 3, $len);

    $cipherlen = substr($message, ($len + 3), 16);
    $cipherlen = hexdec($cipherlen);

    $data = substr($message, ($len + 19), $cipherlen);
    $rsa = new Crypt_RSA();
    $rsa->loadKey($this->public_key);
    $key = $rsa->decrypt($key);

    // Patch: interrompe se la chiave non è valida
    if ($key === false || empty($key))
    {
        return false;
    }

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);
    return $rij->decrypt($data);
}

2) Whitelist delle estensioni accettate in send_to_site()

In aggiunta, la patch introduce un controllo sulle estensioni per assicurare che vengano caricati solo file di backup. Il codice mostrato da Wordfence usa basename() e una preg_replace() per ripulire il nome, poi verifica l’estensione contro una lista consentita.

$safe_name = basename($params['name']);
$safe_name = preg_replace('/[^a-zA-Z0-9._-]/', '', $safe_name);

$allowed_extensions = array('zip', 'gz', 'tar', 'sql');
$file_ext = strtolower(pathinfo($safe_name, PATHINFO_EXTENSION));

if (!in_array($file_ext, $allowed_extensions, true))
{
    $ret['result'] = WPVIVID_FAILED;
    $ret['error'] = 'Invalid file type - only backup files allowed.';
    echo wp_json_encode($ret);
    die();
}

$safe_name = basename($params['name']);
$safe_name = preg_replace('/[^a-zA-Z0-9._-]/', '', $safe_name);

$allowed_extensions = array('zip', 'gz', 'tar', 'sql');
$file_ext = strtolower(pathinfo($safe_name, PATHINFO_EXTENSION));

if (!in_array($file_ext, $allowed_extensions, true))
{
    $ret['result'] = WPVIVID_FAILED;
    $ret['error'] = 'Invalid file type - only backup files allowed.';
    echo wp_json_encode($ret);
    die();
}

Chi è esposto davvero? La condizione della chiave generata

Il punto operativo da tenere a mente è quello evidenziato anche da Wordfence: la vulnerabilità “colpisce in modo critico” chi ha attivato la funzionalità di ricezione backup generando una chiave nelle impostazioni. È una funzione off di default, e la chiave ha una scadenza configurabile fino a 24 ore. Questo non annulla la gravità tecnica (CVSS 9.8), ma cambia molto la priorità di analisi del rischio per siti che non usano mai quel canale di trasferimento.

Mitigazione: cosa fare subito su siti WordPress in produzione

1. Verifica la versione installata di WPvivid Backup: se sei su 0.9.123 o precedente, pianifica l’update immediato.
2. Aggiorna a WPvivid Backup 0.9.124 (versione indicata come patchata al momento della pubblicazione dell’advisory).
3. Controlla le impostazioni del plugin: se in passato hai generato una chiave per ricevere backup da un altro sito, considera di rigenerarla solo quando serve e rispettare la scadenza breve (massimo 24 ore, come indicato).
4. Se usi Wordfence: sappi che la protezione via firewall è stata distribuita a Wordfence Premium/Care/Response il 22 gennaio 2026; per Wordfence Free la stessa regola è prevista 30 giorni dopo, il 21 febbraio 2026 (secondo la comunicazione).
5. Dopo l’update, esegui una verifica di integrità: controlla directory tipicamente pubbliche (es. wp-content/uploads/ e simili) alla ricerca di file inattesi, e rivedi i log di accesso se hai indicatori di compromissione.

Timeline di disclosure (secondo Wordfence)

• January 12, 2026 – Invio della segnalazione della vulnerabilità tramite Wordfence Bug Bounty Program.
• January 22, 2026 – Validazione e conferma del proof-of-concept; primo contatto con il vendor e invito a usare il Wordfence Vulnerability Management Portal.
• January 22, 2026 – Rilascio della regola firewall per utenti Wordfence Premium/Care/Response.
• January 23, 2026 – Risposta del vendor (preferenza per gestione via email).
• January 23, 2026 – Invio dei dettagli completi; ack e avvio lavoro sul fix.
• January 28, 2026 – Rilascio della versione patchata 0.9.124.
• February 21, 2026 – Protezione equivalente prevista per Wordfence Free.

Nota sul Bug Bounty e sul ricercatore

La scoperta è attribuita a Lucas Montes (NiRoX), che ha riportato il problema responsabilmente tramite il Bug Bounty Program di Wordfence. Wordfence indica che la segnalazione è arrivata cinque giorni dopo l’introduzione della vulnerabilità e che il bounty riconosciuto per questo caso è stato di $2,145.00.

Conclusione

CVE-2026-1357 è un caso da prendere sul serio: una combinazione di gestione errata degli errori in decrittazione e controlli insufficienti sul file in ingresso può trasformarsi in upload arbitrario e RCE senza autenticazione. La buona notizia è che esiste una versione corretta (0.9.124) e che l’impatto più critico si manifesta soprattutto quando è attiva la funzione di ricezione backup tramite chiave temporanea. Se hai WPvivid in produzione, l’azione più sensata è verificare versione e configurazione, aggiornare e controllare eventuali tracce di upload sospetti.