CVE-2026-1357 în WPvivid Backup: upload de fișiere fără autentificare și risc de RCE pe site-uri WordPress (până la 0.9.123)

Un advisory publicat de Wordfence atrage atenția asupra unei vulnerabilități critice din pluginul Migration, Backup, Staging – WPvivid Backup & Migration (slug: wpvivid-backuprestore), cu peste 800.000 de instalări active. Problema este clasificată ca Unauthenticated Arbitrary File Upload și, în scenariul potrivit, poate duce la Remote Code Execution (RCE) – adică un atacator poate ajunge să ruleze cod pe server și, de multe ori, la compromiterea completă a site-ului.

Pe scurt: ce s-a întâmplat și cine este afectat

• Vulnerabilitate: Unauthenticated Arbitrary File Upload (încărcare de fișiere arbitrare fără autentificare).
• Impact: posibil RCE și preluare completă a site-ului (de ex. prin webshell).
• Plugin: Migration, Backup, Staging – WPvivid Backup & Migration (wpvivid-backuprestore).
• Versiuni afectate: <= 0.9.123.
• Versiune reparată: 0.9.124.
• CVE: CVE-2026-1357.
• Scor: CVSS 9.8 (Critical).
• Vector de atac menționat: parametru wpvivid_action=send_to_site.

Detalii din Wordfence Intelligence (rezumatul vulnerabilității)

Wordfence descrie cauza ca o combinație între gestionare incorectă a erorilor în decriptarea RSA și lipsa sanitizării căii (path) atunci când fișierele sunt scrise pe disc.

• Pluginul încearcă să decripteze o cheie de sesiune cu openssl_private_decrypt() (în implementarea lor via Crypt_RSA()/phpseclib).
• Când decriptarea cheii eșuează, rezultatul ajunge să fie false. În loc să oprească execuția, codul continuă și pasează acest false către inițializarea cifrului AES/Rijndael.
• Biblioteca (phpseclib) tratează false ca un șir de null bytes, ceea ce face cheia efectiv predictibilă (un fel de „cheie nulă”).
• Atacatorul poate cripta un payload malițios folosind această cheie predictibilă și poate controla conținutul decriptat.
• În plus, numele fișierului este luat din payload-ul decriptat fără sanitizare adecvată, permițând directory traversal (ieșirea din directorul protejat de backup).
• Consecință: un atacator neautentificat poate încărca fișiere (inclusiv PHP) în directoare public accesibile și apoi le poate accesa pentru a obține RCE.

Cum apare bug-ul în fluxul de „send to site”

Funcționalitatea relevantă este cea prin care un site poate primi un backup de la alt site, pe baza unei chei generate din setările pluginului. Wordfence indică faptul că recepția fișierului este gestionată de metoda send_to_site() din clasa WPvivid_Send_to_site, iar mesajul criptat este procesat printr-o rutină de decriptare (decrypt_message()) din clasa WPvivid_crypt.

Din codul analizat de Wordfence rezultă că pluginul ia tokenul/cheia din opțiunile salvate (wpvivid_api_token), verifică existența și expirarea, apoi decriptează conținutul primit în $_POST['wpvivid_content']. Problema apare atunci când decriptarea cheii eșuează, dar codul nu se oprește, iar cifrul simetric este inițializat cu o valoare care ajunge să fie tratată ca „null bytes”.

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);

    $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);

    $rij = new Crypt_Rijndael();
    $rij->setKey($key);

    return $rij->decrypt($data);
}

Interpretarea Wordfence este că, în cazul unei chei invalide, $key devine false, iar inițializarea Rijndael/AES cu această valoare produce o cheie efectiv predictibilă (null bytes). Asta reduce semnificativ bariera criptografică și permite construirea unui payload valid din perspectiva decriptării.

Mai departe, componenta de upload nu impune verificări solide pentru tip/extensie, iar acceptarea numelor de fișiere din payload fără sanitizare deschide ușa către scriere în afara directorului de backup (directory traversal). În combinație, rezultatul este un scenariu clasic de arbitrary file upload care poate ajunge la încărcarea de fișiere PHP și executarea lor.

Ce a schimbat patch-ul (WPvivid 0.9.124)

Wordfence menționează două remedieri principale livrate de vendor în versiunea 0.9.124:

1. O verificare explicită pentru cheia decriptată: dacă $key este false sau gol, funcția de decriptare se oprește și returnează false (în loc să continue cu o cheie predictibilă).
2. O verificare de extensie în send_to_site() astfel încât să fie acceptate doar tipuri specifice de fișiere de backup.

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

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

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

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

$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();
}

Măsuri recomandate pentru administratori și echipe tehnice

1. Actualizează imediat WPvivid Backup la 0.9.124 (sau mai nou, dacă există).
2. Verifică dacă ai activat funcția de „receive a backup from another site” / trimitere între site-uri și dacă există o cheie generată în setările pluginului (acesta e scenariul critic menționat).
3. Dacă nu ai nevoie de transfer de backup între site-uri, păstrează funcția dezactivată (este dezactivată implicit) și evită păstrarea cheilor active mai mult decât e necesar (expirarea este limitată la 24 de ore).
4. Aplică o protecție la nivel de firewall/WAF: Wordfence a distribuit reguli de protecție pentru clienții Premium/Care/Response și ulterior pentru Wordfence Free (detalii mai jos).
5. Ca verificare post-incident: caută fișiere PHP neașteptate în directoare publice și semne de webshell (mai ales dacă funcția a fost activă și site-ul a fost expus în intervalul respectiv).

Protecția Wordfence: când au ajuns regulile de firewall

Conform Wordfence, utilizatorii Wordfence Premium, Wordfence Care și Wordfence Response au primit o regulă de firewall pentru blocarea exploit-urilor care țintesc această vulnerabilitate la data de January 22, 2026. Pentru Wordfence Free, aceeași protecție este programată să ajungă la February 21, 2026 (diferența standard de 30 de zile).

Disclosure timeline (cronologia publicată)

• January 12, 2026 – Wordfence primește raportarea vulnerabilității prin Bug Bounty Program.
• January 22, 2026 – Wordfence validează raportul și confirmă proof-of-concept; contactează vendorul și îl invită să folosească Wordfence Vulnerability Management Portal: https://www.wordfence.com/threat-intel/vendor/vulnerability-management-portal/
• January 22, 2026 – Regula de firewall este livrată către Wordfence Premium/Care/Response.
• January 23, 2026 – Vendorul răspunde și alege comunicarea prin email.
• January 23, 2026 – Wordfence trimite detaliile complete; vendorul confirmă și începe remedierea.
• January 28, 2026 – Este lansată versiunea complet patch-uită: 0.9.124.
• February 21, 2026 – Wordfence Free urmează să primească protecția prin firewall.

Cine a descoperit vulnerabilitatea

Vulnerabilitatea a fost descoperită și raportată responsabil de Lucas Montes (NiRoX) prin programul Wordfence Bug Bounty. Wordfence notează că raportarea a venit la doar cinci zile după introducerea problemei și că researcherul a primit un bounty de $2,145.00.

Detalii despre researcher: https://www.wordfence.com/threat-intel/vulnerabilities/researchers/lucas-montes

Concluzie

CVE-2026-1357 este un exemplu clar de bug critic care apare din combinarea a două probleme: tratarea greșită a unei erori criptografice (continuarea execuției cu o cheie invalidă) și controale insuficiente la scrierea fișierelor (inclusiv posibil directory traversal). Dacă folosești WPvivid Backup și ai activat transferul de backup între site-uri cu cheie generată, actualizarea la 0.9.124 este esențială.

Linkuri utile (din advisory)

• Advisory Wordfence: https://www.wordfence.com/blog/2026/02/800000-wordpress-sites-affected-by-arbitrary-file-upload-vulnerability-in-wpvivid-backup-wordpress-plugin/
• Fișa vulnerabilității în Wordfence Intelligence: https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wpvivid-backuprestore/migration-backup-staging-09123-unauthenticated-arbitrary-file-upload
• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-1357
• Plugin pe WordPress.org: https://wordpress.org/plugins/wpvivid-backuprestore/
• Wordfence Bug Bounty Program: https://www.wordfence.com/threat-intel/bug-bounty-program/
• Submit Vulnerability (Wordfence): https://www.wordfence.com/threat-intel/vulnerabilities/submit/
• Wordfence Vulnerability Management Portal: https://www.wordfence.com/threat-intel/vendor/vulnerability-management-portal/